esp32c3

[dbannon]

ccrause, starting a new thread instead of hijacking wennerer's one.

...... I have done some preliminary checks with S3 and C3 boards and that works with FPC.

thought I'd have a play with my existing esp32c3 modules. So, installed esp_idf 5.5, no problem building the compiler but using it is not good.

Firstly, 5.5 does not seem to make linker scripts for us to pinch. I compiled anyway to see how far I could go,  I get "hello.pas(3,27) Warning: Library driver not found, Linking may fail !" and, unsurprisingly, it does fail but because the scripts are not there.

So, I installed 4.4.8, last of the 4 series thinking it wold be more similar to your 4.3. Same problem, no linker scripts !

Code: Bash  [Select][+][-]

1. dbannon@dell:~/esp448/hello_world$ pwd
2. /home/dbannon/esp448/hello_world
3. dbannon@dell:~/esp448/hello_world$ find . -name "*.ld"
4. ./build/esp-idf/esp_system/ld/memory.ld
5. ./build/esp-idf/esp_system/ld/sections.ld

I guess I am looking for  esp32.ld or esp32c3.ld and esp32.project.ld or esp32c3.project.ld. No sign of either. From memory, last time I played here those scripts appeared during the (c program) build process. 

I did not build a 4.4.8 fpc dependent compiler, no point if I don't have linker scripts.

I would be quite happy to abandon the RISC-V based chips and use the lx7 based eps32s3 if you think that would be simpler.

Thoughts ?

[ccrause]

Since esp-idf v4.4 the linker scripts were renamed to memory.ld and sections.ld.  The compiler will automatically change the required script names according to esp-idf version.

In the master branch the cmake script seems to still output the linker scripts to the ${CMAKE_CURRENT_BINARY_DIR}/ld folder.

[dbannon]

Thanks ccrause !

I'll try that tomorrow.

Do you mind if I update the FPC wiki page with some of these things ? Would be good to it written down .... 

Davo

[ccrause]

Do you mind if I update the FPC wiki page with some of these things ? Would be good to it written down .... 

You are of course welcome to update the wiki 

[dbannon]

OK ccrause some progress.  I can build a basic hello and run it on a esp32c3. And interesting problem, I prefer to use tio to monitor the module output but, apparently, it drops the first line (or so) it gets on the floor. And, remember, the test program writes just one "hello" line and exits. Sigh ...

Anyway, at that level its working. However, thought I'd look at your collection of examples. I find that blink (at least) cannot initialize freertos because its neither lx6 nor FPC_MCU_ESP8266.  The very top of freertos-fpc/esp-idf/freertosconfig.inc :

Code: [Select]

{$if defined(CPULX6)}
  {$include esp-idf/sdkconfig.inc}
{$elseif defined(FPC_MCU_ESP8266)}
  {$include esp8266-idf/sdkconfig.inc}
{$else}
  {$ERROR Unknown sub architecture, cannot decide which idf folder to include}
{$endif}
The esp32c3 is SUBARCH=rv32imc. Is that what we are talking about here ?

Does this mean your bindings there are not yet ready for the esp32c3 ? The lx7 based esp32s3 ?  My guess is lx6 would be similar but not identical to the lx7. For that matter, maybe lx6 = lx7 = rv32imc at the level of source code in the examples ??

Don't get me wrong here, I understand how hard it would be to keep track of these things, new version of both hardware and software faster than we can type !

Davo

[ccrause]

Code: [Select]

{$if defined(CPULX6)}
  {$include esp-idf/sdkconfig.inc}
{$elseif defined(FPC_MCU_ESP8266)}
  {$include esp8266-idf/sdkconfig.inc}
{$else}
  {$ERROR Unknown sub architecture, cannot decide which idf folder to include}
{$endif}

As you realized this is not really a flexible design choice.
a) It assumes that the SDK libraries were built with the static sdkconfig list of options.
b) Nowadays there are many more mcu options that should be handled.

