What would you like to see in The Next Chip?

[ESP_Sprite]

I think the S3 is already amazing. I now have a version with 4 Mbytes of flash and 2 MBytes of RAM in the package. The amount of RAM is actually decadent, I don't think I will need anything close to this anytime, but it's good to have more than the built-in RAM for some things. I might need to have more flash though, but IIRC there are already versions with more flash. The base code for a simple "hello world" app appears to be already like 500 kbytes... That's quite different from what I was used to on the 8266.

The built-in hardware USB serial (ACM) is the best. No more fiddling with UART adapters for obtaining logging or programming, just plug and play.

I also like the way you can configure how many RAM is used for caching (I/D). So if stuff gets a bit tight, you can always configure the caches to be smaller.

Also I noticed that RTC fastram, is actually available to both CPU cores on the S3. In many documents I read that it's only available to the first core. Is this something new on the S series? I am glad it is, I am using it for (reset/crash) persistent logging memory on the second CPU core (and it works like a charm).

So I can just think of, as this seems to be the future for the ESP32, a RISC-V version that can do exactly this. The current "C" versions cannot compete with the S3 (yet).

Thanks for the nice words, it's always good to read that people enjoy our products. When we have a follow-up to the ESP32-S3, it's 99.9% sure to be a RiscV-based chip - we already have the tech for fast multicore RiscV chips, the ESP32-P4 is an example of that. And yes, the 'rtc mem can only be written from core 0' is an original ESP32 thing, iirc. (It's one of the remnants of that chip initially being designed as an AMP chip rather than a SMP one.)

[eriksl]

Does this confirm my assumption that Espressif is moving away from the concept of having all system-related tasks running on CPU 0, user tasks on CPU 1 and then imposing limited access from the CPU 1 to system resources? Because I can start (user) tasks on both cpu's...

[DrMickeyLauer]

Let me toss in another vote for evolution, instead of revolution.

I also think the ESP32S3 is a very good chip in its present form. If there was a way to get an updated version (lets call it S6 for now), I'd like to see three things ­– in the order of importance:
0. More IRAM. Really, that's the most important thing right now. PSRAM is too slow for many applications.
1. A newer TWAI IP core. Let's call it… TWAI/FD
2. Faster GPIOs. I reckon we already have PWM, RMT, and MCPWM, but often bit-banging is the easiest way to get something going.

On top of that, the usual suspects like better ADC or a more beefy ULP that can, e.g., control peripherals.

For my applications, I don't need more cores. My CPU is already idling most of the time.

[copercini]

Let me toss in another vote for evolution, instead of revolution.

I also think the ESP32S3 is a very good chip in its present form. If there was a way to get an updated version (lets call it S6 for now), I'd like to see three things ­– in the order of importance:
0. More IRAM. Really, that's the most important thing right now. PSRAM is too slow for many applications.
1. A newer TWAI IP core. Let's call it… TWAI/FD
2. Faster GPIOs. I reckon we already have PWM, RMT, and MCPWM, but often bit-banging is the easiest way to get something going.

On top of that, the usual suspects like better ADC or a more beefy ULP that can, e.g., control peripherals.

For my applications, I don't need more cores. My CPU is already idling most of the time.

I agree with most of it, especially the TWAI/FD feature

Also, Ethernet is an important feature, at least for me. Most of our products are "stuck" in the standard ESP32 because the ESP32S3 has no Ethernet MAC. And the S3 has ~10 extra pins, it would be perfect for this, since Ethernet uses almost all the good standard ESP32 pins

[ESP_Sprite]

Does this confirm my assumption that Espressif is moving away from the concept of having all system-related tasks running on CPU 0, user tasks on CPU 1 and then imposing limited access from the CPU 1 to system resources? Because I can start (user) tasks on both cpu's...

I don't think we ever had that concept in a production CPU. The ESP31 (ESP32 beta silicon) was designed like that, but we modified that for the ESP32 to make CPUs mostly the same. There were still one or two leftovers from the ESP31 in that chip, like only being able to access RTC memory from one CPU, but the later chips (S2, S3) did away with that altogether. As it is, you should be able to run any task on any CPU.

1. More IRAM. Really, that's the most important thing right now. PSRAM is too slow for many applications.

That's a bit complicated; more internal RAM gets physically larger, and that means it can't run at CPU speeds anymore, and that brings a lot of complexity. For instance, the P4 runs at 320 or 400MHz and has 700'ish K of internal RAM, and we couldn't get that directly coupled to the CPU anymore. Instead, it needs to be wider to get the data throughput and has a cache to adapt it to the CPU speed, but suddenly this means internal RAM accesses aren't deterministic anymore and you need to keep things like flushing caches in mind when you do DMA.

1. A newer TWAI IP core. Let's call it… TWAI/FD

We're looking into that, but it's a bit hairy. Patents on CAN 2.0 have expired, those for FD haven't yet.

2. Faster GPIOs. I reckon we already have PWM, RMT, and MCPWM, but often bit-banging is the easiest way to get something going.

Did you look at the 'fast GPIO' already? It only gives you 8 pins, but it is a lot faster than the regular GPIO interface.

On top of that, the usual suspects like better ADC or a more beefy ULP that can, e.g., control peripherals.

Check the ESP32-C6 for that. It has a pretty fast RiscV core as its ULP (20MHz, around 2.5 coremarks) and when the chip is not in deep sleep, it can access all the peripherals the main CPU can. The P4 also will have an ULP like that, but at 40MHz.

Also, Ethernet is an important feature, at least for me. Most of our products are "stuck" in the standard ESP32 because the ESP32S3 has no Ethernet MAC. And the S3 has ~10 extra pins, it would be perfect for this, since Ethernet uses almost all the good standard ESP32 pins

We're certainly not abandoning the Ethernet MAC. The P4 has one, and I'm decently sure it'll make a comeback on radio-equipped chips as well.

[eriksl]

Interesting! Sometimes I still see CPU 0 being mentioned as the "PRO" CPU and CPU 1 as the "APP" CPU... I wouldn't have minded if Espressif would have stuck to that concept, but this way is fine with me too.

In my very humble opinion there will be very few use cases for huge amounts of internal RAM. I am very happy with the PSRAM option. Apparently you can connect up to 16 Mbytes (and access it directly)? That's enormous! So if you need memory in that amounts and needing it to be as fast as internal RAM, I think you actually need some dedicated hardware, FPGA or DSP. Yes they will be more expensive. Reminds me of the time people thought buying a $2.00 ESP8266 would give them a cheap access point.

Now I think of it, with 16 Mbytes of RAM, one could actually run Linux on it. I am not sure if the MMU is flexible enough to implement stuff like fork() and DSO's though. The documentation suggests it can though. Add a USB SSD and you'll have swap too .

On that subject: I've looked for PSRAM for my ESP8266 for years. I know it can't use it directly, but accessing it through SPI would have been enough for me to store large blobs. The sizes of the RAM chips have been through the roof, especially when going a bit bigger. Now the ESP-S2 and ESP-S3 come with PSRAM sizes that, if even available, would have cost 10 times or more the SoC itself. How is that even possible? Have developments gone in turbo mode in that area?

[DrMickeyLauer]

FWIW, when I'm talking about increasing the IRAM, I speak of a dimension like 1MB. Honestly, I wouldn't refer to that as "huge"…

[eriksl]

Just to have it clear for me, you want to have 1 Mbytes of RAM where your code runs from (IRAM...)? Without ever needing to wait for the flash cache to load any of it. Personally I still think it's an insane amount. I can't think of an application where all of the code needs to be local to the CPU at any time. And if there is a real need, I personally (still) think it's not a microcontroller application. More like microprocessor (software) or FPGA/DSP (hardware).

BTW I grew up with ATTiny's and later ATMega's, having 256 bytes to 4k of RAM. To me 1 Mbytes of any type of RAM is insane anyway .

[mi2024]

A dev board with the form factor of a XIAO ESP32S3, but without the need to depress the Bootloader and Reset buttons every time you want to upload a new sketch. One may argue that depressing those buttons is no big deal, but consider that an IoT project could very well entail the MCU/circuit board being housed in some sort of enclosure that's a pain to disassemble every time you want to upload a new sketch.

[eriksl]

Agree completely. When you're developing a somewhat larger project, in C, you'll need to flash even very frequently. Now with my Wemos/Lolin mini-S3 board that's a breathe, because I only have to run "idf.py app-flash monitor" and wait. I think that's really a requirement. Isn't that board something for you?

For being able to re-flash a project in a tightly closed box, I now have made OTA-over-Bluetooth