Is the 8266 processor supported ?

[Sonic_Amiga]

Hello everyone? Are there any Espressif members present here ? Is ESP8266_RTOS_SDK supported or not ?
The documentation states that there's an ongoing process of merging 8266 support to ESP32-IDF; but i see no results. The ESP8266_RTOS_SDK has a good degree of compatilibity, so it's easy to port applications.

There are some long-standing issues in this SDK, which can be considered critical. The last activity in the master branch repository took place in about march of this year. I tried to mention people, seen in logs, via '@' and ask for help, with no response.
Yesterday i saw some small burst of activity, some updates to wifi libraries, nothing more. Again, i failed to reach the person who does updates.

Is this SDK supported ? What's the overall status of 8266. Did the company simply decide to abandon it ?
If so, is there any ongoing community effort ? I'd like to contribute.

[cruvus]

Very good question...

[Inq720]

This is just my opinion.
Although the website says they will keep making the ESP8266 into 2026, they are trying to get people to move to the ESP32 derivatives. Have been for years. The ESP8266 can not really be locked down for IP or security concerns whereas the ESP32 can. The ESP8266 is just marginally powerful enough to run an HTTPS website in the NonOS version... for like ONE user. I would guess, trying to run anything real-world useful under a multi-threaded RTOS system is even more discouraging. IOW... people would give them more grief over the results than just trying to migrate them to using ESP32 devices.

[eriksl]

Yes it's like that, for most "real" manufacturers the ESP8266 isn't actually that interesting for various reasons. It's a great chip for hobbyists, amateurs etc, because it actually can a A LOT, also a A LOT more than most people think, but to achieve that, you need to make some effort (like for instance, make sure all strings are in FLASH and not copied to RAM, it will fill up all of your RAM instantaneously). Also there is no real debugger, you will have to live with the very limited and buggy SDK (the NONOS SDK). For a hobbyist, that is no problem, for a manufacturer, it's hell. The only issue for hobbyists is that there is very little REAL documentation, just lots of the obvious that's not interesting. So you need to use buggy SDK, you cannot write (all of) the hardware interface code yourself (and solve this issue).

Anyway, yes, it's clear the Espressif lost their interest in the hobbyists sector a long time, as soon as they made their name.

For us that will mean:

- as soon as the chips are no longer made, hog them, build a stash
- see if we actually can use the ESP32, although it obligatory comes with the IDK which allows even less access to the hardware, and find a way to make it solderable in our projects (the pin pitch is even smaller than ESP12).
- and if not, try to find an alternative. But at the moment, there are really none. Otherwise I'd have switched already.

[ESP_Sprite]

Honestly, the ESP8266 by now is a 'mature' product meaning we will still produce the chips and fix security issues etc, but for any new things it makes a lot more sense to go with an ESP32-ish chip. The ESP32-C2 has variants that are cheaper than the '8266, but are more powerful and have more RAM simply because we've become a lot better at designing chips since the ESP8266 days, allowing us to pack more functionality on the same bit of silicon. I'd also say that the ESP32 series have *more* support for poking the hardware directly if you so please: for instance, the documentation has gotten a lot better as during the ESP8266 days we documented the APIs but nowadays we document the hardware details. This already has lead to loads of alternative SDKs popping up: for instance, Rust, Nuttx and Zephyr are options if you don't like ESP-IDF, and they mostly could do their job as we've gotten a lot better at documenting stuff. Even the CPU core has gotten better in that respect: while the ESP8266 had an Xtensa core that never had official docs released (because legal reasons) the RiscV in the ESP32-C series is an open architecture.

Sorry for the rant, but I disagree Espressif left hobbyists behind. It's simply that most focus, both from us and the community, has been shifting to the ESP32.

[eriksl]

Don't be sorry, I am very glad somebody from Espressif comments on my sorrows. Please continue to comment.

