Progress, but not where I want it to be. But it builds and installs the FreeRTOS AWS IoT demo.
Building embedded code is a pickle, and you can get totally confused easily. Different examples use different build systems. There’s a whole Arduino ecosystem. Then PlatformIO, that overlaps with Arduino, but also can directly drive a CMake project. Then there’s the chip vendors, such as Espressif, who have their own ecosystem too. Add in FreeRTOS, and the fork that AWS has done, and it gets matrix-math complicated quickly.
I can’t pretend I totally understand, but at least I can reliably build the ESP32 FreeRTOS from AWS demo code now. I wanted to build it all from a makefile external to the tree, but the build tooling depends on setting a ton of environment variables. And make spawns sub-shells, and getting them to inherit all of those correctly has wasted a lot of my time this weekend. So I punted and just write it into a single shell script and called that.
You can see the whole project here: Amazon FreeRTOS ESP32 Helper.
Really it’s just a learning exercise. To actually have a real project you want to structure your code repo differently. More on that another day.
But, in the interest of sharing, there are a few things to know.
I’m using the config helper script provided in the FreeRTOS tree. You fill out a JSON config file and run a python script and it creates the AWS IoT thing, the certs, the policy, and then associates the policy to the cert and the cert to the thing. It also does all the work for you to embed the cert binaries into the header files. Again, this is not for production use but for learning it’s fine.
I don’t think this is documented, and I have not automated around it, but that script does have more features. If you just run the script over and over it will fail, since the thing/certs/policy already exist. But, you can clean it all up like this:
cd amazon-freertos/tools/aws_config_quick_start python SetupAWS.py cleanup
Then you can start over cleanly.
The most important command in the chain is this one:
cmake -DVENDOR=espressif -DBOARD=esp32_wrover_kit -DCOMPILER=xtensa-esp32 -S . -B build -GNinja idf.py build
But… which board do you have? The build system supports a few options:
I’ve never heard of the last one. Here’s a few pages that outline details on many ESP32 boards:
But it really seems to come down to which module is used. There is the new ESP32-C3 that is being sampled and not supported in FreeRTOS anymore, and then basically it looks like the ESP32-D0WDQ6 and ESP32-D0WD. The D means dual core. If it has an S it means Single core, but I can’t seem to find any parts that use that chip. All the boards I have use the ESP32-D0WDQ6:
How do you know what chip your ESP32 uses? You use the ‘esptool read_mac’ command, like this:
gherlein@mars:~/src/aws$ esptool read_mac esptool.py v2.8 Found 1 serial ports Serial port /dev/ttyUSB0 Connecting.... Detecting chip type... ESP32 Chip is ESP32D0WDQ6 (revision 1) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: 3c:61:05:28:dc:64 Enabling default SPI flash mode... MAC: 3c:61:05:28:dc:64 Hard resetting via RTS pin...
That example is for the “D1 Mini” boards ($5 each, Amazon Prime - likely WAY cheaper from Asia).
Anyway, as best as I can tell the ‘esp32_wrover_kit’ is the right parameter to pass into -DBOARD. I need to dig deeper and find out what those other setting really do. This seems to work, and it’s consistent with other examples I have found.
Conclusion and Next Steps
I’ve made good progress and learned a lot. My next step is to learn how to make these work in production. There’s an AWS workshop to build a Connected Drink Dispenser that I may build, or at least model a new code tree from.
I have a lot of things I plan to build, but I am currently wondering if the ESP32 is right for my weather station. I have the sensors and the temp/humidity/pressure and I think I’ll build a single board to interface them all to the ESP32. But that’s a post for another day, for sure.