esp32c3
lazarus / 77-Embedded

----------------------------------------------------------------------
dbannon · 2025-08-25 06:02

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

Quote from: ccrause on August 23, 2025, 12:50:45 pm...... 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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
dbannon@dell:~/esp448/hello_world$
pwd/home/dbannon/esp448/hello_worlddbannon@dell:~/esp448/hello_world$
find . -name "*.ld"./build/esp-idf/esp_system/ld/memory.ld./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 · 2025-08-25 09:47

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 · 2025-08-25 12:41

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 · 2025-08-25 15:10

Quote from: dbannon on August 25, 2025, 02:41:07 pmDo 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 · 2025-08-27 07:51

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 · 2025-08-27 08:43

Quote from: dbannon on August 27, 2025, 09:51:10 amCode: [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 · 2025-08-28 06:56

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 · 2025-08-29 07:35

Quote from: dbannon on August 28, 2025, 08:56:21 amccrause , 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 · 2025-08-29 10:19

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 · 2025-08-29 11:09

Quote from: dbannon on August 29, 2025, 12:19:49 pmI 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 · 2025-08-30 08:03

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 · 2025-08-30 15:03

Quote from: dbannon on August 30, 2025, 10:03:32 amOK, 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.

QuoteRight, 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.

Quote(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 · 2025-08-31 02:52

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 · 2025-08-31 09:21

Quote from: dbannon on August 31, 2025, 04:52:58 amI 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.

QuoteHow 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.

QuoteWhen 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.)

QuoteSimilarly, 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 · 2025-08-31 12:38

Quote from: ccrause on August 30, 2025, 05:03:41 pmI 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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
dbannon@dell:~/esp_5_5/Projects/Hello$ find ~/.espressif -name
"libc.a" ....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 ?

----------------------------------------------------------------------
ccrause · 2025-08-31 17:10

Quote from: dbannon on August 31, 2025, 02:38:47 pmQuote from: ccrause
on August 30, 2025, 05:03:41 pmI 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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
dbannon@dell:~/esp_5_5/Projects/Hello$ find ~/.espressif -name
"libc.a" ....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.

Quoteedit : 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 · 2025-09-01 01:48

Quote from: ccrause on August 31, 2025, 07:10:04 pmYes, 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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i #!/usr/bin/
bash FPC_COMP="$HOME/bin/FPC/fpc-
3.3.1"ESP_TOOLS="$HOME"/.espressif/tools/riscv32-esp-
elf/esp-14.2.0_20241119/riscv32-esp-
elfESP_HOME="$HOME/esp_5_5"ESP_VER="5.5" # This is the
rv32imc_zicsr_zifencei and ilp32/no-rtti
version. "$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 helloDavo

----------------------------------------------------------------------
ccrause · 2025-09-01 05:48

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 · 2025-09-01 20:29

Quote from: dbannon on August 31, 2025, 02:38:47 pmHmm, 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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
idf_build_set_property(MINIMAL_BUILD OFF)

----------------------------------------------------------------------
dbannon · 2025-09-01 23:51

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 · 2025-09-05 13:20

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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
-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-
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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i program
blink; {$linklib esp_driver_gpio, static} // Add --allow-multiple-
definition to linker command for now type  Tgpio_config = record   
pin_bit_mask: uint32;    mode: integer;         // 0 = disabled, 1 =
input,                           // 2 = output, 6 = output open drain 
  pull_up_en: integer;   // 0 = disabled, 1 = enabled    pull_down_en:
integer; // 0 = disabled, 1 = enabled    intr_type: integer;    // 0 =
disabled, 1 = positive edge,                           // 2 = negative
edge, 3 = any edge,                           // 4 = low level, 5 =
high level  end; const  // GPIO pin number for pin connected to LED 
LED = 21;  // TX LED // Return value is error code, 0 =
successfunction gpio_config(constref gpio_cfg: Tgpio_config): integer;
external; // mode: GPIO_MODE_DISABLE = 0, GPIO_MODE_INPUT = 1,
GPIO_MODE_OUTPUT = 2, GPIO_MODE_OUTPUT_OD = 6function
gpio_set_direction(gpio_num: integer; mode: integer): integer;
external; // level: Low = 0, High = 1function gpio_set_level(gpio_num:
integer; level: uint32): integer; external; procedure
vTaskDelay(xTicksToDelay: uint32); external; var  cfg:
Tgpio_config; begin  cfg.pin_bit_mask := 1 shl ord(LED);  cfg.mode :=
1;  cfg.pull_up_en := 0;  cfg.pull_down_en := 0;  cfg.intr_type := 0; 
gpio_config(cfg);   gpio_set_direction(LED, 2);  repeat   
writeln('.');    gpio_set_level(LED, 0);    vTaskDelay(100);   
writeln('*');    gpio_set_level(LED, 1);    vTaskDelay(100);  until
false;end.