My personal issue is that although the ESP32 has really more features and capabilities, I really don't need them. Most of the ESP8266's fearures work for me. There is no hardware PWM support, but it can be made really well in software, almost as good as a hardware implementation and also still a bit more flexible. Same thing for I2C support, it's nice to have it in hardware, but a good software implementation works just as well and is also more flexible. Having more RAM is nice, but if you use it wisely (avoid copying of strings from flash to RAM), it's amazing what's possible with the amount the ESP8266 has. The SPI support is quite sufficient for most applications. I can do everything I want using ESP8266 (resulting in a 38000 line image of 350 kbytes). Using Richard Burton's excellent "rboot" code I can even do OTA firmware upgrades without any restrictions (e.g. no cloud service required and using one single image address for multiple slots). The only complaint I still have is the very poor documentation of hardware access. Like I was used to on microcontrollers I used before, like ATmel, Microchip microcontrollers. I am convinced I should be able to use a microcontroller without the required use of any opaque blob of manufacturer code. Maybe only for radio licensed stuff like wifi, but that's all.

So what I am looking for (as possible replacement for ESP8266):
- it should be possible to be soldered by hand (sufficient pin pitch), but small nonetheless; I should not be required to use a complete development board for that, I need something like ESP12
- full access to all hardware (minus wifi), no requirement to run an "operating system" (I will do that myself), hardware properly documented so it can be done.
- possible to do OTA firmware upgrade without restrictions, without manufacturer support and using one single image (address) (like rboot does). It doesn't need to have been implemented yet, it just needs to be possible.
- use my own compiler and tools, preferably plain vanilla without manufacturer supplied patches required (as they tend to be not supported for newer versions)
- use plain upstream lwip, preferably so that I can configure it myself (I don't need most of it, only takes up valuable RAM).

I am very curious!

Thank you!

[ESP_Sprite]

Don't be sorry, I am very glad somebody from Espressif comments on my sorrows. Please continue to comment.

I personally really like the ESP32-C3, but I honestly tend to work with the things ESP-IDF gives me (I mean, I help developing it, so I'm pretty much biased to think it's pretty good).
- Dot pitch on the base C3 is 0.4mm rather than 0.5. You can get them with flash integrated, though, and even in the same package size as the ESP8266 in the form of the ESP8685. If you're still looking for a 0.5mm package, you can pick the ESP8684; it's an ESP32-C2 plus integrated flash. While the C2 is less powerful than the C3, it still beats the original 8266 wrt speed, memory size and peripherals, and it tends to be cheaper than the 8266 to boot.
- The canonical module I tend to use for a replacement of the ESP12 is the ESP32-C3-Wroom-02. Again, the castellated pads are at a bit smaller pitch than the ESP12. I personally never had any issues soldering them, but YMMV obviously.
- Hardware docs for the C3 are here. It's a good 877 pages, so I'd posit we at least attempted to make the hardware accessible. Only exceptions are WiFi and BLE (for obvious reasons) and cache control (for reasons that mystify me a bit, but hey; if you need any details there, feel free to ask.).
- I think by default we use LWIP plus some patches, but the WiFi and LWIP driver are decoupled, so you could simply chop off LWIP and use your own driver stack.
- OTA is trivial. The ESP32 series have a better MMU, so you can simply define multiple OTA partitions in flash (of more-or-less arbitrary size and position, as long as they're aligned to 64K) and dump the same image in there and expect it to work. We have support in the bootloader to pick the 'correct' image, but the bootloader is open and hackable, so if you don't like the mechanism, you can use your own.

Some things that may be dealbreakers if I read between the lines:
- Note that if you want to run WiFi or BLE, you do need an operating system. This always has been the case, even with the 8266; it's simply that the 'no-os' SDK used a tiny scheduler OS integrated into the ROM to do its thing. Note you can always replace the OS with your own; the WiFi stack has bindings you can fill in with your own implementation. (Rust/Zephyr/Nuttx/... do that.)
- It's harder to use the ESP-IDF drivers as 'reading material'. As they need to support a high number of use cases and hardware, hardware support in ESP-IDF is layered: there's the drivers, then the HAL, then the LL layer. That makes it a bit labyrinthesque if you want to figure out what bit is set by what. Advantage may be that you might find the LL layer or HAL are more usable than poking the hardware directly.

And one positive thing I like very much (but I'm very biased on this because of reasons) is that the C3 has an integrated USB-serial-JTAG adapter. For most use cases, you can simply connect an USB cable directly to the two USB GPIOs, and you get the functionality of both your USB-to-serial adapter as well as a JTAG adapter for free. Given most of my designs tend to have an USB connector anyway (for charging or power), this tends to make it really easy to reprogram a board when I have it on my desk.


Btw, if you're interested in that, the ESP32-C6 is also fun as it has a small 20MHz secondary RiscV processor that can also run in deep sleep. It's pretty easy to program and fun to play with.

[eriksl]

Oh my, thank you so very much! This is information I have been trying to find for a long time! This could really be the tipping point for me to switch over to ESP32.

Please bear with me and answer another lot of questions (sorry!) from me!

So, I am coming from ATmel microcontrollers, and I am used to having a blunt piece of hardware you'd need to completely drive yourself. I have no problem there, I have a degree in computer science, major networking / operating systems, so for me it's a very nice challenge to create the complete "operating system" here. Any "SDK" or "IDK" code that is required, is just in the way for this. Having said that, on one hand I've seen bits of source code of the ESP8266 SDK (e.g. the I2C implementation) which I wasn't quite enthusiastic about. Also the standard OTA stuff is really unusable. On the other hand, the IDK seems to be a decent piece of work and there is no sense in replicating something that's already good. Maybe if it can't exploit the hardware fully, that might be a reason to bypass the IDK. I hope that is possible.

Anyway, what's the general direction Espressif is heading to? When I decide for a certain model of the ESP32, I'd like it to be the golden standard for at least five years (so I don't need to design new PCB's every time and maintain multiple versions of the software). Is Espressif heading towards RISC-V? In that case I think it would be wise to start there anyway. I like the concept of the dual processor core of some ESP32 Xtensa versions, but it looks like Espressif is abandoning that path? Is the Xtensa arch going to be left completely at some point?

BTW I am looking for a module, the IC, 0.5 mm pitch is something I can't solder anyway . The ESP12 has a pin pitch of 1 mm. For that pitch, SIP pin arrays and sockets are available and it works great. I don't like soldering modules to a PCB. It looks like all ESP32 modules not using standard 2.54 mm DIP (too big for me) are using a pin pitch smaller than 1 mm and I can't find sockets for them. I hardly think I can even solder them at such a small pitch. So that makes the ESP32-C3-Wroom-02 less ideal.

I generally dislike packages/modules that have built-in (internal/on the die) flash because it's too small. I need 4 mbytes for two slots of 1 mbyte images and two slots of 1 mbyte for data.

I have been reading the ESP32 hardware documentation, but that was in 2021, so I guess that has improved somewhat in the meantime.

Great to hear there is no more opaque coupling between driver and lwip, like the ESP8266, where we're stuck to a very old version of LWIP. As I understand it, the interface could be very "light", just sending a frame and receiving a frame, maybe with some options flags.

Also great to hear OTA is now supported properly and open! This sounds very good. Can I just write random flash sectors and then reboot into that? That's all I need.

I am aware of the need for some support to be using Wifi or BT. It cannot be implemented in hardware only. I am fine with calling some opaque code frequently (preferred) or to return to the base code (as in the ESP8266) frequently. I am doing this now, no problem. I don't like large chunks of code running continuously anyway, I prefer using a scheduler. My gripe with the ESP8266 SDK is that it's required to be used for all sorts of non-Wifi-related stuff and then from the linker draws in all sorts of (for me) unrelated code from the SDK, filling up icache.

Are you saying all IDF drivers are open source? I wasn't planning to implement full alternatives, but sometimes it can help when documentation is insufficient. In my opinion on the ESP8266 what's called "drivers" are either software implementations to workaround missing hardware support or a very thin layer, which is not really helpful (for me).

I understand your stance on using hardware abstraction. Normally I am a fierce promotor of that standpoint too, but in a very low-level microprocessor things are bit different I think. If only to be able to get to know the hardware.

Another question. I know some of the newer models of the ESP32 support SPI RAM. I think that is very interesting (e.g. for mp3 and jpeg decoding). So I am searching for a module that does this:
- preferably 1 mm pin pitch (but probably not available)
- dual core processor
- either Xtensa or RISC-V model (preferably the one that has the future within Espressif)
- small (no development board, more like ESP12). Bigger may be possible, maybe even 2.54 mm pitch, but then I'd need to position parts beneath the module.
- 4 Mbytes of flash
- SPI RAM
- USB optional, not required. Normally I do the first programming in a separate programmer (so that's why I don't like to solder the modules to the PCB). Very rarely I screw up OTA and then the module needs to be reprogrammed. But if I can't work out a removable module option, this may be required.
- cheap... I need quite a few (but not industrial amounts).
- I do not need JTAG or any other debugging tools. Have come by without them for quite some time now.

Sorry for the amount of text.

Thanks!

[eriksl]

BTW I just found out that WeMOS makes nice small modules using the ESP32-S2FN4R2 and the ESP32-S3FN4R2. The first one is very affordable, single core but I can live with that, also less memory, but has SPI RAM, so probably not an issue too. A bit disappointing it lacks MCPWM but I can live with that, but the omission of BT is really a shame. I'd like BT to use (if possible) to do an emergency re-flash when OTA failed and the PCB is unreachable (due to water resistant mounting).

The S3 version has all of this, but is hard to get and far more expensive.

[ESP_Sprite]

Hah, I worked with AVRs for a long time myself as well. It was actually a pretty large step for me to move from assembly to C; I still have so many old .asm files around... The ESP32 ecosystem is fairly different in that sense: because the chip is so much more powerful, it also is a fair bit more complex; for me, in 99% of the cases, it makes sense to just use the ESP-IDF drivers rather than try to go down to a lower level. (There are exceptions, obviously, but there's no need to waste time reinventing the wheel if the existing drivers already work.) ESP-IDF doesn't physically separate you from the hardware, by the way, if you have a peripheral and you don't also use an existing driver for that, you're free to poke the hardware bits in whatever way you please.

ESP32 support is generally the same as ESP8266: 12 years from the point we release a chip. The nice thing is that ESP-IDF is more of a shared codebase, meaning things like a new version of a library we use benefits all chips supported as we don't need to update multiple SDKs. We're generally moving towards RiscV, but if you use ESP-IDF and C, it doesn't really matter much, the compiler takes care of any differences. We're certainly not abandoning dual-core: the last few chips we released happened to be single-core (although that's debatable in the ESP32-C6 as it has a low-power coprocessor) but e.g. the to-be-released ESP32-P4 is going to have two 400MHz RiscV cores.

WiFi and BT need a bit more than a scheduler, unfortunately; they assume a pre-emptive multitasking core. (This kinda makes sense anyway, as we intend the dual-core CPUs to be SMP rather than AMP, which makes it easier to distribute CPU loads.) In particular, this is the list of functions it needs; at least up to _rand, they're all OS functions.

On the modules: I advise the Wroom-02 modules as I find them easy to solder and reliable, but an added reason is that I can get them from work as they're produced by Espressif There may be other modules out there like the Wemos, and if they're more convenient for you, I see no reason not to use them. Same with using a socket: I've never felt the need for me as I am comfortable programming an ESP32 chip from scratch in-circuit, but if you feel more comfortable using a socket, I'm sure you can get those as well.

The thing wrt the 'internal' flash in ESP32 chips is that it is in-package rather than on-die; there's effectively a bare SPI flash die dropped on top of the ESP32 die and that all is put into a package. Nice thing is that you trivially can put 4MiB of flash into a package like that; there's even variants with 8MiB flash, or 4MiB of flash and 2MiB of PSRAM internal to the chip package.

OTA: Yep, you can more-or-less write sectors, tell the OTA subsystem that you want to flip OTA partitions and go. Note that the ESP32 has a concept of partitions, you generally don't do 'raw' writes to the flash, but that's just a thin abstraction.

IDF drivers are indeed all open source (as I said, with the exception of WiFi, BLE and some cache stuff). It's all here; you can download and mess with it if you want, and even do a pull request if you find a bug or want to make an improvement public.

With your list of requirements, you'd want either an ESP32-S3 or a 'classic' ESP32 (no suffix) module. Both are dual-core and can handle PSRAM. The former is newer and has better features, but the latter is mature and there's lots of info to be found online.

If you want to get a better idea before you decide, I already pointed you to the ESP-IDF source, but you may also want to look at the included examples to get a feel for how we intend all that to work together. Generally, if you want to know more about the hardware of a certain chip, make sure to look for the datasheet and what we call the 'technical reference manual'. The former has all the electric specs, the latter has the details on peripheral registers etc.