To fix a), one needs to copy the SDK example configuration file (sdkconfig) and convert it to a Pascal include file (I have a shell script for this, can share that when I'm home later today) that is stored in a mcu specific path (e.g. the libs folder which should be sorted per mcu).  To fix b) do not specify the relative path the the sdkconfig.inc file in source code, but specify it using the compiler -Fi option.

I will create a new branch (may only get to that this weekend) for the new design so that we can start fixing these issues and document the requirements.

[dbannon]

ccrause , I really wonder if, log term, its worth the effort ?  As I understand it, my problem is the RISC modules, the CIS ones using lx7 cores are probably little or no effort to adapt from lx6.  I worry you might be spreading yourself just a bit too thin trying to support the existing diversity and its only going to get more diverse.

I consider it quite acceptable to say that FPC can generate riscv32 code (and you have demonstrated that, I will document it). However, the "next software layer up" and the examples you provide concentrate on lx6 and its derivatives.

Espressif now have cheap single core and slightly dearer multicore lx7 chips. They support all the same features as the riscv32 ones (but use sightly more power). Lets just concentrate on lx6 and lx7 (and lx8...). I'll order some esp32s3 modules to play with, they are dual core with all the bell and whistles. And cheaper that the c3 I purchased a year ago !

Davo

[ccrause]

ccrause , I really wonder if, log term, its worth the effort ?  As I understand it, my problem is the RISC modules, the CIS ones using lx7 cores are probably little or no effort to adapt from lx6.  I worry you might be spreading yourself just a bit too thin trying to support the existing diversity and its only going to get more diverse.

The incremental effort to support different architectures and different controllers is not so much.  Espressif has refactored esp-idf so that it nowadays has a clear separation between controller specific code and general code for the SDK.  So once we figure out how to cleanly handle one controller we can use the same recipe for the others.

[dbannon]

Its you call mate ! Just don't spread yourself too thin.

I have documented what I have learnt about the esp32c3 and your mods in FPC. Pretty  wordy I am afraid, maybe it needs its own page ?

https://wiki.freepascal.org/Xtensa#ESP32c3

Davo

[ccrause]

I have documented what I have learnt about the esp32c3 and your mods in FPC. Pretty  wordy I am afraid, maybe it needs its own page ?

https://wiki.freepascal.org/Xtensa#ESP32c3

Davo

Thanks Davo!  I think wordy is better than leaving something unsaid.  Also the Xtensa wiki page probably needs to be refactored - it started as a howto for xtensa controllers + esp-idf, now I think it should split into an architecture dependent bit (xtensa page and riscv page) and a more generic esp-idf page.

PS: I noticed you used esp-idf v4.4.8. I experienced issues with the v4.4 branch and wifi for esp32 (using FPC).  At the time it appeared to be a library linking sequence issue which I couldn't sort out, even though a similar C example compiled via the SDK worked correctly.  Keep this in mind when you test wifi connectivity.

[dbannon]

OK, so, decided to have a play this afternoon.

Edit your esp-idf/freertosconfig.inc to know about a (slightly modified) rv32imc-esp-idf/sdkconfig.inc but still using all the other files in esp-idf.  And we started compiling but complained bitterly when it found assembly code in esp-idf/portmacro.pp !

I guess its not unreasonable for a RISC core to need different asm to CIS one !   

Right, another issue. If you don't suggest using esp-idf 4.4.8, what should  use ? I have 5.5 installed but FPC says not supported. You were using 5.0.6 last time you played publicly ?

(think I'll order those ESP32s3 I mentioned, heaps better chips and the asm for them already exists ! I have not done asm since Uni, a very long time ago.)

Davo 

[ccrause]

OK, so, decided to have a play this afternoon.

Edit your esp-idf/freertosconfig.inc to know about a (slightly modified) rv32imc-esp-idf/sdkconfig.inc but still using all the other files in esp-idf.  And we started compiling but complained bitterly when it found assembly code in esp-idf/portmacro.pp !

I guess its not unreasonable for a RISC core to need different asm to CIS one !   

Indeed! Since this is a portability layer (the interface between freertos and the hardware) this unit should be moved to an architecture dependent folder.

Right, another issue. If you don't suggest using esp-idf 4.4.8, what should  use ? I have 5.5 installed but FPC says not supported. You were using 5.0.6 last time you played publicly ?

I think Michael Ring and I tested the compiler (high level, no detailed testing!) up to esp-idf v5.2.  However the compiler should accept higher esp-idf versions, it will just use the same recipes as for v5.2.

(think I'll order those ESP32s3 I mentioned, heaps better chips and the asm for them already exists ! I have not done asm since Uni, a very long time ago.)

Davo

The assembly routines in portmacro can also be found in the esp-idf source code.  The challenge is to convert from GCC inline assembler to straight assembler.

[dbannon]

I will move back to my esp-idf 5.5 install and see how we go.

Restructure ? Hmm, something like this -

Code: [Select]

fpc-esp-freertos
    freetoc-fpc
         |---  // all the none HW specific files
         |     sdkconfig.pp
         |     portmacro.pp
         |---  riscv32
         |       |--- c3   
         |       |--- c5    // if it turns out needed
         |       |--- c6
         |       |--- sdkconfig.inc
         |       |--- portmacro.inc
         |---  xtensa
         |       |--- lx6   // or is core type a better critea ?
         |       |--- lx7
         |       |--- sdkconfig.inc
         |       |--- portmacro.inc
         |---  <esp8266?>
    examples
    ...
How does various versions of esp-idf fit in ?
When my esp32s3 arrives, and I can test existing model, I could start sending you pull requests towards a restructure. But  need to know what works now first. Don't seem to be able to purchase esp32 locally, plenty of people advertising them but when you look closely, they are the cheaper c3. IMHO, the s3 is direct descendant of the esp32.

Do you think we will need much extra code to support, eg c5 and c6 once c3 is sorted ?

Similarly, esp-idf versions ?  I consider diversity a good thing but not in this case !

Davo 

[ccrause]

I will move back to my esp-idf 5.5 install and see how we go.

Restructure ? Hmm, something like this -

Code: [Select]

fpc-esp-freertos
    freetoc-fpc
         |---  // all the none HW specific files
         |     sdkconfig.pp
         |     portmacro.pp
         |---  riscv32
         |       |--- c3   
         |       |--- c5    // if it turns out needed
         |       |--- c6
         |       |--- sdkconfig.inc
         |       |--- portmacro.inc
         |---  xtensa
         |       |--- lx6   // or is core type a better critea ?
         |       |--- lx7
         |       |--- sdkconfig.inc
         |       |--- portmacro.inc
         |---  <esp8266?>
    examples
    ...

Yes, this the kind of the structure I was thinking of.  Whether one needs subarch specific or controller specific folders is not yet clear.  It appears that esp-idf tends to group configurations per controller so maybe start with that (esp32, esp32s3 esp32c3 etc sub folders), grouped per riscv/xtensa.

How does various versions of esp-idf fit in ?

I suggest a clean break and start from the latest stable version 5.5 in a branch.  After this is more or less stable, we can park the current master branch as a legacy v4.3.7 branch and change the new branch as the master.

When my esp32s3 arrives, and I can test existing model, I could start sending you pull requests towards a restructure. But  need to know what works now first. Don't seem to be able to purchase esp32 locally, plenty of people advertising them but when you look closely, they are the cheaper c3. IMHO, the s3 is direct descendant of the esp32.

Do you think we will need much extra code to support, eg c5 and c6 once c3 is sorted ?

Practically the main work to add a controller is to port the controller specific files.  This should be much less effort compared to porting the application layer libraries (wifi, http, GPIO etc.)

Similarly, esp-idf versions ?  I consider diversity a good thing but not in this case !

Davo

+100! I tried to keep up with newer releases but the effort of identifying changes, patching the code to support multiple versions, and testing the compiler linker recipes have taken up more time than I can spend on this aspect.

[dbannon]

I think Michael Ring and I tested the compiler (high level, no detailed testing!) up to esp-idf v5.2.  However the compiler should accept higher esp-idf versions, it will just use the same recipes as for v5.2.

Hmm, not sure. The library list seems to have changed significantly in 5.5. With the v5.5 esp-idf I ended up with only 54 files in riscv32-esp32-elf-libs. With v4.4.8 there were 94. Noticeably absent are

Code: [Select]

bannon@dell:~/esp_5_5/Projects/Hello$ for LIB in `cat missing_lib`; do echo $LIB; find ~/esp_5_5 -name $LIB; find ~/.espressif -name $LIB; done
libdriver.a
libesp_coex.a
libesp_phy.a
libesp_ringbuf.a
libvfs.a
libesp_gdbstub.a
libespcoredump.a
Further (but manageable), they appear to have added another clause to the paths under the .espressif/tools -

Code: Bash  [Select][+][-]

1. dbannon@dell:~/esp_5_5/Projects/Hello$ find ~/.espressif -name "libc.a"
2. ...
3. .espressif/tools/riscv32-esp-elf/esp-14.2.0_20241119/riscv32-esp-elf/riscv32-esp-elf/lib/rv32imc_zicsr_zifencei/ilp32/no-rtti/libc.a

Do you have any idea what rv32imc_zicsr_zifencei means ?  While there are heaps of libraries down there, the path I quote seems to be the best bet. The rv32imc I am comfortable with, the zicsr_zifencei ?? I cannot FPC compile to test.

But the real issue IMHO is those missing libraries. Says things have changed. I can (obviously) compile, flash and run the c hello app.

Davo

edit : Espressif  Documentation : The RISC-V extensions zicsr and zifencei have been separated from the I extension. GCC 12 reflects this change, and as a result, when building for RISC-V ESP32 chips outside of the ESP-IDF framework, you must include the _zicsr_zifencei postfix when specifying the -march option in your build system.

Code: [Select]

riscv32-esp-elf-gcc main.c -march=rv32imac
Hmm, thats interesting. "rv32imac" ?  I thought I was dealing with rv32imc ?