esp32c3

[ccrause]

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.

I checked 5.2.2, there were 75 libraries as part of the esp-idf.  Will investigate at a later stage.

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 ?

Yes, esp32c3 is rv32imc.  Did you configure your project with idf.py set-target esp32c3?

[dbannon]

Yes, esp32c3 is rv32imc.  Did you configure your project with idf.py set-target esp32c3?

That quote came from https://docs.espressif.com/projects/esp-idf/en/stable/esp32c3/migration-guides/release-5.x/5.1/gcc.html

That is esp-idf 5.5 documentation about the esp32c3.  I agree, the c3 is definitely rv32imc, I suspect its a copy and paste error on espressif's part. Their documentation is very high standard usually. Safely ignore !

If you do get around to testing with esp-idf 5.5, here is my compile script, may save you a few minutes (you will need to change defines at the top).

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

1. #!/usr/bin/bash
2.  
3. FPC_COMP="$HOME/bin/FPC/fpc-3.3.1"
4. ESP_TOOLS="$HOME"/.espressif/tools/riscv32-esp-elf/esp-14.2.0_20241119/riscv32-esp-elf
5. ESP_HOME="$HOME/esp_5_5"
6. ESP_VER="5.5"
7.  
8. # This is the rv32imc_zicsr_zifencei and ilp32/no-rtti version.
9.  
10. "$FPC_COMP"/bin/ppcrossrv32 -vix -Tfreertos -XP"$ESP_TOOLS"/bin/riscv32-esp-elf-  -O3 -Wpesp32c3 -WP"$ESP_VER" -Fl"$ESP_HOME"/riscv32-esp32-elf-libs  -Fl"$ESP_TOOLS"/riscv32-esp-elf/lib/rv32imc/ilp32/no-rtti -Fl"$ESP_TOOLS"/lib/gcc/riscv32-esp-elf/14.2.0/rv32imc_zicsr_zifencei/ilp32/no-rtti -Fl"$ESP_TOOLS"/riscv32-esp-elf/lib/rv32imc_zicsr_zifencei/ilp32/no-rtti hello

Davo

[ccrause]

Davo, thank you for your script.  I'm busy wrapping up some updates for AVR, this is taking more time than I expected (like most things that should be quick & easy).  After this merge request is finalized I will dig into this.

[ccrause]

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.

This probably is related to the minimal build setting which is now on by default. To build the whole esp-idf edit the CMakeList.txt file in the project root folder and change the MINIMAL_BUILD setting to OFF:

Code: CMake  [Select][+][-]

1. idf_build_set_property(MINIMAL_BUILD OFF)

[dbannon]

Yes, that might make sense. I thought the build time was (suspiciously ) faster than I expected. Will try that suggestion out later today if I can manage it.

Thanks

Davo

[ccrause]

Some success! Managed to build a blink example using this compiler patch to support esp-idf v5.5 (currently for esp32c3 only)..  The GPIO and delay work, however the write* procedures do not work yet, I need to replace the putchar low level call with something else.  Note also that the compiler may fail when calling esptool.py to generate the binary image from the elf, One can do this last step separately.

The script I used to extract all the needed SDK files is at the bottom (somehow I cannot attach this).  In addition the following library locations are also required for the toolchain libraries:

Code: Text  [Select][+][-]

1. -Fl/home/$USER/.espressif/tools/riscv32-esp-elf/esp-14.2.0_20241119/riscv32-esp-elf/lib/gcc/riscv32-esp-elf/14.2.0/rv32imc_zicsr_zifencei/ilp32/no-rtti
2. -Fl/home/$USER/.espressif/tools/riscv32-esp-elf/esp-14.2.0_20241119/riscv32-esp-elf/riscv32-esp-elf/lib/rv32imc_zicsr_zifencei/ilp32/no-rtti

Code: Pascal  [Select][+][-]

