Search found 108 matches
- Fri Nov 11, 2016 8:09 am
- Forum: ESP8266 boards
- Topic: Webserver looses character
- Replies: 4
- Views: 3923
Re: Webserver looses character
Why not test the return value of send which is supposed to be the actual number of bytes sent ? Well I assume that's the case. The MicroPython docs don't say as much.
- Tue Nov 01, 2016 4:53 pm
- Forum: ESP8266 boards
- Topic: Querying Uber API from Wemos D1
- Replies: 2
- Views: 3363
Re: Querying Uber API from Wemos D1
You are likely to find that its dependencies just don't run on this device.
- Tue Nov 01, 2016 4:48 pm
- Forum: ESP8266 boards
- Topic: Wemos D1 mini stuck in bootloop after flashing 1.8.4, 1.8.5, 1.8.5-latest
- Replies: 6
- Views: 7630
Re: Wemos D1 mini stuck in bootloop after flashing 1.8.4, 1.8.5, 1.8.5-latest
I've grumbled before about the illiteracy among many coders concerning units.
After my change recent versions of esptool warns if it isn't going to fit which helps a bit.
After my change recent versions of esptool warns if it isn't going to fit which helps a bit.
- Thu Oct 27, 2016 3:19 pm
- Forum: ESP8266 boards
- Topic: Calling experienced network programmers
- Replies: 31
- Views: 24036
Re: Calling experienced network programmers
TCP says absolutely nothing about timing out unless you have keepalives going. On a sensible network what is supposed to happen when one end thinks a TCP connection is closed is to reply to any attempt to talk to a socket with an RST. However this isn't reliable for example if the host simply isn't ...
- Wed Oct 26, 2016 2:14 pm
- Forum: ESP8266 boards
- Topic: Calling experienced network programmers
- Replies: 31
- Views: 24036
Re: Calling experienced network programmers
A couple of points. @Damien has cautioned that using sockets in a timer callback is unreliable. Secondly I've encountered very rare occasions when a socket read or write seems to block forever. Block forever even when configured not to ? Blocking forever on a normal blocking socket is quite possibl...
- Tue Oct 25, 2016 12:01 pm
- Forum: ESP8266 boards
- Topic: Calling experienced network programmers
- Replies: 31
- Views: 24036
Re: Calling experienced network programmers
I must apologise. I meant there _is_ control of timeout and blocking (or not) through usocket.
Whether they work properly and are configurable through things built on top (MQTT...) is another matter.
Whether they work properly and are configurable through things built on top (MQTT...) is another matter.
- Thu Oct 20, 2016 3:20 pm
- Forum: ESP8266 boards
- Topic: Calling experienced network programmers
- Replies: 31
- Views: 24036
Re: Calling experienced network programmers
Whether select or poll or timeout/blockability (applied via ioctl or fcntl) or process alarms or indeed many threads is largely down to preference. Heavyweight servers with many sockets use kqueue and similar. But I believe the _only_ things we have here are socket timeouts and blocking through the ...
- Wed Oct 19, 2016 12:21 pm
- Forum: ESP8266 boards
- Topic: Calling experienced network programmers
- Replies: 31
- Views: 24036
Re: Calling experienced network programmers
My test was oh maybe six feet from my router though this goes wobbly from time to time thanks to Virgin Media. I just wanted to know whether the ESP itself causes trouble. A real application, no matter what it uses must have its own policy for what to do when connectivity fails. This could be as sim...
- Tue Oct 18, 2016 4:00 pm
- Forum: ESP8266 boards
- Topic: Calling experienced network programmers
- Replies: 31
- Views: 24036
Re: Calling experienced network programmers
I agree that something isn't as robust as it might be. I've been writing network/socket code for decades now and do network TAPs for a living (and it's almost certain your bank, mobile provider and ISP all use kit we supply) so like to think I've see just about every kind of weird network problem go...
- Mon Oct 10, 2016 9:40 am
- Forum: ESP8266 boards
- Topic: ESP board doesn't support std{in,out,err}.buffer
- Replies: 7
- Views: 6168
Re: ESP board doesn't support std{in,out,err}.buffer
I think you're looking for what is typically provided by the operating system.
If you want carriage returns produce them yourself.
If you want carriage returns produce them yourself.