ESP32-C3 mini

Has anyone successfully flashed Espruino on this chip?

4 Attachments

Hi, nice tiny ESP32 board. There is no build for board other than the ESP32 Series. There is only very little support by the community. You are wellcome to support. Check to open issues for ESP32 on github and let us know if and how you like to support.

I would love to see a firmware for this platform as well, however it seems that it is a bit different than the other ESP32. Native USB (instead of a USB to serial chip on the board) and RISC-V processor...

Yes - I'd love to support ESP32-C2/C3 at some point, but they are not supported at the moment.

I believe Espruino will run on RISC-V (there was at least one port that didn't require any real changes to the interpreter) so it's mainly a matter of getting it built with Espressif's newer SDKs I think.

so it's mainly a matter of getting it built with Espressif's newer SDKs I think.

Yes 3.3.6 ist not supporting this type, ESP-IDF 5.x would work.

Did someone tried to build Espruino with help of Platformio, or is this impossible?

https://github.com/rgomezwap/EspruinoS3

I guess this could be used as a starting point for a build environment for the ESP32-Cx.

Thanks - I guess I'll have to try and find some time to look into it. There must be a way to use the IDF without rewriting the build system just for it - even if it's only to create a CMakeList and then call idf.py

That would be great!

ESP32 Series Comparison (As of 2024)

Key Takeaways

• ESP32: Continues as a versatile choice for a wide range of applications, offering robust memory and processing capabilities.
  
• ESP32-C3: Provides an efficient, cost-effective solution for simple IoT devices that require Wi-Fi, Bluetooth, and USB OTG capabilities.
  
• ESP32-C5: Steps up as a dual-core RISC-V processor with improved Wi-Fi and Bluetooth, ideal for high-performance IoT applications that also require USB OTG support.
  
• ESP32-S3: Offers advanced AI capabilities and rich I/O options, suitable for applications requiring machine learning and USB OTG support.
  
• ESP32-P4: Newer model with enhanced AI capabilities and superior connectivity options, including USB OTG support, designed for demanding IoT applications.
  
• ESP32-H2: Focuses on connectivity for smart home applications using Bluetooth 5, Thread, and Zigbee, perfect for non-Wi-Fi dependent setups.
  

I am quite sure ESP32-C3 has USB built-in, where did you get this comparison chart from?

Did it myself, just my mistake :) Doing in in a hurry.
...fixed it ;) Thx for the review :)

check this page for idf-release-and-soc-compatibility and this one for -C3 details

...fixed it ;)

Actually you was probably right before. C3 does not have USB OTG. It only has fixed function USB CDC Serial + JTAG. So no generic purpose USB that could do HID or mass storage or anything. So USB is there just for flashing and console so you don't need to have usb to serial chip on devboard. S3 has same fixed serial/jtag interface + USB OTG on same pins so you need to select at runtime one or another (you can't have both) but C3 only has that fixed function one.

Hello,

some time ago, I worked on bringing Espruino to ESP-IDF 4.x and 5.x.
Adapting the hardware code is not very difficult for me. But integrating it into the current BUILD system became impossible due to my limited knowledge in this area.

Following this thread, and the interest in the C3, I wanted to give it a try. With ESP-IDF 4.4.7 and minimal Espruino (removing extra modules and disabling incompatible or pending hardware configuration), I successfully built it.

I don't have any ESP32-C3 board available, so I can't test it. I'm going to order one from China to see if it really boots.

We can work collectively to add those chips into the current Espruino. My current interest lies in ESP32-C5 and ESP32-P4, but to support these new chips, ESP-IDF 5.x is required, which is a bigger challenge that I haven't yet overcome.

That sounds great! I know IDF 5 will be different, but hopefully some of what you did for 4.4.7 will still apply. I think if we're going to all this effort we should really try and target IDF 5 as it provides the widest support.

Did you manage to get it building within the existing Makefile framework?

I know someone put a lot of work into https://github.com/rgomezwap/EspruinoS3, but because it throws out the whole old build system it's not something I could pull back in to the main project - and I'm not willing to completely re-architect Espruino for it as it's got to support a bunch of different hardware alongside ESP32.

