What would you like to see in The Next Chip?

[boarchuz]

Functionality to help with very low power projects. I think the ULP coprocessor is amazing and underutilized. I know there has been talk in here already of making it easier to work with.

-Faster boot time (and/or faster wake from deep sleep if more feasible)
-Faster WiFi connection time (I'm still convinced there's some kind of serious low-level bug with WPA2 connections). Even on par with 8266 would be a solid improvement.
-Boot directly to ULP program if this is technically possible. It could then be used as a kind of user-programmable 'bootloader' for the main cores at very low power. eg. Monitor battery voltage, if power good then enable higher current LDO and then wake chip, otherwise continue waiting or taking low-power sensor readings until there's enough power available to wake up and transmit.

[Agree007]

When can we expect to see the next new chip?

What is the current list of confirmed spec for it?

[edigi32]

- 32 bit PCNT counter (with capture possibility)
- better interrupt latency (even when using C/Arduino)
- better ADC (less noisy conversion, better linearity)

[arunbm123]

Proper documentation of Examples and API

[Jeroen88]

I would like to have an accurate core wake up from deep sleep and an accurate ulp wake up at an exact time. Currently timing is dependent on temperature an crystal accuracy.
Also I would like to restart the ulp timer at the start of the ulp program, instead of at calling 'halt', to make restarting the ulp program independent of the duration the ulp program was running

[M@rcel]

A 2nd Canbus controller would be very useful for automotive applications.

[Deouss]

Faster ram and much more ram available in continuous blocks of memory would be a dream.
Also increasing carrier frequency for RMT up to 433Mhz would help greatly.
Mandatory thing - make better and clear documentation for I2S !!

[earlyAdopter]

A 2nd Canbus controller would be very useful for automotive applications.

CAN Controller
I did not see ESP_Sprite mention of the CAN controller in the 30pages here. I hope we've kept the CAN controller. And as mentioned above, do consider adding another controller i.e. if that ship hasn't sailed already.

And as a nice to have, make that a CAN-FD controller which supports up to 5 MBaud.
Eg: https://www.nxp.com/docs/en/fact-sheet/ ... TRLFUS.pdf

Reliability/Quality
Do consider putting out reliability & quality information for the hardware. By that I mean publish the Mean Time To Failure (MTTF) or Failure In Time (FIT) information. I am sure(hope) such testing was done for the ESP32. This is much needed in IoT applications in the industrial/automotive environment. On that note, I'd be very grateful if this info is already available for the ESP32 and anyone can point me to that.

High Temperature Operation
Hope the chips continue to be made for the -40°C to +125°C temperature range.

Increased Encryption Bits
Be nice if the chip directly supported storage of hardware encryption keys. Say about 16 keys, each being 256-bits. If I recall correctly, I think the current number of bits available for the user are 768 bits.

Memory Protection Unit (MPU)
Is there going to be support for MPU in the next chip? Be nice to be able to physically guard/restrict application software to the MPU and from accessing any other memory outside defined interfaces.

[arunbm123]

proper documentation

[jcsbanks]

S2 improvements to the dual core ESP32 whilst retaining CAN would be awesome. I don't want an SPI CAN controller for size and latency, the ESP32 is awesome for CAN.

The main S2 improvements I want are the ability to address larger flash and PSRAM.