Is the 8266 processor supported ?

[eriksl]

Hi,

I've been programming assembly too, for years, but at the time I started with the ATmels, there was a pretty good toolkit (avr-gcc), so I didn't need to use assembly. Although I like some good assembly at times. Preferably 68000 assembly then, I still think it's almost as versatile as C itself.

I like optimizing to an extreme level, so you can use a simple/cheap/low power device in place of a more advanced model. I have seen many references to the ESP8266 not being able to do this or that, but until now it can do almost everything I want, it's just a bit more effort and I like that So really the only reason I am heading towards ESP32 is the support for ESP8266 becoming a problem and I don't have access to all required documentation to keep it alive myself. For instance, the amount of IRAM is sufficient for my needs, but all sorts of code are now included there (from the SDK libs) that I don't need, so in the end I must see to work around a minimal amount of IRAM.

On the other hand, I like me a interesting new thing every now and then

I'd like to be ahead of the troops, but it seems there is no suitable RISC-V version for me yet. The "mini" boards that I like (2.54 mm pitch pins but still very small) are all with S2 orc S3. So I guess that will be for a future project. I don't think the P4 will be very cheap (as an end-user-product), but thanks for the information!

Talking about models. Can I build an image that can run on either S2 or S3 version and what happens when I address hardware that's not available on the S2 model? Will it crash, report error (preferred) or rise an exception? Can the image inquire what model it's running on? I prefer to build one single image for all chips.

Regarding Wifi/BT -> scheduler. I am aware. I don't mind having an NMI interrupting my code, nor do I mind having to create a timer that calls some opaque code at strict intervals. I understand that it would pose a problem for most users though, I've seen many questions and complaints about the watchdog timer kicking in because they don't understand an event driven environment.

Can you say something about the use BT for OTA recovery, would that be possible, in one way or another? As I have quite a few in water resistant enclosures that are a real pain to access and then re-seal after the fix. Of course we're doing "fail safe" OTA (restart into new slot temporarily and only activate the slot permanently if the reboot completes). But still then accidents can occur.

The ESP8266 NON-OS-SDK has been using flash partitioning from version 3 onward, so no difference there. You can only access partitions you've declared in the partition table. I had to tweak it a bit though, as the SDK doesn't understand 4 Mbyte flash chips where each OTA slot is 1 Mbyte. It would be nice if Espressif would fix that omission, but it's clearly heavily based on their own OTA system.

I already have a few ESP32 (no extension) modules lying around, I've ordered an S2 and an S3 version too, so I can go ahead and get familiar with them. So I am very curious and excited it will be able to do everything I want and what I'm already doing with the ESP8266.

Is there still the situation that data read from flash can only be read in aligned 32 bit words? So on the ESP8266 this has been worked around by copying all data sections to RAM on boot, which fills up RAM pretty quickly and you really need to make sure that doesn't happen + take care for this situations. Can the ESP32 access data from flash on byte boundaries? Maybe via some data cache just like icache for code? That would make some things pretty easier. I tend to have a lot of data in flash and of course I'd like to keep it there without clobbering all DRAM.

Thanks!
Erik.

[ESP_Sprite]

I'd like to be ahead of the troops, but it seems there is no suitable RISC-V version for me yet. The "mini" boards that I like (2.54 mm pitch pins but still very small) are all with S2 orc S3. So I guess that will be for a future project. I don't think the P4 will be very cheap (as an end-user-product), but thanks for the information!

There's still options there. Nothing that we as Espressif manufacture, so I can't vouch for or against how good or price-efficient these are, but e.g. Seeed and Adafruit have small modules incorporating a C3.

Talking about models. Can I build an image that can run on either S2 or S3 version and what happens when I address hardware that's not available on the S2 model? Will it crash, report error (preferred) or rise an exception? Can the image inquire what model it's running on? I prefer to build one single image for all chips.

I don't think you can. Aside from the fact that I think the ROM checks the chip versions, the CPU core on those chips is also slightly different. It may be possible to use a lowest-common-denominator image (that e.g. does not use the FPU, which the S2 does not have), but certainly ESP-IDF is not built for that.