----------------------------------------------------------------------
dbannon · 2025-09-06 10:16

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 · 2025-09-07 06:37

Quote from: ccrause on September 05, 2025, 03:20:03 pmSome 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 · 2025-09-07 08:43

Quote from: ccrause on September 05, 2025, 03:20:03 pmThe 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 · 2025-09-07 12:06

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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i Skipping
CMakeFilescp: 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
directorycp: 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 directorycp: 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....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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
dbannon@dell:~/esp_5_5/esp-idf/hello_world$ ls -l
/home/dbannon/esp_5_5/esp-idf/components/xtensa/esp32c3/libxt_hal.als:
cannot access '/home/dbannon/esp_5_5/esp-
idf/components/xtensa/esp32c3/libxt_hal.a': No such file or
directorydbannon@dell:~/esp_5_5/esp-idf/hello_world$ ls -l
/home/dbannon/esp_5_5/esp-idf/components/xtensa/drwxr-xr-x 3 dbannon
dbannon  4096 Aug 24 15:55 esp32drwxr-xr-x 3 dbannon dbannon  4096 Aug
24 15:55 esp32s2drwxr-xr-x 3 dbannon dbannon  4096 Aug 24 15:55
esp32s3...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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
...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 · 2025-09-07 13:45

Quote from: dbannon on September 07, 2025, 02:06:17 pmOK, 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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i Skipping
CMakeFilescp: 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
directorycp: 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 directorycp: 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 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.

QuoteCode: [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][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
dbannon@dell:~/esp_5_5/esp-idf/hello_world$ ls -l
/home/dbannon/esp_5_5/esp-idf/components/xtensa/esp32c3/libxt_hal.als:
cannot access '/home/dbannon/esp_5_5/esp-
idf/components/xtensa/esp32c3/libxt_hal.a': No such file or
directorydbannon@dell:~/esp_5_5/esp-idf/hello_world$ ls -l
/home/dbannon/esp_5_5/esp-idf/components/xtensa/drwxr-xr-x 3 dbannon
dbannon  4096 Aug 24 15:55 esp32drwxr-xr-x 3 dbannon dbannon  4096 Aug
24 15:55 esp32s2drwxr-xr-x 3 dbannon dbannon  4096 Aug 24 15:55
esp32s3...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.

QuoteOn the basis that I am only missing CIS (ie esp32s3) files, I
tried to build but get told -
Code: Bash  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
...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.

QuoteOtherwise, 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 · 2025-09-08 10:13

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 · 2025-09-08 12:32

Quote from: dbannon on September 08, 2025, 12:13:16 pmI 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.

QuoteAnother '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).

QuoteSo, 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 · 2025-09-09 02:01

Quote from: ccrause on September 08, 2025, 02:32:28 pmAs 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.

QuoteI have an example somewhere for the WS2812, using the RMT
peripheral (IIRC).
That would be cool but not, I suggest, a high priory.

QuoteI 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 · 2025-09-11 04:51

The patch for esp32c3 was merged into main.

----------------------------------------------------------------------
dbannon · 2025-09-11 11:16

Yep, thats great !  I just pulled down a fresh copy and reinstalled,
tested all good.

Davo

----------------------------------------------------------------------
dbannon · 2025-09-19 04:10

OK, so, not surprisingly, Espressif have released an update to SDK
5.5.  Its 5.5.1 and is described as 'Stable' whereas 5.5 is a beta.

I have installed and using pretty much the same model as you worked
out, tested the blink.pas mentioned above. All good except the linker
is called without an explicate path to where memory.ld and sections.ld
are. Its easy enough to add that path with a -L instruction to linker
but I cannot see why its necessary, or, more accurately, I cannot see
how the 5.5 version did not need it.

We still have the linker fail to generate a bin file from the elf
file, still works perfectly if done using a subsequent call to
esptool.py.  If I understood just where the linker gets its
instructions from, I'd disable that call, lets just make the call from
a build script.

Anyway, I'll update the wiki with this information, recommend people
use 5.5.1 and see what else can be done there. I think I will advise
people to move the esp-idf-snapshot up to ESP_HOME. Leaving it down in
the (c code) hello_world directory feels a bit strange to me.

I'd still like to test out the esp32s3 I have now but not sure when !

Davo

----------------------------------------------------------------------
dbannon · 2025-10-26 00:29

Once again, I went off an did what I needed with C. Probably bad C.

Honestly, while FPC can make esp32xx code and thats a great credit to
ccrause and others, its not a working system for several reasons

 Expressif keep releasing new chips. Expressif keep releasing new SDK
We really need the equivalent of the RTL/FCL, a compiler is not
enough.Now, a suggested alternative approach ?  Superficial, not had
time to really investigate but ?

As well as the Expressif SDK, they also support an interface to
Arduino. And Arduino now support "Plugins" to its IDE. So, right now,
its convenient to use the Arduino IDE to develop, compile and upload
code to an ESP32c3 or ESP32s3 boards. Using the Arduino version of C,
no C++, no cmake visible anywhere ! 

So, this Arduino C is a much more static target than Expressif's SDK,
if we were make an interface to it instead, its then up to the
Expressif-Arduino project to support new chips/SDK. And, of course,
other chips/boards that Arduino also, incidentally support.

Arduino have a command line tool that builds and uploads to my
ESP32c3, its a binary rather than a script so not easy to see what its
doing but source is available.

Thoughts ?

EDIT : https://forum.arduino.cc/t/does-it-support-using-a-custom-
linker-script-through-the-command-line/1199591

Davo

----------------------------------------------------------------------
ccrause · 2025-10-26 11:11

Quote from: dbannon on October 26, 2025, 02:29:59 amNow, a suggested
alternative approach ?  Superficial, not had time to really
investigate but ?

As well as the Expressif SDK, they also support an interface to
Arduino. And Arduino now support "Plugins" to its IDE. So, right now,
its convenient to use the Arduino IDE to develop, compile and upload
code to an ESP32c3 or ESP32s3 boards. Using the Arduino version of C,
no C++, no cmake visible anywhere ! 

So, this Arduino C is a much more static target than Expressif's SDK,
if we were make an interface to it instead, its then up to the
Expressif-Arduino project to support new chips/SDK. And, of course,
other chips/boards that Arduino also, incidentally support.

I agree with your motivation for investigating something a bit more
stable than esp-idf.  The problem I expect with the Arduino libraries
is that they are C++ based.  For example the WiFi class uses multiple
inheritance, while the WebServer class uses a generic streamFile
method.

It is not easy to link to these classes directly from FPC.  A short
Delphi centric explanation of why this is not easy (by the late Rudy
Velthuis) Using C++object with Delphi. An older FPC document (refer to
chapter 4) which discusses flattening of the C++ interface.  The
issues with linking against C++ classes may be old, I don't know what
the current status is.

----------------------------------------------------------------------
dbannon · 2025-10-27 10:17

Hmm, yes,  I see. While Expressif does have cpp code, seem the actual
API is all C.  I write just C in the Arduino-ESP32 tests but there
behind is the dreaded cpp.

Interestingly, the arduino command line tool is written in go !
Sigh...

Davo