1. program blink;
2.  
3. {$linklib esp_driver_gpio, static}
4.  
5. // Add --allow-multiple-definition to linker command for now
6.  
7. type
8.   Tgpio_config = record
9.     pin_bit_mask: uint32;
10.     mode: integer;         // 0 = disabled, 1 = input,
11.                            // 2 = output, 6 = output open drain
12.     pull_up_en: integer;   // 0 = disabled, 1 = enabled
13.     pull_down_en: integer; // 0 = disabled, 1 = enabled
14.     intr_type: integer;    // 0 = disabled, 1 = positive edge,
15.                            // 2 = negative edge, 3 = any edge,
16.                            // 4 = low level, 5 = high level
17.   end;
18.  
19. const
20.   // GPIO pin number for pin connected to LED
21.   LED = 21;  // TX LED
22.  
23. // Return value is error code, 0 = success
24. function gpio_config(constref gpio_cfg: Tgpio_config): integer; external;
25.  
26. // mode: GPIO_MODE_DISABLE = 0, GPIO_MODE_INPUT = 1, GPIO_MODE_OUTPUT = 2, GPIO_MODE_OUTPUT_OD = 6
27. function gpio_set_direction(gpio_num: integer; mode: integer): integer; external;
28.  
29. // level: Low = 0, High = 1
30. function gpio_set_level(gpio_num: integer; level: uint32): integer; external;
31.  
32. procedure vTaskDelay(xTicksToDelay: uint32); external;
33.  
34. var
35.   cfg: Tgpio_config;
36.  
37. begin
38.   cfg.pin_bit_mask := 1 shl ord(LED);
39.   cfg.mode := 1;
40.   cfg.pull_up_en := 0;
41.   cfg.pull_down_en := 0;
42.   cfg.intr_type := 0;
43.   gpio_config(cfg);
44.  
45.   gpio_set_direction(LED, 2);
46.   repeat
47.     writeln('.');
48.     gpio_set_level(LED, 0);
49.     vTaskDelay(100);
50.     writeln('*');
51.     gpio_set_level(LED, 1);
52.     vTaskDelay(100);
53.   until false;
54. end.

[dbannon]

Sorry, ccrause. Got lost in another project, worked for 3 days and made absolutely no progress. Sigh.

I will hopefully try to catch up to you some time tomorrow.

Davo

[ccrause]

Some success! Managed to build a blink example using this compiler patch to support esp-idf v5.5 (currently for esp32c3 only).

Patch updated to fix watchdog timeout problem due to linking.

[ccrause]

The GPIO and delay work, however the write* procedures do not work yet, I need to replace the putchar low level call with something else

Fixed.

[dbannon]

OK, so I have rebuilt my FPC with your (day old) patch, builds fine and appears to run.

But having trouble with your script to extract out the necessary libraries etc.  Seems to me you are mixing esp32s3 in there ?  Was that intentional ? eg, I see -

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

1. Skipping CMakeFiles
2. cp: cannot stat '/home/dbannon/esp_5_5/esp-idf/hello_world/build/esp-idf/esp_driver_ana_cmpr/libesp_driver_ana_cmpr.a': No such file or directory
3. cp: cannot stat '/home/dbannon/esp_5_5/esp-idf/hello_world/build/esp-idf/esp_driver_bitscrambler/libesp_driver_bitscrambler.a': No such file or directory
4. cp: cannot stat '/home/dbannon/esp_5_5/esp-idf/hello_world/build/esp-idf/esp_driver_dac/libesp_driver_dac.a': No such file or directory
5. ....
6. cp: cannot stat '/home/dbannon/esp_5_5/esp-idf/components/xtensa/esp32c3/libxt_hal.a': No such file or directory
7.  

Looking for the last one (of 17) -

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

1. dbannon@dell:~/esp_5_5/esp-idf/hello_world$ ls -l /home/dbannon/esp_5_5/esp-idf/components/xtensa/esp32c3/libxt_hal.a
2. ls: cannot access '/home/dbannon/esp_5_5/esp-idf/components/xtensa/esp32c3/libxt_hal.a': No such file or directory
3. dbannon@dell:~/esp_5_5/esp-idf/hello_world$ ls -l /home/dbannon/esp_5_5/esp-idf/components/xtensa/
4. drwxr-xr-x 3 dbannon dbannon  4096 Aug 24 15:55 esp32
5. drwxr-xr-x 3 dbannon dbannon  4096 Aug 24 15:55 esp32s2
6. drwxr-xr-x 3 dbannon dbannon  4096 Aug 24 15:55 esp32s3
7. ...