(Fwiw, the way you'd normally build this is to have one or more components that contain the common code for all projects, then one project per chip that contains the config and chip-specific code and uses the common components. It still means building for every chip individually, but it makes keeping the code in sync a lot simpler.)

Regarding Wifi/BT -> scheduler. I am aware. I don't mind having an NMI interrupting my code, nor do I mind having to create a timer that calls some opaque code at strict intervals. I understand that it would pose a problem for most users though, I've seen many questions and complaints about the watchdog timer kicking in because they don't understand an event driven environment.

As I said, it's a bit more complicated than simply calling code at intervals. The WiFi/BT is built to run on a pre-emptive RTOS, with tasks that can be suspended without their knowledge or cooperation if a higher-prio task needs to run. I'm not sure if that can be replaced by a simple scheduler. You're welcome to try, though.

Can you say something about the use BT for OTA recovery, would that be possible, in one way or another? As I have quite a few in water resistant enclosures that are a real pain to access and then re-seal after the fix. Of course we're doing "fail safe" OTA (restart into new slot temporarily and only activate the slot permanently if the reboot completes). But still then accidents can occur.

The thing is that you would still need to find some way to activate the BT OTA recovery; if your running image cannot be trusted, how can you guarantee that the BT OTA recovery can be booted succesfully into? Aside from that, we have the concept of a 'factory' partition; a 'golden' image that never changes that can be used as a fallback to update from. You could put your rescue OTA in there. It does need some trigger (either external, like a GPIO, or internal, as in the running code decides to boot into it by nuking the OTA partitions and resetting) to boot from that, though.

Is there still the situation that data read from flash can only be read in aligned 32 bit words? So on the ESP8266 this has been worked around by copying all data sections to RAM on boot, which fills up RAM pretty quickly and you really need to make sure that doesn't happen + take care for this situations. Can the ESP32 access data from flash on byte boundaries? Maybe via some data cache just like icache for code? That would make some things pretty easier. I tend to have a lot of data in flash and of course I'd like to keep it there without clobbering all DRAM.

The ESP32 range of chips have a cached flash range for both code and data, and the data flash range allows byte-granularity accesses.

[eriksl]

There's still options there. Nothing that we as Espressif manufacture, so I can't vouch for or against how good or price-efficient these are, but e.g. Seeed and Adafruit have small modules incorporating a C3.

Yes I found these (and some others). Interesting option, but not very much I/O pins (may or may not suffice for a particular task, although I also use I2C and SPI I/O extenders quite often). Also I don't think any of them have SPI RAM, do they? I'd like to have SPI RAM for receiving and buffering images (for displaying on a LCD). Now I need to do that on flash memory, which of course has the disadvantage it wears out, so I can do a limit amount of updates.

I guess I just need to start somewhere, there is a lot of work to do anyway before anything will start to work, if only just the command interpreter and I2C sensor handling. Let's go and see from there.

I don't think you can. Aside from the fact that I think the ROM checks the chip versions, the CPU core on those chips is also slightly different. It may be possible to use a lowest-common-denominator image (that e.g. does not use the FPU, which the S2 does not have), but certainly ESP-IDF is not built for that.

Ah okay, I didn't get that information. I was under the impression the S2 and S3 would only differ in I/O modules (comparable to the ATmel e.g. ATtiny models, which all, from the same generation, have the same CPU core).

(Fwiw, the way you'd normally build this is to have one or more components that contain the common code for all projects, then one project per chip that contains the config and chip-specific code and uses the common components. It still means building for every chip individually, but it makes keeping the code in sync a lot simpler.)

I'll look into that, thanks for the tip. Currently I have a very simple set (I like simple...) where one exact same image is built and used for all projects I am using. The only difference is the (runtime) configuration. But I guess I will have to leave that concept.

The thing is that you would still need to find some way to activate the BT OTA recovery; if your running image cannot be trusted, how can you guarantee that the BT OTA recovery can be booted succesfully into? Aside from that, we have the concept of a 'factory' partition; a 'golden' image that never changes that can be used as a fallback to update from. You could put your rescue OTA in there. It does need some trigger (either external, like a GPIO, or internal, as in the running code decides to boot into it by nuking the OTA partitions and resetting) to boot from that, though.

Hmmm, I get it. I won't add much to my usual approach then (the golden/factory image). Actually the only problem I've been running into for the last few years was that the ESP wouldn't connect to my access points (for whatever reason, it's not always clear). I now have a workaround for that, which works quite well, using this procedure:
- set autoreconnect
- after boot, have autoreconnect run it's course, most of the time it's quickest way to associate
- if successfully associated, after one minute do a full scan, select the best access point, and if better than the current (which tends to happen very now and then), force reconnect
- if after a minute still not associated, fire up the access point mode
- if after five minutes still no clients associated, do a full reset. This is to make sure all ESP's will reconnect after some time, when the wireless network has been failing and is up and running again. No need to reboot them manually or associate with all of them.

I could change the procedure slightly to also enable BT when association fails, that would probably be sufficient.

Is there a way to have simple (fifo) byte pulls/pushes to/from BT, like UART?

The ESP32 range of chips have a cached flash range for both code and data, and the data flash range allows byte-granularity accesses.

That's good to hear. So, double check, I can read bytes at arbitrary addresses from flash, using the flash cache window? Is that one of the core major improvements of ESP32 vs ESP8266?

[ESP_Sprite]

Yes I found these (and some others). Interesting option, but not very much I/O pins (may or may not suffice for a particular task, although I also use I2C and SPI I/O extenders quite often). Also I don't think any of them have SPI RAM, do they? I'd like to have SPI RAM for receiving and buffering images (for displaying on a LCD). Now I need to do that on flash memory, which of course has the disadvantage it wears out, so I can do a limit amount of updates.

Ah, if you need SPI RAM, you need a S3 ofcourse, the C3 does not support that.

Ah okay, I didn't get that information. I was under the impression the S2 and S3 would only differ in I/O modules (comparable to the ATmel e.g. ATtiny models, which all, from the same generation, have the same CPU core).

We're a bit more free with mixing and matching CPU cores, as there are very few people writing assembly for our chips; this means we can use the compiler as an abstraction layer. Whatever CPU we use, as long as they're roughly the same (all 32-bit for instance) and we have a compiler for it, the SDK will work with it. That's also why we could get away with the switch from Xtensa to RiscV fairly painlessly.

Is there a way to have simple (fifo) byte pulls/pushes to/from BT, like UART?

Possibly, but I have to admit I don't know too much about BT/BLE.

That's good to hear. So, double check, I can read bytes at arbitrary addresses from flash, using the flash cache window? Is that one of the core major improvements of ESP32 vs ESP8266?

Yes, you can. By default, ESP-IDF will actually put const stuff (strings, structures, whatever) into flash for that reason.

[eriksl]

Ah, if you need SPI RAM, you need a S3 ofcourse, the C3 does not support that.

I seem to remember some RISC-V (C series) does support SPI-RAM or am I mistaken?

If so, I guess I will choose the S series for the foreseeable future and I hope Espressif will keep making/supporting them for some time.

Yes, you can. By default, ESP-IDF will actually put const stuff (strings, structures, whatever) into flash for that reason.

Ah ok, great. I have been doing that by hand for years now.

This actually what I did (and it's something I think Espressif should have done, NONOS SDK, but I guess it didn't have the priority)
- make all "unmarked" (default) sections from the Espressif libs go to IRAM by default
- make all "unmarked" (default) sections from other sources go to FLASH by default
- only sections marked as "iram" explicitly go to IRAM
- for r/o structs and arrays align them all on 32 bit words (offsets and sizes) and move them to FLASH section. Making them const is not sufficient, loader recognizes alignment will be wrong and has them copied to RAM on boot.
- for all strings, mark them "FLASH" sections and use a function that copies them to flash, individually, temporarily, when required.
- reconfigured LWIP to have a much smaller memory footprint

If you do all that, the net amount of free RAM (~78 Kbytes) isn't such a big deal

But I guess using IDF + ESP32 does the job just as well

[MicroController]

Maybe check out the WaveShare ESP32-S3 zero or "mini". Tiny module, with ("mini"?) or without ("zero"?) PSRAM, a bunch of IOs...
If you're used to 8266s you may want to fasten your seatbelt before powering up the S3 though

[ESP_Sprite]

I seem to remember some RISC-V (C series) does support SPI-RAM or am I mistaken?

Both the ESP32P4 and the ESP32C61 can, but these chips aren't (widely) available yet.

If so, I guess I will choose the S series for the foreseeable future and I hope Espressif will keep making/supporting them for some time.

We'll keep making them for 12 years, so e.g. for the ESP32S3 you'll have until 2033 to jump to the next chip. (Which should be fairly trivial, given we expect future chips to still be programmable with ESP-IDF)

[eriksl]

Ah great! You convinced me, success I have always been a bit uneasy with the thought, but now I am willing to take the leap