What would you like to see in The Next Chip?

[vanBassum]

I have absolutely no idea if this is even possible. But I would like to see an FPGA as peripheral. So complex timing critical stuff can be handled in customizable hardware.

[MicroController]

I have absolutely no idea if this is even possible. But I would like to see an FPGA as peripheral. So complex timing critical stuff can be handled in customizable hardware.

Maybe something more cheap/simple would do, like RP2040's PIO? Much like a CPU clock version of the FSM-ULP...

[MicroController]

I think generic timer capture hardware would be very useful for a lot of things. I.e. the possibility to have a (high speed) timer running and have hardware to "capture"/"snaphot" the current timer count when a certain event occurs, then raising an interrupt; the most prominent "event" to support would be an edge on a GPIO pin. Having hardware handle the capturing eliminates any delays/jitter a GPIO ISR can incur.

Maybe hook up the capture hardware to the INTC so that any ISR can be enabled to find out the exact time of when the hardware interrupt happened.

If the capture feature would support a FIFO or DMA we could create powerful handling of relatively high-speed digital signals in software (although we kind-of already can using RMT.)

[ESP_Dazz]

@MicroController w.r.t to the "timer capture hardware", the ETM (Event Task Matrix) on some of the newer chips (e.g., ESP32-C6) could be able to do this. It's basically this big routing matrix that allows routing certain peripheral "event" signals from one peripheral (e.g., GPIO edge interrupt event) to a trigger a particular "task" to peripheral B (e.g., capture the current count of the GPTimer).

However, the set "events" and "tasks" are fixed (i.e., not configurable by software), so you'll need to check if the peripherals you use have the required "events" or "tasks" to fulfill your requirements.

[MicroController]

@ESP_Dazz Good to know, thank you

[username]

A much better A/D converter. Pins for Vref & power to A/D converter.

[thefury]

A true successor to the ESP32, in my humble 2.5 cents (inflation!), from the perspective of an audio system, after having gone through a couple of prototypes with ESP32 and/or ESP32-S3:

• Keep the APLL, it gives a cleaner MCLK than ESP32-S3 does. This helps with signal-to-noise ratio on DACs that don't have their own PLL.
• Keep Bluetooth classic. It's still the vast majority of Bluetooth audio applications until LE Audio goes mainstream, and how long will that take? (It just made it into Android 13, will existing phones get that update and can their chips even support it?)
• More bits in the I2S registers to support higher BCLK/WS divisor; S3 was limited to TDM4 at 32-bit and this required a dual-wielding I2S to achieve 8 channels
• MOAR PINS.
  
  Between 7 pins to the DAC (I2S/I2C), 7 pins to the amps (interrupt/control), 5 pins for speaker detection and board power control, and we've only got 3 left; add anything else like a radio tuner or LEDs/buttons, and we might have to add an IO expander or another MCU.

So basically an esp32 mashed up with an esp32-p4?

P4 has me drooling over the number of pins and peripherals, but lacking WiFi and BT means it needs a separate chip for the radios (so just stick another ESP32 on the board?). I have tried that kind of thing before, an esp32 and an esp32-s3 on the same board to get Bluetooth classic & APLL from ESP32, and USB & TDM from the S3, but this then complicates the system quite a bit

• Finding a peripheral to communicate fast enough (UART? I managed about 20 Mbps at the most with flow control; SPI was counter-intuitively much much slower due to the need for bidirectional asynchronous communication, and the SPI master does not know how much data the SPI slave needs to send)
• Managing the communication protocol
• Remotely controlling GPIO
• Firmware updates
• What happens if one crashes

It adds a lot of code and things-to-go-wrong compared to a single integrated SoC with one firmware binary.

[faptastic]

Bring back 24-bit or greater parallel output.

ESP32 supported 24-bit parallel LCD... but didn't have enough GPIOs!
S2 does, but apparently doesn't work with PSRAM properly.
S3 has a GDMA that can pull data from PSRAM... but only a 16-bit LCD interface.

[ESP_Sprite]

The ESP32-P4 will have the 24-bit LCD interface again.

[eriksl]

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).