ok , I agree there is stuff broken in the ESP 32 targets at the moment (although @rgomezwap work is moving it forward greatly). I suppose what im saying is how to fix it. Saying it a different way , my proposal is to Invest now, start a fresh and , build a new 5.1 (say) idf sdk espruino port to drive all the current esp targets. A clean slate, without the #idefs for each of the current idf variants and test it once for each target. Using @rgomezwap work, the Arduino core and the micropython /circuit pythons esp32 library as guides for this build.
This approach is as opposed to moving the original esp32 to 4.x (persisting with the complication of TARGET/IDF VERSION ifdefs) , testing it and then later moving , it and other variants to 5.x , testing again etc.
My understanding (and i could be wrong and im learning from scratch here) is that one version of the application and using the config files for the target differences is how the ESP IDF is intended to be used , using macros and #ifdefs defined from the config files for the variants.
(anyone know otherwise ??) see here how circuit python (running on idf v5.3) sets up the config files. see attached also.
but im still not sure, if this is correct, or if i can make an impact (and there does not seem to be many others with the time/inclination to work on this. @rgomezwap excepted. )
So I am currently trying to prove my understanding above AND understand what a compilable vanilla version (eg all peripherial jswraps pointing to empty functions) of Espruino looks like for the basis of the clean sheet* (eg I got yesterday a cflow report of the function calls from app_main)
and then looking at other applications like micro-python , circuit python and esp32 Arduino core to try to understand their approach. And also a good espruino/esp32 test set is needed !?
if anyone has a vanilla espruino version , I would be great full to see it ( i do see the headers in jshardware.h as a clue. )
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
ok , I agree there is stuff broken in the ESP 32 targets at the moment (although @rgomezwap work is moving it forward greatly). I suppose what im saying is how to fix it. Saying it a different way , my proposal is to Invest now, start a fresh and , build a new 5.1 (say) idf sdk espruino port to drive all the current esp targets. A clean slate, without the #idefs for each of the current idf variants and test it once for each target. Using @rgomezwap work, the Arduino core and the micropython /circuit pythons esp32 library as guides for this build.
This approach is as opposed to moving the original esp32 to 4.x (persisting with the complication of TARGET/IDF VERSION ifdefs) , testing it and then later moving , it and other variants to 5.x , testing again etc.
My understanding (and i could be wrong and im learning from scratch here) is that one version of the application and using the config files for the target differences is how the ESP IDF is intended to be used , using macros and #ifdefs defined from the config files for the variants.
(anyone know otherwise ??) see here how circuit python (running on idf v5.3) sets up the config files. see attached also.
but im still not sure, if this is correct, or if i can make an impact (and there does not seem to be many others with the time/inclination to work on this. @rgomezwap excepted. )
So I am currently trying to prove my understanding above AND understand what a compilable vanilla version (eg all peripherial jswraps pointing to empty functions) of Espruino looks like for the basis of the clean sheet* (eg I got yesterday a cflow report of the function calls from app_main)
and then looking at other applications like micro-python , circuit python and esp32 Arduino core to try to understand their approach. And also a good espruino/esp32 test set is needed !?
1 Attachment