davydnorris wrote:
Do you think there's a chance Espressif will pull the ESP8266 stuff up into the latest branch and maintain it? I'd really like to be able to have the same versions of everything for both the ESP8266 and the ESP32 chips I'm playing with.
Statistics: Posted by jcmvbkbc — Fri May 19, 2023 5:59 pm
Statistics: Posted by davydnorris — Thu May 18, 2023 1:02 am
eriksl wrote:
I also should cleanup some of the GCC patches Max added, as they're for really old GCC versions. Apparently current GCC doesn't need patching for lx106 targets.
Statistics: Posted by jcmvbkbc — Wed May 17, 2023 10:25 pm
Statistics: Posted by davydnorris — Fri May 12, 2023 8:07 pm
Statistics: Posted by eriksl — Fri May 12, 2023 2:27 am
eriksl wrote:Agree that the ESP32 has some interesting features, but nothing I can't do with the ESP8266. Nice to have hardware I2C and PWM modules, but I just do fine with my software emulations (my I2C implementation can reach speeds of 500 kHz, the Espressif version only 100 kHz; the PWM implementation can reach 18 bit PWM, 16 bits up to 120 Hz, which is not perfect, but better than most hardware implementations).
Statistics: Posted by eriksl — Fri May 12, 2023 2:20 am
Statistics: Posted by davydnorris — Thu May 11, 2023 6:55 pm
Statistics: Posted by davydnorris — Thu May 11, 2023 6:50 pm
Statistics: Posted by eriksl — Thu May 11, 2023 12:23 pm
davydnorris wrote:eriksl wrote:The latest newlib and newlib nano are used with no local patches, only the overlay, which is required for xtensa chips in general. The latest ESP32 risc chips don't use anything - newlib is used straight out of the box
Statistics: Posted by davydnorris — Tue May 09, 2023 8:43 pm
eriksl wrote:Are you really considering using the RTOS SDK? That means even more Espressif code. Opaque and badly documented as well as badly written. Are you sure? What is the advantage? I have found that using the three (or even one) task queues you can very well do time slicing yourself, for background tasks. Using RTOS means you will have even less direct access to the hardware or CPU.
BTW the integers were always 32 bit (and signed by default), that's dictated by the xtensa platform. The thing you're running into is that more recent gcc compilers are more strictly enforcing the "uint32_t is the same as an unsigned int, but the name is different so it's an error". Which I think is a good thing. Newer gcc's also warn about using a bool as an int and vice versa.
Statistics: Posted by eriksl — Tue May 09, 2023 10:48 am
eriksl wrote:The latest newlib and newlib nano are used with no local patches, only the overlay, which is required for xtensa chips in general. The latest ESP32 risc chips don't use anything - newlib is used straight out of the box
Statistics: Posted by eriksl — Tue May 09, 2023 10:40 am
Statistics: Posted by davydnorris — Sun May 07, 2023 6:31 pm
eriksl wrote:
The interesting thing is that on the lx106, int = long. But yes, gcc complains. As said, a very simple remedy is to cast all variables declared using uint32_t or int32_t to unsigned int or int (accordingly) when used in printf. The code will be exactly the same and the error is gone.
Statistics: Posted by davydnorris — Sun May 07, 2023 6:24 pm
davydnorris wrote:
See my last post - I previously used %x, %d, %u in my code, but the new toolchain now needs these to be %lx, etc. The other option is to use the PRIx32 macro throughout, but when I did this I found the old toolchain breaks because the PRI macros are defined based on the size of long and not size of int! Which is bizarre
Statistics: Posted by eriksl — Sun May 07, 2023 3:41 am
Statistics: Posted by eriksl — Sun May 07, 2023 3:31 am
/home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/gcc/../include/ansidecl.h:40:1: error: expected initializer before 'extern'
#ifndef _ANSIDECL_H
#define _ANSIDECL_H 1
#ifdef __cplusplus
extern "C" {
#endif
Statistics: Posted by eriksl — Sun May 07, 2023 3:21 am
Statistics: Posted by eriksl — Sun May 07, 2023 3:12 am
davydnorris wrote:Bit more progress but still not close:
- found that almost all the missing functions have been moved out into libgloss or libnosys, so you need to add nosys to your list of libs
3.1. The relationship between libgloss and newlib
Newlib is now divided into two parts. The main newlib directory contains the bulk of the code for the two main libraries, libc and libm, together with any architecture specific code for particular targets.
The libgloss directory contains code specific to particular platforms on which the library will be used, generally referred to as the Board Support Package (BSP). Any particular target architecture may have multiple BSPs, for example for different hardware platforms, for a simulator etc.
The target architecture specific code within the newlib directory may be very modest - possibly as little as an implementation of setjmp and a specification of the IEEE floating point format to use.
The board support package is more complex. It requires an implementation of eighteen system calls and the definition of one global data structure, although the implementation of some of those system calls may be completely trivial.
eriksl wrote:davydnorris wrote:Bit more progress but still not close:
- still trying to get --specs=nonsys.specs to work properly. Does anybody know how it should be used? I thought you just added it to the link line and it automatically added -lnonsys and the nano versions of the libraries but it seems to not do anything
What do you exacly mean with the "nano versions"? Aren't you using newlib?
eriksl wrote:- __ctype_ptr__ error is actually caused by liblwip being compiled with an old GCC version so I'll have to make or find a newer version of that
I remember having this issue as well, I had my implementation of ctype for this, but now it doesn't seem to be required anymore. Maybe it's indeed the lwip stuff.
I used to compile with irom versions of the libraries, so I tried to flip my build back to my old working toolchain to compare sizes and now all the sprintf formatting changes I made make it not compile . So I think I'll need to go back through my code and use the C99 PRIxxx format specifiers to make it platform independent
That's interesting? What did you do exactly, the sprintf formatting specifiers have been the same for a very long time. You may want to workaround it by not changing the formatting specifiers and casting the ints to a "well-known" type like int or unsigned int. Or just change the error into a warning.
Statistics: Posted by davydnorris — Sat May 06, 2023 10:01 pm
Statistics: Posted by davydnorris — Sat May 06, 2023 9:44 pm
Statistics: Posted by davydnorris — Sat May 06, 2023 9:37 pm
/home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/gcc/../include/ansidecl.h:40:1: error: expected initializer before 'extern'
#ifndef _ANSIDECL_H
#define _ANSIDECL_H 1
#ifdef __cplusplus
extern "C" {
#endif
Statistics: Posted by eriksl — Sat May 06, 2023 1:26 pm
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:510:56: error: 'intptr_t' undeclared (first use in this function)
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:510:65: error: expected ',' or ';' before 'counters'
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:559:39: error: expected ';' before 'new_node'
[ERROR] make[4]: *** [Makefile:921: _gcov_merge_add.o] Error 1
[ERROR] make[4]: *** Waiting for unfinished jobs....
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:510:56: error: 'intptr_t' undeclared (first use in this function)
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:510:65: error: expected ',' or ';' before 'counters'
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:559:39: error: expected ';' before 'new_node'
[ERROR] make[4]: *** [Makefile:921: _gcov_merge_topn.o] Error 1
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:510:56: error: 'intptr_t' undeclared (first use in this function)
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:510:65: error: expected ',' or ';' before 'counters'
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:559:39: error: expected ';' before 'new_node'
[ERROR] make[4]: *** [Makefile:921: _gcov_merge_ior.o] Error 1
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:510:56: error: 'intptr_t' undeclared (first use in this function)
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:510:65: error: expected ',' or ';' before 'counters'
[ERROR] /home/erik/src/esp/crosstool-NG/.build/xtensa-lx106-elf/src/gcc/libgcc/libgcov.h:559:39: error: expected ';' before 'new_node'
[ERROR] make[4]: *** [Makefile:921: _gcov_merge_time_profile.o] Error 1
[ERROR] make[3]: *** [Makefile:13271: all-target-libgcc] Error 2
Statistics: Posted by eriksl — Sat May 06, 2023 10:57 am
Statistics: Posted by davydnorris — Fri May 05, 2023 9:06 pm
davydnorris wrote:
Bit more progress but still not close:
- still trying to get --specs=nonsys.specs to work properly. Does anybody know how it should be used? I thought you just added it to the link line and it automatically added -lnonsys and the nano versions of the libraries but it seems to not do anything
- __ctype_ptr__ error is actually caused by liblwip being compiled with an old GCC version so I'll have to make or find a newer version of that
I used to compile with irom versions of the libraries, so I tried to flip my build back to my old working toolchain to compare sizes and now all the sprintf formatting changes I made make it not compile . So I think I'll need to go back through my code and use the C99 PRIxxx format specifiers to make it platform independent
Statistics: Posted by eriksl — Fri May 05, 2023 3:36 am
Statistics: Posted by eriksl — Fri May 05, 2023 3:30 am
Statistics: Posted by davydnorris — Tue May 02, 2023 9:43 pm