I know at the moment we have this system where we precompile the IDF which we then download and include in the build. Computers have got a bit more powerful since that went in, and I imagine if that's making it difficult we could ignore that and just build it each time without it being a total nightmare.

Just looking again at https://docs.espressif.com/projects/esp-­idf/en/stable/esp32/get-started/linux-ma­cos-setup.html#configure-your-project they really seem to want you to use the idf.py, and it seems fighting against that might be an uphill battle, making it hard for us to upgrade to later versions.

I'd be interested to know how you got 4.4.7 working but it feels a lot like we can modify the ESP32 makefile for Espruino to auto-generate a CMakeLists.txt for each target like https://github.com/rgomezwap/EspruinoS3/­blob/main/make/esp32idf4/main/CMakeLists­.txt and then just call the idf.py to build everything.

So you still call BOARD=ESP32C3 make if you want to build it, and that'll generate all the files in gen for Espruino, and will then call into idf.py to finally build everything - but honestly that feels like it'll tidy up the ESP32 build system a lot anyway.

I got my ESP32-C3 and will try a build with 4.4.7 on a Ubuntu.

modify the ESP32 makefile for Espruino to auto-generate a CMakeLists.txt

that definitely will help

I just did a very quick hack at https://github.com/espruino/Espruino/com­pare/master...gfwilliams:Espruino:esp32_­idf_5?expand=1 shamelessly based off of https://github.com/rgomezwap/EspruinoS3/­tree/main for now (eventually we can make the Espruino makefile create the CMakeList)

It doesn't fully build, but it doesn't look completely impossible as most things appear to be minor renamings or changing defines for functions. As you noted @MaBe the mbedtls version is different and we could look at updating Espruino, but just to get the build working for now we can disable TLS I think.

I guess we should probably look at that repo and try and figure out what changes were made to the other source files (we'll have to try and figure out which commit it was based on and then manually diff it). It may be quite a bit of the work has already been done there.

Hello,

I'm the same person as the one from rgomezwap's GitHub. I signed up on the forum using my GitHub login, but it seems to have assigned me a random username.

I've updated the GitHub version to ESP-IDF 4.4.7, and everything is still working fine. Then, I installed the build system for ESP32-C3. When I tried to build, I encountered a bunch of errors which I've been fixing: either by commenting out the problematic parts to fix them later, or by making changes based on the suggestions provided by the compiler. As for the Espruino core source files, it compiles without any issues or fixes.

I've tagged these changes (all related to hardware) so that I can revisit them later and analyze each one to ensure ESP-C3 compatibility.

The idea of transforming the current makefile system to the IDF system on the fly, is a good one.
For me i find the current system confusing ,to carry out this task myself. Especially since it's shared across many different hardware configurations.

On the other hand, performing a full build with IDF is easy and fast. I don't see any drawbacks; you just need to have the entire SDK downloaded, but IDF takes care of everything.

The source files that need to be changed from the current Espruino, I've identified them very well, and there are very few things to modify. The main issue lies with the BUILD system; regarding the source files.

I also find it easy to maintain dual compatibility with 3.3.6 and 4.4.7 through defines in the source files. Although I've noticed a significant improvement in stability with the 4.x series compared to the 3.x series.

Great that you are back

I also find it easy to maintain dual compatibility with 3.3.6 and 4.4.7 through defines in the source files. Although I've noticed a significant improvement in stability with the 4.x series compared to the 3.x series.

Nice

@user110663
How do you handle with 3.3.6 and 4.4.7 at the same time? Do you just rename folders?

Hello Mark, I don't mean being able to build both versions on the same computer.

What I mean is that version 3.3.6 is very stable, with all the hardware adaptation and testing completed. As for versions 4.x and 5.x, the functionality of the hardware SDK is different (SPI, LEDC, DMA, FreeRTOS, ADC...) and it will take us some time to get it ready.

If, while we prepare versions 4.x and 5.x, version 3.3.6 remains valid through conditional defines, we can generate binaries for all three versions at any time with the latest versions of the source files.

instead of esp I try to use something like this markbecker@vmux091:~/esp/v4.4.7$

Edit: cloned @Gordon branch and working on this.