- Sun May 07, 2023 3:31 am
#96364
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.
BTW2 did you know the lx106 (as many other modern cpu's) has very little 8- and 16-bit specific instructions? So if you declare a variable to be 8 or 16 bit wide (something Espressif does very now and then), it just carries out all operations in 32 bit and then chops off the upper 24 or 16 bits. One extra instruction that in most cases isn't really necessary. This is most important in function parameters, never declare them as char, unsigned char, uint8_t, int8_t, short, unsigned short, uint16_t or int16_t unless really necessary. They'll get expanded to 32 bits and afterwards truncated.
davydnorris wrote:Yeah I have ANSIfied the headers in the NonOS SDK and have stripped almost everything out of c_types.h and instead add the stdbool, stdint, etc, headers.
The real reason I am trying to compile the latest toolchain is to try and move to the RTOS and some common code between ESP8266 and ESP32 chips. But I need to be able to get my existing code to work first.
The super annoying thing about the whole change to 32bit integers in the latest toolchains is that you need to replace all your *printf formatting, but if you use the supposedly agnostic PRIxxx macros, they break on the earlier toolchains because the definitions inside GCC itself rely on the size of long not int
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.
BTW2 did you know the lx106 (as many other modern cpu's) has very little 8- and 16-bit specific instructions? So if you declare a variable to be 8 or 16 bit wide (something Espressif does very now and then), it just carries out all operations in 32 bit and then chops off the upper 24 or 16 bits. One extra instruction that in most cases isn't really necessary. This is most important in function parameters, never declare them as char, unsigned char, uint8_t, int8_t, short, unsigned short, uint16_t or int16_t unless really necessary. They'll get expanded to 32 bits and afterwards truncated.
