Has anyone run into the problem where the code will work on one board but not another, very similar board?
I successfully developed some code on a Mega2560 with an ESP01 for wifi. Uses Serial1 on the Mega. However, when I rehost it on an Uno, just changing the serial connection to the UART (0, 1) pins, I now get the following error:
The debug output comes from a SoftwareSerial connection - nothing else is writing to the UART. (Yes, that is one other difference, but the same thing happens with SoftwareSerial removed.) I thought it might be available RAM, as that is big difference between the two boards, but the free memory is fairly constant at ~ 660 which I would think is sufficient unless a library function has a big stack footprint or they are deeply nested. I’ve tried a lot of things, but nothing has worked. I’d post the code, but basically it is not getting past Blynk.connect() so not sure it would help.
660 does seem tight, though. Any empirical data on how much free space to reserve with this library?
It does connect, so it has to be something else. Are you manually setting the MAC address of your ESP? If not, it could help to clear/reboot your router/modem. Sounds silly, but my router has something against ESP’s if they connect too many times in a short period.
That’s not it. I switch back to the Mega when I make code changes to verify that it is still working and every time it runs fine on the Mega.
But I did figure this out. I added a check of free memory using the FreeMemory library in the Blynk.connect() wait loop. Before calling connect(), free memory is 675. Afterwards, it’s 4560, which means that the heap and the stack have grown into each other.
To understand why this was happening, I read through the code for connect(), and in BlynkProtocol.h there is a sendCmd function that puts a 256 byte array on the stack. Ouch! There is a TODO note to get rid of the constant:
but there is no easy way I can see to eliminate this without major changes to the library.
I have optimized the memory footprint of my code to within 20 bytes or so of the minimum using PROGMEM, etc. At this point, my only option is the Mega and that will not fit the enclosure this project needs to be in.
Blynk authors / @vshymanskyy: I see in the roadmap that an ESP8266 rewrite is coming. How soon can we expect that and will it solve this issue? I can wait for a while if there is hope that we’ll have library code soon that has less of a stack footprint. Please help. Thanks.
Unfortunately I couldn’t find a better library for ESP8266 interfacing yet.
Can someone suggest a better driver library?
(currently a modified ITEAD esp8266 library is used)
I thought of that, but looking at the code, I don’t see any boundary checking so I was concerned that I would create a buffer overflow condition. In particular, I was concerned about this debug message:
>msg 0,1,200
Which made me think that the smallest declaration for the buffer was ~ 200. Any advice for
how small you can make the buffer without running past the end of the array?
I decided to take a different approach and port the code to a standalone ESP (Adafruit Huzzah). I had to work through some library incompatibilities (one was a Blynk issue - will report this separately) and I rather quickly was able to get the base code up and running. It’s MUCH faster for Blynk operations this way, BTW! Now just waiting for some new parts to arrive to finish it off…
Observation: given the cost (or complexity, if you’re going ESP8266) of adding WiFi to an AVR board, it sure seems a lot simpler and easier to add peripherals like ADCs, shift registers,level shifters, etc to an ESP 8266 module (e.g. an ESP-12E/F) if/as needed rather than deal with the limitations of the AVR microcontroller coupled with the complexity of getting an ESP to work as a WiFi adapter.
EDIT 3/31 - traced down the aforementioned Blynk issue and it turned out to not be an error after all.
