What would you like to see in The Next Chip?

[ESP_Sprite]

PHY's likely not going to happen, given the process requirements likely are pretty different from the rest of the chip; I don't think we can integrate the two on one silicon die easily.

[Hackswell]

I'm just a beginner with embedded controllers, and my interest is more in the devkit rather than the actual "chips", but here are a few items I've thought of:

* [esp32] Totally agree with more DMA accessible RAM that others have said. As attached displays and streaming are growing more and more, you can't have enough DMA RAM!
* [esp32] Everyone seems to be talking "extras" of the ~~CAN~~ TWAI, I2S, etc. Would more pins on the package be an option instead of muxing even more into the same number of pins? Pins could be placed closer, or even "bonus" pins on bottom. On a devkit, do something like the Teensy 4.0, where there are PLENTY of pins for general use, but for those with insane amount of peripherals, extra pads on the bottom or some such?
* [esp32] Better separation of church and steak? Reading around it seems that certain HW only runs on core0 or core1. I've seen users getting trapped with having to use core0 and core1 with certain constraints (timers, DMA, interrupts, etc) that then interfere with other portions of the chip or even might be mutually exclusive.
* [devkit] usb-c interface?
* [devkit] more boards with PICO form-factor that will fit better on standard breadboards. The devkit is sooo wide! (I totally understand though because the WROOM/WROVER modules are rather "fat" themselves.)

[pataga]

Big thumbs up for :
1. RISC V cores - simply because you will have more software engineers willing to invest the effort if the knowledge is transferable, and so, a bigger pool of software engineers who can contribute to developing drivers, toolchain improvements, applications.
2. DMA to/from PSRAM to SPI, I2S, DAC - to support graphic LCDs, audio applications, with working (no byte-ordering workarounds) 8/16/24 bit support.

[fearless_fool]

The more things that can wake the processor from sleep, the better.

One that I've not seen anywhere is a "sleepy UART" mode that draws almost no current until a start bit is seen, then proceeds to capture the entire first byte as it wakes the processor.

If you want a longer discussion about optimizing the RF MAC layer for low power, we should start a separate thread. (I was chair of the IEEE 802.15.4B standards body and co-founder of Ember Corporation, so I've done a lot of work here.) Exploiting RF capture effects, "fast-fail" on corrupted packets, synchronizing transmitter and receiver to minimize the time the receiver is powered on and a few other techniques come to mind. Some of that can be done within the 802.11 standard, some require bending the rules...

[svenbieg]

I'd like to see a new memory manager based on my Clusters-algorithm.

http://www.github.com/svenbieg/Clusters

Best regards,

Sven Bieg

[leoncoolmoon]

smaller, faster, less power consumption, more examples

[boarchuz]

The same capability as at least one new competing product to maintain WiFi connection with average current <50uA.

[Baldhead]

I agree with @pataga

[PeterR]

@ESP_Sprite

CAN is a bit of a... thing. I won't say we have a CAN controller in our chip (because of ...reasons), but I can say that the ESP32-S2 has a peripheral we call the 'TWAI (Two Wire Automotive Interface) controller'; which happens to be fully compatible with the peripheral you used to use for that on the ESP32. (If it's still not clear, TWAI in chips after the ESP32-S2 should be an 100% compatible ISO 11898-3 protocol implementation; TWAI in the -S2 is 99.8% compatible.) The TWAI interface will likely also appear in selected future chips, and we don't rule out that we may decide to put more than one in a chip.

Hey; maybe caught you on a Friday night comment but may I confirm that (1) the ESP32 is ISO 11898-3 compatible (sans existing errata publications) & (2) that any apparent equivocation around 'CAN' compatability is purely about commercial trade mark considerations?
Do you have certification to support the ISO claim (please enumerate compliant platforms)?
If no, what are the drop offs?
EDIT: Listed by chip - errata link accepted.
EDIT:

in chips after the ESP32-S2 should be an 100% compatible ISO 11898-3

So I suppose I need a clear statement as where ESP32 drops off from ISO 11898-3 (if we cannot say CAN). Also as ISO 11898-3 is <=125Kbps what I might expect at 256K, 512K (Sort of ISO 11898-3+ but not CAN) etc. Ideally with some practical notes & work arounds.

[csoapy]

CAN-FD since it's used in more and more cars.
And 2~3 CAN controllers as in most cars.