Are you assuming that both CIS and RISC systems are installed ?  Easy to do but I have not yet ....

and /xtensa/esp32c3/ sounds a bit odd ?

On the basis that I am only missing CIS (ie esp32s3) files, I tried to build but get told -

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

1. ...riscv32-esp-elf-ld: cannot find libcoexist.a: No such file or directory

So, manually copied that from esp-idf/components/esp_coex/lib/esp32c3/ and we got a lot further, however the linker fails to resolve esprv_int_enable, esprv_int_disable, esprv_int_set_priority and a few more similar named symbols. Now,  have searched for those symbols without success. Seem to be related to interrupt handler, required by a number of existing libraries. Even exists in the binary the c compiler made in the hello_world demo but I cannot find the library or obj they exist in.

Otherwise, it sounds like you are making great progress, gpio, writeln etc !

Davo

[ccrause]

OK, so I have rebuilt my FPC with your (day old) patch, builds fine and appears to run.

But having trouble with your script to extract out the necessary libraries etc.  Seems to me you are mixing esp32s3 in there ?  Was that intentional ? eg, I see -

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

1. Skipping CMakeFiles
2. cp: cannot stat '/home/dbannon/esp_5_5/esp-idf/hello_world/build/esp-idf/esp_driver_ana_cmpr/libesp_driver_ana_cmpr.a': No such file or directory
3. cp: cannot stat '/home/dbannon/esp_5_5/esp-idf/hello_world/build/esp-idf/esp_driver_bitscrambler/libesp_driver_bitscrambler.a': No such file or directory
4. cp: cannot stat '/home/dbannon/esp_5_5/esp-idf/hello_world/build/esp-idf/esp_driver_dac/libesp_driver_dac.a': No such file or directory
5.  

The script I use performs a general scan of the example/build/esp-idf sub folders and tries to copy a library from each sub folder it finds.  Some libraries (sub folders) are in the esp-idf components folder but are not built for some controllers (like the esp_driver_* files listed above).  Those messages are not necessarily errors, except if something obvious like libesp_common.a is missing.

Code: [Select]

....
cp: cannot stat '/home/dbannon/esp_5_5/esp-idf/components/xtensa/esp32c3/libxt_hal.a': No such file or directory

Looking for the last one (of 17) -

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

1. dbannon@dell:~/esp_5_5/esp-idf/hello_world$ ls -l /home/dbannon/esp_5_5/esp-idf/components/xtensa/esp32c3/libxt_hal.a
2. ls: cannot access '/home/dbannon/esp_5_5/esp-idf/components/xtensa/esp32c3/libxt_hal.a': No such file or directory
3. dbannon@dell:~/esp_5_5/esp-idf/hello_world$ ls -l /home/dbannon/esp_5_5/esp-idf/components/xtensa/
4. drwxr-xr-x 3 dbannon dbannon  4096 Aug 24 15:55 esp32
5. drwxr-xr-x 3 dbannon dbannon  4096 Aug 24 15:55 esp32s2
6. drwxr-xr-x 3 dbannon dbannon  4096 Aug 24 15:55 esp32s3
7. ...

Are you assuming that both CIS and RISC systems are installed ?  Easy to do but I have not yet ....

and /xtensa/esp32c3/ sounds a bit odd ?

Copying the libxt_hal.a shoud probably be put in a conditional expression, since it is specific to the xtensa controllers only.  But I'm not really a shell script enthusiast so I only do the bare minimum. And I keep it there so that I can use the same script for the esp32/s* controllers too.

On the basis that I am only missing CIS (ie esp32s3) files, I tried to build but get told -

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

1. ...riscv32-esp-elf-ld: cannot find libcoexist.a: No such file or directory

So, manually copied that from esp-idf/components/esp_coex/lib/esp32c3/ and we got a lot further, however the linker fails to resolve esprv_int_enable, esprv_int_disable, esprv_int_set_priority and a few more similar named symbols. Now,  have searched for those symbols without success. Seem to be related to interrupt handler, required by a number of existing libraries. Even exists in the binary the c compiler made in the hello_world demo but I cannot find the library or obj they exist in.

