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.