ESP32 Forum

Kind folks,

I am interested in porting an existing single-threaded firmware package, written in C, from the ESP32-S2 to an ESP32, initially to run in a single core (with the second core idle). What are the obstacles which need to be overcome, your estimate of their difficulty, and your advice on how to overcome them?

I anticipate difficulties in the following areas (as well as the obvious ones of pinout differences and memory sizes):

• MCU Core: Tensilica 7 vs. 6, differences in instruction set and timing,
• Differences in register sets and function,
• Structural differences in memory layout and function (not just simple location differences),
• Differences in interrupt and fault handling,
• Differences between like-peripheral programming and performance (i.e., only considering peripherals common to both devices)
• In devices with extra cores (e.g., the ESP32), what's the easiest and safest way to keep the extra core(s) in an idle state?

Have any of you developed a set of working rules for writing cross-variant portable code?

I'm hoping that based on your feedback, I can limit my detailed study to a small portion of the rather large set of documentation in the device data sheets.

Thank you in advance,

Mike

It very much depends on what your firmware is doing. Is it doing an equivalent of e.g. connecting to WiFi to turn on and off a LED depending on what a server tells it to do, is everything properly coded to use the public APIs and are you not using any peripherals that are only available on one of the cores? Run 'idf.py set-target [new chip name]', build, flash, and you're done. Stuff like extra cores will be taken care of automatically (either by idling those cores, or distributing tasks between the two), drivers will take care of the implementation differences between peripherals and life in general will be good and you won't need to change a single line of your code.

On the other hand, if you have decided to handcode your program entirely in assembly, bit-banging the registers of the peripherals you need directly and assuming code executes in x cycles instead of doing proper timing... yeah, you'll have some porting to do.