What would you like to see in The Next Chip?

[jeremy]

I haven't read through this entire thread, but if there is one thing I could vote for, it would be adjusting the architecture so that the task stacks could be in PSRAM (and adding the 8MB PSRAM to the address space would be even better!). When I have BT, WiFi, mbedtls, MQTT, HTTPS, etc all running simultaneously on the WROVER, even when they are all set to allocate in PSRAM, I spend a lot of time struggling to manage BT/wifi stack out of memory conditions (and I assume memory fragmentation), and yet I have 4MB of heap free, presumably all in the PSRAM. Most of the internal DRAM is used up by the task stacks, and the rest is seemingly taken by BT/WIFI for their various buffers. I'd gladly give up memory performance to be able to utilise the full PSRAM space, saving the internal DRAM for only things that are critically dependent on fast memory (like DMA, interrupt routines, etc).

It would also be neat to see some sort of virtual memory and paging mechanism for the PSRAM.

[ESP_Sprite]

At the moment, the task stack not being allowed in PSRAM has to do with 1. the workaround the ESP32 needs, which is not baked into the ROM; the ROM may thus cause weird issues when working in stack in PSRAM, and 2. stack in PSRAM means the stack will 'disappear' when the CPU has to write to flash or otherwise disable cache, leading to weirdness. The new chip will at least have 1 fixed (as we won't need the workaround anymore) and I'm pretty sure we can find something around 2.

(Note it's actually possible to get stack in PSRAM with the current ESP32 and ESP-IDF as well, given you turn on the feature for it in menuconfig and allocate the task stack manually. If you do so, it's on you to make sure the stack memory never ever ever is used in a ROM function or when cache is disabled. Use at your own risk, cave hacker, etc.)

[tuupola]

Only thing I am personally missing at the moment is more I2C controllers. I have a hobby project which requires to be able to act as four I2C slave devices.

[ESP_Sprite]

...four slave devices? Can I ask what your use case is? I think there aren't a lot of projects that even need two slave devices.

[danielrp]

Hi,
It would be fantastic having a really cheap general purpose version of the ESP32, that includes the flash memory, don't have the radios, but has all the rest of processing power and peripherals: touch sensors, I2Cs, SPIs, UARTS, MCPWM, etc etc, and maybe a better low power approach. If this "new microcontroller" is fully compatible with the ESP-IDF and the whole framework, a company that already invested time in learning the ESP32 framework could start using these microcontrollers for all the products.
Cheers.

[mikemoy]

It would be fantastic having a really cheap general purpose version of the ESP32

The ESP32 IC can be picked up for $2.20 in single piece QTY. How much cheaper are you looking to go?

[danielrp]

I don't know, maybe $0.5 - $1.

[Deouss]

I recently saw small nice Risc-V boards being sold and they look very competitive to esp.
I think it is Sipeed modules. So next chip will have to be definitely more competitive than that.
We should have 64bit CPU 2+core, 8+MB sram, FPIOA, APU, DVP, KPU, FFT and higher clock 400Mhz+

[KanyeKanye]

1. More output pins! I miss 10 or more pins. JTAG and SDCard would be helpful.
2. Dedicated pin for RTC holdup: In my current products I use external RTC chip with 1.5F goldcap and read its time via uart using wroom module. Currently, for wroom module, adding external holdup power is impossible (power pins are shorted). For chip itself very problematic.
3. Float (floating point variables) in ISR (eg. for timer)
4. More pins again

[guillep2k]

I'd like to have support for UART in light-sleep mode, meaning: a not-so-small receive buffer (e.g. 64 bytes?) and the ability of waking up the cores after receiving some "complete" packet (either by size, character match, character timeout, etc.). A decent send buffer that works in light-sleep would complete the picture. The UART itself should remain fully functional during light-sleep, of course. This would work beautifully with GSM/LTE+GPS solutions, where the main processor often times has nothing to do while it's waiting for some data. I bet there are countless other scenarios for this.

Thanks for taking the time to hear out the community. I think this is mostly unheard of in the industry and you guys are doing an excellent work!