ESP32 Forum

I would still consider Risc-V /64bit - why not - architecture is perfect for ESP64 )
Going with ARM increases costs unfortunately ...

I think also more details into the functioning of the peripherals would be a good investment as it should carry forward to new processor designs, e.g. an ADC that delivers accurate results.

Absolutely ! Unfortunately not paying enough attention to the peripherals and peripheral control, i.e. getting the embedded micro-controller right. This is why it makes commercial sense to design and sell a board with a Cortex M4 with an ESP32 as "wifi co-processor". Board pinouts from the Cortex M4.

E.g. https://www.evelta.com/metro-m4-express ... gKoqPD_BwE

Go figure.

tvoneicken: Point taken wrt power saving. I think there's also some discussion about this internally; I think there should be some improvement here in next chips. Wrt ADC: we're aware that the current one under-delivers in light of what is seen as 'normal' in the industry. Even the ESP32-S2 already should have some improvements here.

Besides what has aleady been said or even confirmed for ESP32 successor:

[*] USB 2.0 Host Mode
[*] 5GHz WiFi (RTT FTM is a nice add-on)

We would also like to see [*]low power Bluetooth LE. Both advertise (ADV) and subscribe to GATT services.
Currently the ESP32 takes about 3mA with the newest firmware, even with the optional 32Mhz Crystal,
while competing Bluetooth focused chips take about 10 µA.
Source: https://esp32.com/viewtopic.php?f=2&t=1 ... 0&start=20
Any hardware improvements here are very appreciated.

I've almost forgot to ask here :
It would be nice to change the OTP fuses with EE fuses. Would it be possible by adding erase mechanism if security is removed ?

Hi!

I read the entire branch, but did not notice the answer ...

ESP32-S2 will have fuses with EE fuses?

I think, I already messed up the chip in an attempt to study the documentation on "Flash Encryption + Secure Boot + Encrypted OTA" ...
For beginners, the documentation on this topic is a real HELL!

The firmware has already been written.
But I can’t bring the device to the market without this ...

And it turns out this dependence:
Documentation HELL -> solving customer problems takes a lot of time -> chips are not bought as fast -> Espressif Systems does not make money.

No, it does not have EE fuses. In general, being able to reset security fuses is something that is not very easy to implement without making 100% sure there aren't any security holes in it that would allow an attacker to pull shenanigans, so even if we had EE fuses, we might not want to enable that funcionality for secureboot-related things. Especially given that for most mass production development, reflowing a new ESP32 in place of a bricked one is a cheap and trivial matter.

Maybe a second CAN controller, support for MIPI DSI displays, and please keep the RMT peripheral, I just love it, it is very useful.

Maybe a second CAN controller, support for MIPI DSI displays, and please keep the RMT peripheral, I just love it, it is very useful.

A second CAN controller would be amazing!!!!

Hi,

Reinforcing my suggestion:

* independent bus communication with psram and flash memory with dual sqi controller and with dual cache controller.
Each cache controller with independent memory regions for speed up and for large data transfers.
Dma access on sqi psram and dma access on sqi flash memory(independent dma channels).
Support for sdr(single data rate) and for ddr(double data rate) sqi memory. DDR for speed up.
Psram DDR and Dma for displays buffers for example(high speed refreshing of display and memory update).
So on boot i can load a critical part of flash into psram memory.
With independent cache controller and independent cache memory regions for external flash and psram memory i think there will
be no stall on reading/writing psram or reading flash memory.

* +1 proper documentation(hardware documentation is poor, more software/hardware examples).
* configurable parallel port(with data/command, chip select, reset, write/read, all configurable ) in isolation from the i2s module.
* mipi dsi.
* graphical controller(with tearing support).
* independent communication with psram and flash memory(dual sqi controller maybe, more package pin 64 pins maybe), so on boot i can load a critical part of flash into psram memory without reading psram/flash stall.
* 64 pin package.
* more internal static ram/cache.
* powerfull fpu/dsp instructions.
* FreeRtos support for static allocation memory.

...

FYI, the ESP32S2 already has a fair few features you're mentioning: you can connect a flash and PSRAM chip to different SPI channels and map them both in memory simultaneously, support for DDR octal PSRAM, support for executing code in PSRAM. We also have 8-bit 'spi' which may or may not count as your configurable parallel port (if any, it's flexible enough).