Investigate ESP8266 freeRTOS architecture for Espruino #699
Comments
|
One of the first challenges has been building a FreeRTOS SDK testing environment ... however that seems solved now. The next is actually seeing that Task processing works ... and I can't get it to work ... see the following: http://www.esp8266.com/viewtopic.php?f=6&t=6500&p=33780 Puzzle resolved ... no idea how ... but resolved it is. |
|
After some initial studies, the results seem very promising. The first big surprise is that it appears that the FreeRTOS actually consumes LESS memory than the Espressif non-OS SDK. An app compiled with the non-OS SDK left 40KBytes while the same app compiled with FreeRTOS left 56KBytes of free heap. Initial tests of the sockets() API in FreeRTOS seems to show that they are working exactly as desired. This includes non-preemtive threading which means that we can block on sockets calls while allowing the rest of FreeRTOS to continue. |
|
I do believe that FreeRTOS is the way to go for Espruino because the emw3165 and esp32 will require it, and it also makes sense for esp8266. This is a bit of a larger work item, though, because it needs to be well done. Espruino needs to be modified to play well with interrupt handlers, going to sleep, the timer queue, and other such things with FreeRTOS. The way I would approach it is to grab the latest FreeRTOS and make that work with Espruino without wifi, probably using an ARM platform. Basically learn what all the integration points are and try to isolate the necessary shims into one file or one #define. This way it would hopefully be easy to add the next platform that uses FreeRTOS. I would then add the wifi stuff as a second step. |
|
It this worth keeping open as a ticket? I mean... if someone wants to spend time looking into this then great, but we don't really need a ticket to remind us of this possibility, do we? |
The ESP8266 SDK comes as two flavors. One is called the "non-OS" SDK and contains all the libraries one needs to run an ESP8266 application without a supervisor. The other is the RTOS SDK that is based on "freeRTOS". This uses FreeRTOS as the supervisor technology. Today, the Espruino port to the ESP8266 utilizes the non-OS SDK ... however that choice was made without consideration of the merits of using the FreeRTOS SDK. This issue asks for consideration of the RTOS SDK as an alternative to the non-OS SDK for the ESP8266 port. To do this properly, research will have to be performed on the relative merits of one vs the other as well as future directions of the ESP8266 and ESP32 environments.
One nugget of information that appears to be extremely interesting is that the RTOS SDK leverages a more "exposed" version of the TCP/IP stack which seems to include socket APIs which appear to leverage non-preemtive multi-tasking. In English ... the ability to use a sockets API that appears to block which in fact will not impact the operation of the ESP8266 core.
The text was updated successfully, but these errors were encountered: