ESP32-C3 riscv32 lazarus / 77-Embedded ---------------------------------------------------------------------- dbannon · 2024-05-16 05:42 This is a follow on from https://forum.lazarus.freepascal.org/index.php/topic,67252.msg517455 The wiki page, https://wiki.freepascal.org/Xtensa talks about the esp32 but the esp32-c3 is much more common now, substantially cheaper IMHO. (It too is marked as legacy, such is the market for such things). The esp32-c3 is a different beast from the esp32, the -c3 gets you a riscv32 chip. The above mentioned wiki article suggests the use of espressif tool kit and model, and using their base C libraries to access the specialist functions these chips have. So, thought I'd give it a try. Sort of, works, with the disclaimer that my hardware has not arrived yet so not tested ! And my generated binaries are suspiciously small. And some serious problems needing ugly workaround, better solutions would be very, very welcome ! Several stages - Install the espressif tool kit, it has some system dependencies, a git tree and then a hidden directory containg some generated stuff. Pretty easy. Walks you through building an example binary. https://docs.espressif.com/projects/esp- idf/en/stable/esp32c3/index.html Building a riscv32 FPC compiler and rtl. Based on https://wiki.freepascal.org/Xtensa Building a Hello World FPC app - and here there be dragons ! Jump to second stage, I easily built what I think might be a esp32c3 compiler, based on fpc-main, dedicated to esp32-c3, I built a x86_64 in the conventional way first and then, the source directory (where the Makefile lives) - Code: [Select]$> make FPC=~/bin/FPC-esp32/fpc-3.3.1/bin/fpc  CPU_TARGET=riscv32 OS_TARGET=freertos  SUBARCH=rv32imc    "CROSSOPT=-XPriscv32-esp-elf- -Cfsoft" all -j $> cp compiler/ppcrossrv32 ../../fpc-3.3.1/bin/. $> make crossinstall FPC="$FPC_DIR"/bin/ppcrossrv32  CPU_TARGET=riscv32 OS_TARGET=freertos  SUBARCH=rv32imc  INSTALL_PREFIX="$FPC_DIR" That was easy, I ended up with a ppcrossrv32 binary and a whole lot of compiled units in ~/bin/FPC-esp32/fpc-3.3.1/units/riscv32-freertos/ that seemed to be what I expected - Code: [Select]$> file /home/dbannon/bin/FPC- esp32/fpc-3.3.1/units/riscv32-freertos/rtl/system.o /home/dbannon/bin/FPC- esp32/fpc-3.3.1/units/riscv32-freertos/rtl/system.o: ELF 32-bit LSB relocatable, UCB RISC-V, RVC, soft-float ABI, version 1 (SYSV), not stripped But after that, things get muddy.  I could compile but not link. And the reason seems to be that the espressif supplied linker has some funny ideas how to use the FPC linker script.  The compiler makes a nice linker script with absolute paths to all the necessary object files, but the the linker  insists on prepending a path of its own devising. See tail end of a compile run  (-va  and -k" --verbose") here - 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 $> /home/dbannon/.espressif/tools/riscv32-esp- elf/esp-13.2.0_20230928/riscv32-esp-elf/bin/riscv32-esp-elf-ld -g   --verbose   --gc-sections   -L. -o hello.elf -T link289829.resGNU ld (crosstool-NG esp-13.2.0_20230928) 2.41...opened script file link289829.resusing external linker script:=========================== =======================SEARCH_DIR("/home/dbannon/.espressif/tools/risc v32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/riscv32-esp- elf/lib/")SEARCH_DIR("/home/dbannon/bin/FPC-esp32/fpc- 3.3.1/lib/fpc/3.3.1/units/riscv32- freertos/rtl/")SEARCH_DIR("/home/dbannon/bin/FPC- esp32/fpc-3.3.1/bin/")INPUT (hello.o/home/dbannon/bin/FPC-esp32/fpc- 3.3.1/lib/fpc/3.3.1/units/riscv32- freertos/rtl/system.o/home/dbannon/bin/FPC-esp32/fpc- 3.3.1/lib/fpc/3.3.1/units/riscv32- freertos/rtl/esp32c3.o/home/dbannon/bin/FPC-esp32/fpc- 3.3.1/lib/fpc/3.3.1/units/riscv32- freertos/rtl/consoleio.o/home/dbannon/bin/FPC-esp32/fpc- 3.3.1/lib/fpc/3.3.1/units/riscv32- freertos/rtl/heapmgr.o)....=========================================== =======/home/dbannon/.espressif/tools/riscv32-esp- elf/esp-13.2.0_20230928/riscv32-esp-elf/bin/riscv32-esp-elf-ld: mode elf32lriscvattempt to open hello.o succeededhello.oattempt to open /home/dbannon/.espressif/tools/riscv32-esp- elf/esp-13.2.0_20230928/riscv32-esp-elf/bin/../riscv32-esp- elf/home/dbannon/bin/FPC- esp32/fpc-3.3.1/lib/fpc/3.3.1/units/riscv32-freertos/rtl/system.o failed/home/dbannon/.espressif/tools/riscv32-esp- elf/esp-13.2.0_20230928/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find /home/dbannon/bin/FPC- esp32/fpc-3.3.1/lib/fpc/3.3.1/units/riscv32-freertos/rtl/system.o: No such file or directoryattempt to open /home/dbannon/.espressif/tools/riscv32-esp- elf/esp-13.2.0_20230928/riscv32-esp-elf/bin/../riscv32-esp- elf/home/dbannon/bin/FPC- esp32/fpc-3.3.1/lib/fpc/3.3.1/units/riscv32-freertos/rtl/system.o failed... I could find no way to tell FPC to not supply the full path nor to tell tell the linker that the full path is there, use it ! So, in the end, I created a (crazy) directory structure below where the linker insists on looking with symlinks to the (few) needed files. Thats was good, it build an elf file, but a very, very small one, 4688 bytes ?? Anyway, no .bin file because, after linking, FPC somehow calls Code: [Select]$> /home/dbannon/bin/esp/esp- idf//components/esptool_py/esptool/esptool.py --chip esp32c3 elf2image --flash_mode dio --flash_freq 80m --flash_size 4MB --elf-sha256-offset 0xb0 --min-rev 3 -o hello.bin hello.elf But esptools is not executable, running it by hand (ie with python3) does make the hello.bin but its only 64bytes ??  That cannot be right but currently, no hardware! So, I wait .... In summary, three issues Crazy Linker problem. FPC calls esptools (how does FPC know esptools even exits ?) Resulting binaries appear to be too small to be useful. Any comments very welcome ! ---------------------------------------------------------------------- MiR · 2024-05-16 07:52 ccrause is definitely the expert here... but have you already checked if the linker code in ./compiler/systems/t_freertos.pas is correctly configured? There are currently two possible defines that may be active, XTENSA and RISCV32 and in the end it may be that you need code from both to get proper linking. likely XTENSA is not set at all but it should contain all the required linker settings that will likely have to go into the RISCV32 code sections. This may explain why your result is so small, currently close to nothing is defined in the linker script for RISCV32 ---------------------------------------------------------------------- ccrause · 2024-05-16 10:34 I have started testing the build process for esp32c3.  There appears to be a few missing pieces in the compiler for handling the interaction with the esp-idf SDK for riscv32.  This is required for correct linking of the final binary image.  I will update this thread once I have a fix, or at least a better grasp of what is going on. ---------------------------------------------------------------------- ccrause · 2024-05-16 10:48 Quote from: dbannon on May 16, 2024, 07:42:53 amSo, thought I'd give it a try. Sort of, works, with the disclaimer that my hardware has not arrived yet so not tested ! And my generated binaries are suspiciously small. Consider testing with Espressif's qemu fork for esp32c3.  This is especially useful for testing logic (as opposed to interacting with hardware).  It should output write(ln) statements, at least it does for esp32. ---------------------------------------------------------------------- Fibonacci · 2024-05-16 10:49 Would love to code these bad boys in FPC ---------------------------------------------------------------------- dbannon · 2024-05-16 10:52 One thing I noted, after Michael prompted, the code in ./compiler/systems/t_freertos.pas that writes out default linker scripts does not seem to be happening. I am not entirely sure where they appear, I suspect ~/bin/esp/riscv32--esp32-elf-libs in my case. Its where the espressif's *.a files are copied to make them afailable to FPC. But, truth is, they are not appearing. That code is active if RISCV32 is defined but in my test compile, it does not seem to be (but CPURISCV32 is). I tried adding it as a -d define but no help. Davo ---------------------------------------------------------------------- dbannon · 2024-05-17 02:34 Just to clarify, there is some (considerable ?) code in compiler/systems/t_freertos.pas that is clearly intended to write some default linker scripts and other config files for the riscv32. However, that code is not called. Its in TlinkerFreeRTOS.GenerateDefaultLinkerScripts of which there several, each wrapped in their own {$ifdef SOMECPU} tags. Down in TlinkerFreeRTOS.MakeExecutable , there is an {$ifdef XTENSA} block for example that calls GenerateDefaultLinkerScripts, but if we have RISCV32 defined, no such call is made. I have confirmed that RISCV32 is defined at that stage, I guess its "just" a case of implementing whats necessary guided by the way its done for XTENSA ? Davo Davo ---------------------------------------------------------------------- ccrause · 2024-05-17 05:00 Quote from: dbannon on May 17, 2024, 04:34:56 amJust to clarify, there is some (considerable ?) code in compiler/systems/t_freertos.pas that is clearly intended to write some default linker scripts and other config files for the riscv32. However, that code is not called. Its in TlinkerFreeRTOS.GenerateDefaultLinkerScripts of which there several, each wrapped in their own {$ifdef SOMECPU} tags. Down in TlinkerFreeRTOS.MakeExecutable , there is an {$ifdef XTENSA} block for example that calls GenerateDefaultLinkerScripts, but if we have RISCV32 defined, no such call is made. I have confirmed that RISCV32 is defined at that stage, I guess its "just" a case of implementing whats necessary guided by the way its done for XTENSA ? Yes, the riscv32 recipe should closely follow the xtensa recipe.  I have started fixing some things, but it is slow going since there are small changes with esp-idf version changes that also needs to be accounted for (else one needs to pin FPC support to a specific version of esp-idf).  Will have more time over the weekend to work on this.  Also the list of scripts & libraries to load is similar but not identical between esp32 and esp32c3. ---------------------------------------------------------------------- dbannon · 2024-05-17 05:20 Yes, been playing in the same space. I note that idf_version is set to 0, options.pas does not want to know about RISCV32. Not clear to me how it is supposed to be set, seems dependent on the cpu type ?  Anyway, I forced a new version and a lot more worked. But the XTENSA one seems to have a number of ld scripts not present in RISCV32. I got as far as being told "cannot find entry symbol call_start_cpu0", linked in cpu_start.c.obj from Hello-World and realized I was way, way out of my depth .... Davo ---------------------------------------------------------------------- ccrause · 2024-05-17 05:49 Here is my git branch that I'm working on: https://gitlab.com/ccrause/fpc-source/-/tree/esp32c3 It would be great if you can help with this.  Note that I am currently using esp-idf v5.0.6, since v5.0 is mentioned in FPC (although the list of libraries seem to fit better with a later version).  Since there are differences, it would avoid confusion if we are working off the same esp-idf base. Once we have a working base in FPC, I can update FPC to work with different versions of esp-idf. Current status is that the linker reports multiple definitions for symbols, due to two versions of newlib being found (one from esp-idf and the other one from the gcc toolchain). ---------------------------------------------------------------------- MiR · 2024-05-17 06:38 Cloned... Thanks for the new branch! Christo, have you ever thought of integrating esp-idf as a submodule? I googled a little and found this: https://esp32.com/viewtopic.php?t=13860 which looks promising. If you like the idea then I can try if I can come up with something..... also this looks interesting: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api- guides/tools/idf-component-manager.html ---------------------------------------------------------------------- dbannon · 2024-05-17 06:41 I'll help in any way I can but .... Cloning (yek, to gitlab, I should have pointed to my github...) Davo ---------------------------------------------------------------------- ccrause · 2024-05-17 08:53 Quote from: MiR on May 17, 2024, 08:38:45 amCloned... Thanks for the new branch! Christo, have you ever thought of integrating esp-idf as a submodule? I googled a little and found this: https://esp32.com/viewtopic.php?t=13860 which looks promising. If you like the idea then I can try if I can come up with something..... also this looks interesting: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api- guides/tools/idf-component-manager.html Michael I don't see the potential you are thinking of, maybe explain a bit more what workflow you are envisioning? I would appreciate anything that can automate building and collecting the esp-idf libraries for use with FPC. AFAICS the eps-idf submodule is used within another project to pin the esp-idf version, also the build system of the project needs to work with cmake.  For FPC, we need (maybe not need, but it is a real time saver if one does not need to build the SDK on the fly) to provide precompiled libraries for the linking stage.  The approach you use in espsdk4fpc seems fine for this,  it checks out a specific git tag and build and collect the necessary files from there. I think espsdk4fpc should perhaps be generalized a bit so that one can select different controllers and different SDK versions.  This requires customization (or at least testing) for each version (and controller) since files and even components can move around even between minor versions. ---------------------------------------------------------------------- MiR · 2024-05-17 09:15 Let me give this a little more thought.... But you are right, for building code with fpc there is no real need to have full esp-idf inside. That's maybe more something for the infrastructure arround fpc Michael ---------------------------------------------------------------------- dbannon · 2024-05-17 09:53 (work in progress when you post arrived) From your gitlab ccrause around 5250 compiler/options.pas there is this, as it does not respond in RISCV32, the idf_version is still not being set. 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 {$ifdef XTENSA}  { set ESP32 or ESP8266 default SDK versions }  option.MaybeSetIdfVersionMacro;{$endif XTENSA} Then, about line 1500, we have - 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   if not(target_info.system=system_xtensa_freertos) then    exit; Needs an or with system_riscv32_freertos .... Then, down a bit further - 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 {$ifdef RISCV32)}    ct_esp32c3:      begin        set_system_compvar('IDF_VERSION','40400');        idf_version:=40400;      end;{$endif RISCV32}Need to get rid of the curved bracket, ")" from ifdef line. But I am afraid even more trouble, once that block of code is exposed, it seems that current_settings.controllertype is not, in fact, set to ct_esp32c3 there ! Davo ---------------------------------------------------------------------- ccrause · 2024-05-17 10:25 Quote from: dbannon on May 17, 2024, 11:53:35 amFrom your gitlab ccrause around 5250 compiler/options.pas there is this, as it does not respond in RISCV32, the idf_version is still not being set. 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 {$ifdef XTENSA}  { set ESP32 or ESP8266 default SDK versions }  option.MaybeSetIdfVersionMacro;{$endif XTENSA} Davo Thanks Davo, I will fix this.  The default setting is not really useful, unless it happens to coincide with the provided esp-idf libraries version.  I strongly suggest specifying the esp-idf version via the -WP command line option (once the basics are sorted of course). ---------------------------------------------------------------------- dbannon · 2024-05-17 10:38 Quote from: ccrause on May 17, 2024, 12:25:08 pm....I strongly suggest specifying the esp-idf version via the -WP command line option (once the basics are sorted of course). Great !  -WP ?  what is the syntax, my compiler does not mention it with a -h  ? Does not like it if I use -WP40400 ---------------------------------------------------------------------- ccrause · 2024-05-17 11:08 Quote from: dbannon on May 17, 2024, 12:38:32 pmQuote from: ccrause on May 17, 2024, 12:25:08 pm....I strongly suggest specifying the esp-idf version via the -WP command line option (once the basics are sorted of course). Great !  -WP ?  what is the syntax, my compiler does not mention it with a -h  ? Does not like it if I use -WP40400 It is briefly mentioned on the xtensa wiki page: Quote  Note: Different versions of esp-idf require different libraries to link. Use the -WP command line option to specify the version number, e.g. -WP4.3.2. It should also be documented as part of the compiler help output, but this help entry is missing for the riscv cross compiler. ---------------------------------------------------------------------- dbannon · 2024-05-17 11:37 Ah, makes sense. One thing I am reasonable at is documenting, might have some fun later down this path. Anyway, I forced a valid idf_version number and we proceeded to linking. And the linker rejects my *.a files (scrapped from the helloworld demo) because they contain, wait for it, Xtensa, obj files ! Code: [Select]dbannon@dell:~/esp/riscv32-esp32-elf-libs$ file espnow.o espnow.o: ELF 32-bit LSB relocatable, Tensilica Xtensa, version 1 (SYSV), not stripped Going to have to roll back a long way and find what I did wrong there !  Last you will see of me tonight. Davo ---------------------------------------------------------------------- ccrause · 2024-05-17 14:16 Quote from: dbannon on May 17, 2024, 01:37:20 pmAnyway, I forced a valid idf_version number and we proceeded to linking. And the linker rejects my *.a files (scrapped from the helloworld demo) because they contain, wait for it, Xtensa, obj files ! Code: [Select]dbannon@dell:~/esp/riscv32-esp32-elf-libs$ file espnow.o espnow.o: ELF 32-bit LSB relocatable, Tensilica Xtensa, version 1 (SYSV), not stripped Going to have to roll back a long way and find what I did wrong there !  Last you will see of me tonight. Davo The default build target in esp-idf is esp32.  To change this do: 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 idf.py set- target esp32c3in your esp-idf example folder. ---------------------------------------------------------------------- ccrause · 2024-05-17 14:24 Quote from: dbannon on May 17, 2024, 11:53:35 amCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$ifdef RISCV32)}    ct_esp32c3:      begin        set_system_compvar('IDF_VERSION','40400');        idf_version:=40400;      end;{$endif RISCV32}Need to get rid of the curved bracket, ")" from ifdef line. QuoteBut I am afraid even more trouble, once that block of code is exposed, it seems that current_settings.controllertype is not, in fact, set to ct_esp32c3 there ! The controller type should be specified by a command line option (-Wpesp32c3), or am I missing something else? ---------------------------------------------------------------------- MiR · 2024-05-17 15:38 Hmm, Christo, now you got me confused.. Which version for esp-idf do you want to use for risc? I read about 5.0.6 earlier and now in your last comment it seems 4.4 I am currently doing a script to be able to have compilers/libs/bootloaders for 4.4, 5.0.6 and 5.2.1 for devices esp32 esp32s2 esp32s3 esp32c3 esp32c6 (Not everything available everywhere) Michael ---------------------------------------------------------------------- ccrause · 2024-05-17 16:01 Quote from: MiR on May 17, 2024, 05:38:22 pmHmm, Christo, now you got me confused.. Which version for esp-idf do you want to use for risc? I read about 5.0.6 earlier and now in your last comment it seems 4.4 I am currently doing a script to be able to have compilers/libs/bootloaders for 4.4, 5.0.6 and 5.2.1 for devices esp32 esp32s2 esp32s3 esp32c3 esp32c6 (Not everything available everywhere) Michael I started with the v5.0 (latest fixes, so v5.0.6) branch because there already was an esp32c3idf_50000.pp unit in rtl/freertos/riscv32/. The riscv32 code in the t_freertos unit copied a lot of the esp32 code, hence the version checks do not always seem to match up yet. Once I get something working I will add support for different versions. Edit: The v4.4 is also just copy/paste to get the functionality in place, not to reflect any specific preference. ---------------------------------------------------------------------- MiR · 2024-05-18 13:43 I have now created a branch: https://github.com/michael-ring/espsdk4fpc/tree/devel which currently allows you to build sdk and binutils for 4.4.7 and 5.0.6 (and likely some other versions...) Christo, can you please have a look if things are roughly in the right place and complete? Supported chips are currently esp32 esp32s2 esp32s3 and esp32c3 with 5.2.1 Espressif releases common binutils for all xpressif chips, same as for risc5, so for the future this would be a nice target (and it has support for esp32c6). I did not feel like already doing the necessary changes, when you want to work in this direction I can make the code also work with 5.2.1 sdk esp32s2 and esp32s3 are lx7 but I kept the lx6 directory, let me know if you would like to change this. I also splitted into debug / release directories, although currently I have no proper sdkconfig files for debug so actually the debug files are identical to the release files, feel free to create a PR to change this... Michael ---------------------------------------------------------------------- ccrause · 2024-05-18 14:18 Quote from: MiR on May 18, 2024, 03:43:08 pmI have now created a branch: https://github.com/michael-ring/espsdk4fpc/tree/devel which currently allows you to build sdk and binutils for 4.4.7 and 5.0.6 (and likely some other versions...) Christo, can you please have a look if things are roughly in the right place and complete? Thank you Michael!  I finally got to the point where FPC can link against esp32c3 libraries without conflicts.  I want to test the generated executable to check if it is actually working, then I will dive into espsdk4fpc. ---------------------------------------------------------------------- dbannon · 2024-05-19 00:59 Quote from: ccrause on May 17, 2024, 04:16:36 pmQuote from: dbannon on May 17, 2024, 01:37:20 pmAnd the linker rejects my *.a files (scrapped from the helloworld demo) because they contain, wait for it, Xtensa, obj files ! The default build target in esp-idf is esp32.  To change this do: 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 idf.py set- target esp32c3in your esp-idf example folder. No, the github repo itself contains a whole lot of prebuilt *.a archives. See (libcore.a for example) - Code: [Select]bannon@dell:~/esp/hello_world$ find ~/esp/esp- idf/components -name "*.a" | grep libcore /home/dbannon/esp/esp-idf/components/esp_wifi/lib/esp32s3/libcore.a /home/dbannon/esp/esp-idf/components/esp_wifi/lib/esp32c3/libcore.a /home/dbannon/esp/esp-idf/components/esp_wifi/lib/esp32s2/libcore.a /home/dbannon/esp/esp-idf/components/esp_wifi/lib/esp32c2/libcore.a /home/dbannon/esp/esp-idf/components/esp_wifi/lib/esp32/libcore.a As the find/copy command finds them, it will over write the previous one so its quite unpredictable as to which one you end up with in riscv32-esp32-elf-libs. Selecting only archives that have esp32c3 in their pathname solved that problem. But (with your latest commits) - Code: [Select]/home/dbannon/.espressif/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libc.a /home/dbannon/.espressif/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libm.a /home/dbannon/.espressif/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libgcc.a [0.055] hello.pas(4,18) Error: Error while linking [0.055] hello.pas(4,18) Fatal: There were 1 errors compiling module, stopping Davo ---------------------------------------------------------------------- ccrause · 2024-05-19 06:20 Quote from: dbannon on May 19, 2024, 02:59:02 amCode: [Select]/home/dbannon/.espressif/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libc.a /home/dbannon/.espressif/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libm.a /home/dbannon/.espressif/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libgcc.a [0.055] hello.pas(4,18) Error: Error while linking [0.055] hello.pas(4,18) Fatal: There were 1 errors compiling module, stopping These libraries are part of the Gnu toolchain distribution and can be found here (obviously computer specific): 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 ~/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp- elf/lib/gcc/riscv32-esp-elf/11.2.0/rv32imc/ilp32/no- rtti~/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp- elf/riscv32-esp-elf/lib/rv32imc/ilp32/no-rtti For all the settings I'm using, see the below summary for riscv32-freertos in my fpc.cfg: 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 #ifdef cpuriscv32  -Fu~/fpc/installs/lib/fpc/$fpcversion/units/$fpctarget/*/$fpcsubarch  #ifdef CPUrv32imc    -XPriscv32-esp-elf-    #ifdef freertos     # esp- idf libraries     -Fl/home/christo/fpc/xtensa/esp-idf-5.0.6/libs- esp32c3     -Ff/home/christo/fpc/xtensa/esp-idf-5.0.6     -WP5.0.6     -FD/home/christo/.espressif/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin     -Fl/home/christo/.espressif/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/lib/gcc/riscv32-esp- elf/11.2.0/rv32imc/ilp32/no-rtti     -Fl/home/christo/.espressif/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/riscv32-esp- elf/lib/rv32imc/ilp32/no-rtti    #endif freertos    -Wpesp32c3  #endif CPUrv32imc#endif cpuriscv32Note: Later, when all is working and updated in fpcupdeluxe, the folder structure will obviously be different, this is just how I happen to arrange things for now. To see where all the used libraries in the example project are located, go the the esp-idf example build sub folder, open the $example.map file and search for the library name. The map file is also useful to see which library is supplying which symbol, if you end up in a situation where the linker cannot locate a symbol in a FPC project. EDIT: Fixed paths to toolchain library folders ---------------------------------------------------------------------- ccrause · 2024-05-19 11:49 Current status of a simple blink Pascal project: Code: [Select]I (8609) cpu_start: cpu freq: 160000000 Hz I (8632) cpu_start: Application information: I (8647) cpu_start: Project name:     blink I (8665) cpu_start: App version:      1 I (8677) cpu_start: Compile time:     May 18 2024 17:46:58 I (8698) cpu_start: ELF file SHA256:  6c88b520a176f320... I (8720) cpu_start: ESP-IDF:          v5.0.6 I (8738) cpu_start: Min chip rev:     v0.3 I (8764) cpu_start: Max chip rev:     v1.99 I (8791) cpu_start: Chip rev:         v0.3 I (8839) heap_init: Initializing. RAM available for dynamic allocation: I (8904) heap_init: At 3FC8D600 len 0004F110 (316 KiB): DRAM I (8946) heap_init: At 3FCDC710 len 00002950 (10 KiB): STACK/DRAM I (8992) heap_init: At 50000010 len 00001FD8 (7 KiB): RTCRAM Guru Meditation Error: Core  0 panic'ed (Instruction access fault). Exception was unhandled. The problem is located in the startup code function __smakebuf_r which is called during the initialization of the heap memory on the SDK side (before the Pascal code is loaded). The problem is that the FPC linked binary contains a version of __smakebuf_r that is slightly different from the esp-idf linked example, even though both examples are linked to the same libc library. Working version: 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 4200ae8a <__smakebuf_r>: ...4200af04:   cf91                   beqz   a5,4200af20 <__smakebuf_r+0x96>4200af06:   00e41583          lh   a1,14(s0)4200af0a:   8526                  mv   a0,s14200af0c:   f7bf80ef             jal   ra,42003e86 <_getpid_r>4200af10:   c901                beqz   a0,4200af20 <__smakebuf_r+0x96>4200af12:   00c45783          lhu   a5,12(s0) Non-working version: 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 4200abe6 <__smakebuf_r>:...4200ac60:   c385                   beqz   a5,4200ac80 <__smakebuf_r+0x9a>4200ac62:   00e41583             lh   a1,14(s0)4200ac66:   8526                   mv   a0,s14200ac68:   fdff5097             auipc   ra,0xfdff54200ac6c:   718080e7           jalr   1816(ra) # 40000380 <_isatty_r>4200ac70:   c901                 beqz   a0,4200ac80 <__smakebuf_r+0x9a>4200ac72:   00c45783           lhu   a5,12(s0) Looking at the object code for __smakebuf_r in libc shows the following instructions for the relevant jal call: Code: [Select]0000010c <.LVL17>:  10c: 00000097          auipc ra,0x0 10c: R_RISCV_CALL _isatty_r 10c: R_RISCV_RELAX *ABS*  110: 000080e7          jalr ra # 10c <.LVL17> This obviously should call _isatty_r.  Unfortunately there are two versions, one defined in newlib and one that is included in the on chip ROM , defined in esp32c3.rom.newlib-time.ld. The non-working version links to the ROM version of _isatty_r, so this appears to not work correctly. Now to find a way to convince the linker to pick the newlib version... ---------------------------------------------------------------------- dbannon · 2024-05-19 11:54 Quote from: ccrause on May 19, 2024, 08:20:32 am.... These libraries are part of the Gnu toolchain distribution and can be found here (obviously computer specific): Oh, I don't know why I did not look there !  Sorry. QuoteFor all the settings I'm using, see the below summary for riscv32-freertos in my fpc.cfg: Yep, makes sense, I prefer not to edit the fpc.cfg file, I have been building with a script that offers all that content on a fpc command line, easier IMHO to manage. But I still find myself missing symbols esp_app_get_elf_sha256, esp_partition_main_flash_region_safe, esp_app_get_description Easy to look them up in the map file you mention and find the .a file they live in. And easy to manually add then to the link file and it all builds. But thats no solution. How can I tell FPC about needing them ? It finds all the other object archives it needs ? What are your plans with "packaging" this ?  Its a labourous process installing IDF and its associated tool, it appears to me it would be legal to just cherry pick all the needed libraries and put them 'somewhere' suitable but how about the assembler and linker ?  Oh, and that esptool.py thing .... And should that process be based on the 5.2.1 stable release ? Davo ---------------------------------------------------------------------- MiR · 2024-05-19 12:11 Packaging is done in my repo: https://github.com/michael-ring/espsdk4fpc/tree/devel when you have a linux box or a mac you can run buildsdk.sh and you will end up with a directory structure (4.4.7 and 5.0.6) that includes the (hopefully complete) dependencies for compiling and linking an esp project. We use an older version of this with fpcupdeluxe, hopefully when things advance the same mechanism can be used for the esp32c3 chip. Michael ---------------------------------------------------------------------- dbannon · 2024-05-19 12:15 Sorry, I posted over you. Quote from: ccrause on May 19, 2024, 01:49:34 pm.... Now to find a way to convince the linker to pick the newlib version... That ROM code appears to be reproduced .espressif/tools/esp-rom- elfs/20220823/esp32c3_rev3_rom.elf It has a date stamp and rev number so, is likely to be different in different hardware during a release cycle. Does not sound very reliable .... Davo ---------------------------------------------------------------------- ccrause · 2024-05-19 12:24 Quote from: ccrause on May 19, 2024, 01:49:34 pmUnfortunately there are two versions, one defined in newlib and one that is included in the on chip ROM , defined in esp32c3.rom.newlib-time.ld. The non- working version links to the ROM version of _isatty_r, so this appears to not work correctly. Now to find a way to convince the linker to pick the newlib version... As a work-around I have removed the sp32c3.rom.newlib-time.ld from fpc's list of scripts passed to the linker. Not sure this is the proper general solution, but at least now the startup process runs into the pascal $main function, then hangs in FPC_INIT_FUNC_TABLE. But this is good news, the problem now lies in the fpc domain, so conceptually a bit easier to tackle. ---------------------------------------------------------------------- ccrause · 2024-05-19 12:27 Quote from: dbannon on May 19, 2024, 02:15:31 pmSorry, I posted over you. Quote from: ccrause on May 19, 2024, 01:49:34 pm.... Now to find a way to convince the linker to pick the newlib version... That ROM code appears to be reproduced .espressif/tools/esp-rom- elfs/20220823/esp32c3_rev3_rom.elf It has a date stamp and rev number so, is likely to be different in different hardware during a release cycle. Does not sound very reliable .... Davo Thanks Davo, I was going to search for that image at some point.  Luckily I can work around that particular problem for now. ---------------------------------------------------------------------- ccrause · 2024-05-19 12:45 Quote from: dbannon on May 19, 2024, 01:54:42 pmYep, makes sense, I prefer not to edit the fpc.cfg file, I have been building with a script that offers all that content on a fpc command line, easier IMHO to manage. Yes, there are many ways to supply information to the compiler, so do whatever fits in best with your workflow. QuoteBut I still find myself missing symbols esp_app_get_elf_sha256, esp_partition_main_flash_region_safe, esp_app_get_description Easy to look them up in the map file you mention and find the .a file they live in. And easy to manually add then to the link file and it all builds. But thats no solution. How can I tell FPC about needing them ? It finds all the other object archives it needs ? The list of libraries required to link a minimal project depends on the ep-idf version.  This is handled by having secondary units with the version dependent list of esp-idf libraries, e.g. esp32c3idf_50000.pp.  FPC will select the applicable unit based on the esp-idf version specified via -WP. QuoteWhat are your plans with "packaging" this ?  Its a labourous process installing IDF and its associated tool, it appears to me it would be legal to just cherry pick all the needed libraries and put them 'somewhere' suitable but how about the assembler and linker ?  Oh, and that esptool.py thing .... Michael Ring is working on a script that does exactly this, packaging the esp-idf libraries, fragments, python tools, bintools and a python environment. This is used with fpcupdeluxe at the moment, so the end user just selects the target in fpcupdeluxe, then all the required files are just copied across. Of course fpcupdeluxe only support esp8266 (v3.4) and esp32 (v4.3) at the moment, but this will change as the situation stabilizes. QuoteAnd should that process be based on the 5.2.1 stable release ? I'm working with esp-idf v5.0.6 at the moment, since it appeared to correspond with what was in FPC when I started. Once I get the platform working, it is relatively easy to cover other esp-idf versions. Edit: Added link to Michael's post of espsdk4fpc ---------------------------------------------------------------------- MiR · 2024-05-19 14:36 Christo, I built fpc now based on your branch, I am now struggeling with this: ~/fpcupdeluxe/fpc/bin/aarch64-darwin/ppcrossrv32 -Tfreertos -XP/Users/tgdrimi9/devel/espsdk4fpc/5.0.6/esp32c6/riscv32-binutils- aarch64-darwin/bin/riscv32-esp-elf- -O1 -WpESP32C3 hello -vt -Fu~/fpcupdeluxe/fpc/units/riscv32-freertos/rtl /Users/tgdrimi9/devel/espsdk4fpc/5.0.6/esp32c6/riscv32-binutils- aarch64-darwin/bin/riscv32-esp-elf-ld: cannot open linker script file esp32c3_out.ld: No such file or directory Is this file hand crafted by you or is this sections.ld from the sdk? ---------------------------------------------------------------------- MiR · 2024-05-19 14:40 .. guess I need to set -WP but not sure why this still fails: ~/fpcupdeluxe/fpc/bin/aarch64-darwin/ppcrossrv32 -Tfreertos -XP/Users/tgdrimi9/devel/espsdk4fpc/5.0.6/esp32c6/riscv32-binutils- aarch64-darwin/bin/riscv32-esp-elf- -O1 -WpESP32C3 hello -vt -Fu~/fpcupdeluxe/fpc/units/riscv32-freertos/rtl -WP5.0.6 -Fl~/devel/espsdk4fpc/5.0.6/esp32c3/riscv32-libs/riscv32/ /Users/tgdrimi9/devel/espsdk4fpc/5.0.6/esp32c6/riscv32-binutils- aarch64-darwin/bin/riscv32-esp-elf-ld: cannot open linker script file esp32c3.rom.ld: No such file or directory Getting closer: ~/fpcupdeluxe/fpc/bin/aarch64-darwin/ppcrossrv32 -Tfreertos -XP/Users/tgdrimi9/devel/espsdk4fpc/5.0.6/esp32c6/riscv32-binutils- aarch64-darwin/bin/riscv32-esp-elf- -O1 -WpESP32C3 hello -vt -Fu~/fpcupdeluxe/fpc/units/riscv32-freertos/rtl -WP5.0.6 -Fl~/devel/espsdk4fpc/5.0.6/esp32c3/riscv32-libs/riscv32/ -Fl~/devel/espsdk4fpc/5.0.6/esp32c3/riscv32-binutils- aarch64-darwin/esp-idf-5.0.6/components/esp_rom/esp32c3/ld/ -Fl~/devel/espsdk4fpc/5.0.6/esp32c6/riscv32-binutils- aarch64-darwin/esp-idf-5.0.6/components/soc/esp32c3/ld/ -Fl~/devel/espsdk4fpc/tools-5.0.6/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/riscv32-esp- elf/lib/rv32imc/ilp32/ -Fl~/devel/espsdk4fpc/tools-5.0.6/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/lib/gcc/riscv32-esp- elf/11.2.0/rv32imc/ilp32/ -Fl~/devel/espsdk4fpc/5.0.6/esp32c3/riscv32-libs/riscv32/release/ but now I have multiple defines between newlib.a and libc.a (Tons of them) libnewlib.a(locks.c.obj): in function `__retarget_lock_init': newlib/locks.c:276: multiple definition of `__retarget_lock_init'; lib/rv32imc/ilp32/libc.a(lib_a-lock.o): first defined here ---------------------------------------------------------------------- ccrause · 2024-05-19 15:29 Quote from: MiR on May 19, 2024, 04:36:25 pmcannot open linker script file esp32c3_out.ld: No such file or directory Specify the esp-idf version with -WP.  The above name is for esp-idf before v4.4. Edit: QuoteIs this file hand crafted by you or is this sections.ld from the sdk? It is sections.ld from the SDK since esp-idf v4.4. ---------------------------------------------------------------------- ccrause · 2024-05-19 15:34 Quote from: MiR on May 19, 2024, 04:40:20 pmbut now I have multiple defines between newlib.a and libc.a (Tons of them) libnewlib.a(locks.c.obj): in function `__retarget_lock_init': newlib/locks.c:276: multiple definition of `__retarget_lock_init'; lib/rv32imc/ilp32/libc.a(lib_a-lock.o): first defined here Please post the linker script from fpc (linkxxx.res). I managed to get past this by moving the standard C libraries to the end of the library list. ---------------------------------------------------------------------- MiR · 2024-05-19 16:25 Here you go Isn't newlib a replacement for libc? ---------------------------------------------------------------------- ccrause · 2024-05-19 16:42 Quote from: MiR on May 19, 2024, 06:25:16 pmIsn't newlib a replacement for libc? Espressif builds the standard toolchain libc based on newlib, then also use a different newlib in esp-idf. So linking order seems to be critical to correctly chain the dependencies. At least that is my impression. Note the SDK build uses the no-rtti libs: tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/riscv32-esp- elf/lib/rv32imc/ilp32/no-rtti/ tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp- elf/lib/gcc/riscv32-esp-elf/11.2.0/rv32imc/ilp32/no-rtti/ Compared to your linker file search paths: tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/riscv32-esp- elf/lib/rv32imc/ilp32/ tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp- elf/lib/gcc/riscv32-esp-elf/11.2.0/rv32imc/ilp32/ ---------------------------------------------------------------------- ccrause · 2024-05-19 17:33 Progress! 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 hello; procedure vTaskDelay(xTicksToDelay: uint32); external;function gpio_reset_pin(gpio_num: uint32): uint32; external;function gpio_set_direction(gpio_num, mode: uint32): uint32; external;function gpio_set_level(gpio_num, level: uint32): uint32; external; const  LED = 10; // DFRobot Beetle ESP32-C3 board  OUTPUT = 1 shl 1; begin  gpio_reset_pin(LED);  gpio_set_direction(LED, OUTPUT);  repeat    WriteLn('Hello from FPC!');    gpio_set_level(LED, 1);    vTaskDelay(75);    gpio_set_level(LED, 0);    vTaskDelay(25);  until false;end. Compile: Code: [Select]$ ~/fpc/installs/lib/fpc/3.3.1/ppcrossrv32 -Tfreertos -Wpesp32c3 -WP5.0.6 -vhwi hello.pp Hint: Start of reading config file /home/christo/.fpc.cfg Hint: End of reading config file /home/christo/.fpc.cfg Target OS: FreeRTOS Compiling hello.pp Assembling hello Linking hello esptool.py v4.7.0 Creating esp32c3 image... Merged 1 ELF section Successfully created esp32c3 image. 24 lines compiled, 2.1 sec, 436 bytes code, 45 bytes data 2 hint(s) issued Upload: Code: [Select]$ ~/fpc/xtensa/esp- idf-5.0.6/components/esptool_py/esptool/esptool.py -p /dev/ttyACM0 -b 460800 --before default_reset --after hard_reset --chip esp32c3  write_flash --flash_mode dio --flash_size detect --flash_freq 40m 0x10000 hello.bin esptool.py v4.7.0 Serial port /dev/ttyACM0 Connecting... Chip is ESP32-C3 (QFN32) (revision v0.3) Features: WiFi, BLE, Embedded Flash 4MB (XMC) Crystal is 40MHz MAC: 84:f7:03:41:63:20 Uploading stub... Running stub... Stub running... Changing baud rate to 460800 Changed. Configuring flash size... Auto-detected Flash size: 4MB Flash will be erased from 0x00010000 to 0x0003bfff... Compressed 179488 bytes to 94964... Wrote 179488 bytes (94964 compressed) at 0x00010000 in 1.7 seconds (effective 853.6 kbit/s)... Hash of data verified. Leaving... Hard resetting via RTS pin... LED is blinking, I don't feel like posting a video.  Serial output: Code: [Select]I (225) heap_init: At 50000010 len 00001FD8 (7 KiB): RTCRAM I (232) spi_flash: detected chip: generic I (236) spi_flash: flash io: dio W (240) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header. I (254) app_start: Starting scheduler on CPU0 I (258) main_task: Started on CPU0 I (258) main_task: Calling app_main() I (258) gpio: GPIO[10]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 Hello from FPC! Hello from FPC! Hello from FPC! Hello from FPC! Hello from FPC! Hello from FPC! ---------------------------------------------------------------------- MiR · 2024-05-19 18:00 Gratulations! Would you mind sending me output of find . -type f -exec md5sum {} \; and your linker file? Then I can check what's different for me.... ---------------------------------------------------------------------- ccrause · 2024-05-19 18:48 Quote from: MiR on May 19, 2024, 08:00:04 pmGratulations! Would you mind sending me output of find . -type f -exec md5sum {} \; and your linker file? Then I can check what's different for me.... Attached a linker file for the above program.  I ran the find command in the toolchain library folders: Code: [Select]/.espressif/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/riscv32-esp- elf/lib/rv32imc/ilp32/no-rtti$ find . -type f -exec md5sum {} \; 51d7005d49d8c7b7040915e72180f56a  ./libm.a bce0cd2e439edb19315d4a2bec8c5098  ./libnosys.a 0f2e66e53f9a139c8d9fcba1d5c32a55  ./semihost.specs ce20bdc490b21f797baaf645d2147ecc  ./crt0.o d08dd7b55a76d589a44b30ce93cd0af0  ./default.specs a855456e73dc690d6b55a25151b70d2b  ./libsupc++.a 16d1f0a025fb66ed9439eb003deebc26  ./libsim.a 0c60d9947506a3ef279005db64ac15a0  ./sim.specs 8efe348cdde3362419670a2bfba81d33  ./libgloss.a deef8236100e6e6e5ed87a4980e5c9bf  ./libstdc++.a-gdb.py 69f260c542f13ddf0355e30db1b39a87  ./nosys.specs 91ba9a643886d0dfd3587a92e3f8766b  ./libc_nano.a f387bc33370f3be0d57dd884e355ce94  ./libg.a 4b9a9f1c669f766f761c4dbd17120a83  ./libm_nano.a f387bc33370f3be0d57dd884e355ce94  ./libc.a 91ba9a643886d0dfd3587a92e3f8766b  ./libg_nano.a f5b8c852015817240910cf899e67ce12  ./libsemihost.a 3bd403a3d6abe958b2bfd2a045dda8b1  ./nano.specs 782a7efe7c535fd192b38a2c8a155450  ./libstdc++.aand Code: [Select]~/.espressif/tools/riscv32-esp- elf/esp-2022r1-11.2.0/riscv32-esp-elf/lib/gcc/riscv32-esp- elf/11.2.0/rv32imc/ilp32/no-rtti$ find . -type f -exec md5sum {} \; 685c71247615ed4907a4555e4d40febc  ./crtn.o bd1a5b35b847d6aaffe4425d7ab3042c  ./libgcc.a 255b930e2d689a52f0c880e1b6061ac4  ./libgcov.a a8ff41a27e98dc8041a7ac76b8bd35da  ./crtbegin.o bc16f85b1c2de39cbda2f4255cfa30ba  ./crtend.o 685c71247615ed4907a4555e4d40febc  ./crti.o ---------------------------------------------------------------------- MiR · 2024-05-20 18:13 tgdrimi9@ubuntu:~/devel/fpc-esp32c3/test$ ./c Free Pascal Compiler version 3.3.1 [2024/05/19] for riscv32 Copyright (c) 1993-2024 by Florian Klaempfl and others Target OS: FreeRTOS Compiling hello.pas Assembling hello Linking hello (1023) IDF_PATH is /home/tgdrimi9/devel/espsdk4fpc/5.0.6/esp32c3/riscv32-binutils- amd64-linux/esp-idf-5.0.6 esptool.py v4.7.0 Creating esp32c3 image... Merged 1 ELF section Successfully created esp32c3 image. .. found my issue, please pull espsdk4fpc again... ---------------------------------------------------------------------- ccrause · 2024-05-20 20:10 Michael, hopefully I can test your script tomorrow. Could you test that your compiled program is functional? ---------------------------------------------------------------------- ccrause · 2024-05-21 05:46 Quote from: MiR on May 20, 2024, 08:13:00 pm.. found my issue, please pull espsdk4fpc again... The script is not sh or bash compatible. Perhaps add a check for zsh at the start of the script to ensure it is not executed in a different shell. With sh or bash it will spit out the following error:  ./buildsdk.sh: 56: Syntax error: "(" unexpected (expecting "done") Script is running, will take a while to finish on my pedestrian machine. Edit: Should export "IDF_TOOLS_PATH" not be   export "$IDF_TOOLS_PATH" Edit2: Strikethrough ---------------------------------------------------------------------- MiR · 2024-05-23 11:05 Today received those two new toys, let the party begin.... ---------------------------------------------------------------------- Thaddy · 2024-05-23 15:36 I received part of my orders too  I will keep you both posted! ---------------------------------------------------------------------- MiR · 2024-06-10 21:04 The party has gotten bigger.... All on the left side already say "Hello", the only party crusher is the big boy on the right side, an esp32s2..... Michael ---------------------------------------------------------------------- dbannon · 2024-06-11 02:23 Folks, I have to apologize, I started this thread. Then went in for a minor medical op, picked up a quite serious infection. Be assured I will join the fun as soon as I can concentrate on something for more than five minutes. It does sound like fun too ! Davo ---------------------------------------------------------------------- TRon · 2024-06-11 02:50 Quote from: dbannon on June 11, 2024, 04:23:34 am... picked up a quite serious infection. Stay save and get well (e.g. live long and prosper  ). Wishing you a speedy recovery. Unfortunately I know from experience that these kind of things can be a PITA especially when you get older. ---------------------------------------------------------------------- 440bx · 2024-06-11 03:00 @dbannon, here is hoping you get well asap ---------------------------------------------------------------------- Thaddy · 2024-06-11 04:02 Yes, get well soon! ---------------------------------------------------------------------- cdbc · 2024-06-11 05:56 Hi Davo I hope you get better soon, stay safe mate. Regards Benny ---------------------------------------------------------------------- MarkMLl · 2024-06-11 06:31 Quote from: dbannon on June 11, 2024, 04:23:34 amBe assured I will join the fun as soon as I can concentrate on something for more than five minutes. Regrettably, that comes with being unwell (and with getting older )-: Look after yourself and hope to see you back in full flow sooner rather than later. MarkMLl ---------------------------------------------------------------------- ccrause · 2024-06-11 08:41 Quote from: dbannon on June 11, 2024, 04:23:34 amFolks, I have to apologize, I started this thread. Then went in for a minor medical op, picked up a quite serious infection. Whishing you a speedy recovery.