The requirement for coexist was removed.  The esprv_* symbols are defined in the rom.api.ld script.  These two changes are in the latest patch.  Unfortunately I amended these changes rather than add it as a separate commit, so it may not be obvious from the commit log.

Otherwise, it sounds like you are making great progress, gpio, writeln etc !

Davo

Finally at the point where I can start a branch in fpc-esp-freertos to work on translating esp-idf v5.5.  Once the basic structure and minimally required units are in place for esp32c3, I will start upgrading the compiler for the other esp controllers.

[dbannon]

OK, I have got to the blink stage. To put your mind a rest, I will confess to a something  should have spotted before my last post !  I downloaded the three files your recent patching changed, copied them into my FPC source tree and ran my esp32c3 build script. Completely forgetting that the script creates a completely new source tree every time it runs....

Sorry !   

All there now. 

I don't fully understand the "fail to link issue". Adding 'python3' ahead of it  makes it run OK and its not marked executable. So, I marked it executable and tried again, it goes into an endless loop !

I guess you know how fpc knows to call esptool.py during the linking stage ...

Another 'issue' ?  On the very common esp32c3-zero board the LED is not connected to gpio21, its either 8 or 10 depending on what you read. But its not 'just' an LED, its a smart one, requiring programming. WS2812, way, way out of scope here I believe.

So, I added my own LED to gpio0 and it all worked as expected.

All good at this stage !  Are you going to push those patches to FPC/fpc main  ?

Davo

[ccrause]

I don't fully understand the "fail to link issue". Adding 'python3' ahead of it  makes it run OK and its not marked executable. So, I marked it executable and tried again, it goes into an endless loop !

I guess you know how fpc knows to call esptool.py during the linking stage ...

FPC calls the esptool after successful linking to create a binary image (that can be flashed to the controller) from the generated elf. FPC calls the esptool version in the provided esp-idf path.  The problem is that the latest esp-idf do not ship a real esptool.py, it uses a stub that calls through to esptool installed in a venv. So one should either recreate the python venv (currently done by snapshot that ships with fpcupdeluxe), or copy the Espressif created one (typically in ~/.espressif) and activate this venv and call the real esptool in the venv.

As a work-around you can install eptool separately, then manually run the elf2bin command to generate the bin file.

Another 'issue' ?  On the very common esp32c3-zero board the LED is not connected to gpio21, its either 8 or 10 depending on what you read. But its not 'just' an LED, its a smart one, requiring programming. WS2812, way, way out of scope here I believe.

I have an example somewhere for the WS2812, using the RMT peripheral (IIRC).

So, I added my own LED to gpio0 and it all worked as expected.

All good at this stage !  Are you going to push those patches to FPC/fpc main  ?

Davo

I was considering waiting until I can update all the controller configurations.  But that may take a long time to complete, so it may be better if I submit the part that is working.

[dbannon]

As a work-around you can install eptool separately, then manually run the elf2bin command to generate the bin file.

The esptool.py we get as part of the sdk works OK if its called by python3. If fpc was to explicit call "python3 esptool.py..." I expect it would work as expected. Or, better still, if fpc was told to not bother calling esptool.py at all (so we don't get an error message) its easy to call it as the next item in a build script. And that does expose the inner working, "compile; link to elf; make.bin from .elf". Thats a good thing imho. 
EDIT: nope, changing the exec process that calls esptool.py so that it calls python3 first does not help. Tried a number of ways, seems it loads esptool.py as a script then tries to load a (c compiled) module of the same name and thats path critical. Just remove it and we can call the real thing as next line in a script.

I have an example somewhere for the WS2812, using the RMT peripheral (IIRC).

That would be cool but not, I suggest, a high priory.

I was considering waiting until I can update all the controller configurations.  But that may take a long time to complete, so it may be better if I submit the part that is working.

Yes, I agree. If you push those patches, I'll update the wiki docs, perhaps spin off a separate esp32c3 page as you suggested. There seems to be some interest out there noting downloads. Stub pages ep32s3, 6 too. Mine should have arrived by now.

I'd like to fine tune your lib collecting script and my compiler building script to work with either (or all) flavours so the installs can live side by side. Make an install simple but leave details easy to see for those who want to.

This is really great work you are doing here ccrause !

Davo

[ccrause]

The patch for esp32c3 was merged into main.