Re: Compiling mqtt_publisher example with ESP32

Leandro Pereira


On 05/16/2018 10:32 AM, Zach wrote:
The example app implements TLS which is nice, but for Google IoT I need to be able to create JSON and JSON Web Tokens. Are there Zephyr libraries for either of these? Other than that I believe I just need to get the ESP32 connected to wifi, but I need to look into it more as that may be more of an espressif thing rather than a zephyr thing. Any help would be greatly appreciated!
WiFi on the ESP32 is not supported at the moment. Short answer: There are a few technical reasons for this, and making it work will require quite a bit of plumbing.

The long answer:

Zephyr is currently loaded by the first stage bootloader (in the ESP32 mask ROM) into RAM, and is executed from there. The instruction RAM (IRAM) is quite tiny, only a few kilobytes long.

The WiFi stack for ESP32 is immense in comparison. It's also only distributed as a binary object, and linked against Espressif's port of FreeRTOS, with the ABI defined by them, and requiring some features from that OS. Most of these things we can write shims for (e.g. synchronization primitives, memory allocation, this sort of thing), but Espressif is said to be working on an OS-agnostic version of their WiFi stack that would help in this scenario without any sort of hacks.

When you factor the IRAM size and the size of the WiFi stack, you'll end up finding that you need to enable a feature in the ESP32 SoC that's called "flash cache". The hardware will transparently fetch things from the flash memory into an IRAM chunk, execute it from there, and then you can have arbitrarily large code. Sort of, anyway... because this can get tricky with pages not being in the cache and interrupts happening... so we'll have to ensure that the whole Zephyr kernel is in IRAM (so that, for instance, interrupt handlers can use any of the Zephyr API without triggering an interrupt because parts of it aren't in the cached region yet; this can get tricky with our API, especially those with user-defined callbacks such as the GPIO API).

This also requires a second stage bootloader; in other words, ensuring that MCUBoot works on ESP32. It's not a difficult job, but it's one that has to be done to make all this work.

I've also stopped working on the ESP32 port due to many (unrelated) reasons, but I'll be glad to help with code and more details from my findings if anybody wants to take the torch, or coordinate with others that got my brain dump on the subject.


Join to automatically receive all group messages.