What would you like to see in The Next Chip?

[rin67630]

How do you mean, wake from deep sleep without hardware modifications? Also, what use case would you have to compile sepate things for both cores?

...wake from deep sleep without having to tie a pin to RST.
Compile one core to gather data and the other one to form/transmit data.

[ESP_Sprite]

On the ESP32, there's no need to tie RST to GPIO16; that is an ESP8266 thing. And with the current SDK you can already happily start a thread on one core to collect data and one on the other core to send it. Are you sure you have worked with the ESP32 before, and are not confusing it with the ESP8266?

[-31253-]

CAN 2.0 module , more UART module, maybe some functional safety module and software, compliance with IEC61508\IEC60730 standard,,etc

[barometre]

Hi,

After using ESP32 till this time, my revised suggestions would be like this:

-5ghz support
-USB 2.0 slave/host options.
-Some kind of lcd interface, preferably lvds
-Internal video decoder/encoder (doesnt have to 1080p or something low res is okay)
-TDM audio
-Small DSP for audio
-Preferably bluetooth chip can have fm receiver too but not very important.
-Low res camera interface

With these futures it will have wide use areas. Like usb dongles, media players etc... If it would have video decoder and video output option it can be even used as cheap android auto receiver.

[rin67630]

On the next package like WROOM I'd expect an integrated 32.768KHz/10ppm Xtal for a decent sleep timing.

[davydnorris]

Wi-Fi RTT: We actually have a fair bit of the hardware needed for something like this already; we just haven't had any requests from big customers to write the added driver support for it (at least, that's what I understand); also, I'm not sure if hardware support actually has been tested in any way; for all we know it may be broken. Don't be surprised if something like this pops up in esp-idf in an upcoming version, however.

Apart from the common 5GHz wifi request, this would be very interesting to me. I am working on two areas that would benefit from this:
- large scale mesh networks that work with deep sleep
- real time protocol (RTP) for Audio over IP applications using AES67 or RAVENNA

In each case, having a high precision RTC and the ability to precisely synch each device's RTC over the network is essential

[ninjaneer]

I was going through MS's new security white paper on what they've identified for their devices, Seven Properties of Highly Secure Devices, and of course the hardware based root-of-trust one is the piece that stands out. It would be nice to have a hardware-implemented, cryptographically-backed way to identify and certify each chip.

The rest looks nice, but it's something that most serious scada engineers can implement on an as-needed, roll-your-own-for-obscurity basis.

[markwj]

No more dual-use strapping pins, please. The GPIO2 and GPIO12 vs SD CARD has been a nightmare for us. Overall, messing around with SD CARD issues probably set our project back about 6 months.

[daslolo]

LVDS would expand our display options and would require a 2D accelerator https://www.reddit.com/r/esp32/comments ... the_esp32/

If it's possible, a section of the chip is an FPGA then we'd have possibly super high speed IO, but FPGA would have to be configurable by C code alone so in the Arduino layer we could make cool things whilst remaining lazy

[burtrum]

1. Mechanical Switch Debounce in HW.
2. Rotary Encoder Switch Decoder.