What would you like to see in The Next Chip?

[PeterR]

You're digital guys talk?
More DMA RAM. Enougth to comfortably run a reasonably sized/colour depth dual buffered display whilst running Wifi n BTE.
Add USB and I'll give you my phone number & a photo.
320*240 8 bits is 74K & so 158K dual. Not a lot left over when Wifi & BLE. Actually 74K is all pretty much all I have left in my modest application before I wifi.

[PeterR]

Hi, late to the party & just wanted to check:

CAN is a bit of a... thing. I won't say we have a CAN controller in our chip (because of ...reasons),

I assume ESP32 CAN is 'not a thing' and is real n supported (despite the refusal of the IDF to deal with overrun errors)?

BTW: My vote is more DMA RAM, enougth to run dual buffered resonable display (320x240, 8 bit colour) with Wifi n BTE. 74*2K is 'not possible' on ESP32 (k, cannot prove a negative).

[ESP_Sprite]

S2 has USB host and device support; no need for phone numbers or photo's For more RAM, you could try one of our modules with PSRAM... while you can't DMA straight from PSRAM (on the ESP32, not sure if the ESP32-S2 allows it) it may free up some more memory to stick a framebuffer in.

[bkgoodman]

Power control support, specifically:

LiPo battery management
Charger Management

Specifically for +5v/USB charger and Solar charged-LiPo applications

[kbaud1]

The ESP target low cost embedded systems. IOT. They don't need to run Linux and do everything. That would make them too expensive. The bones of the ESP32 are pretty solid. I suggest focusing on the software and only make small changes to the hardware.

- boot from network (flash chip optional. ssid/password in existing or expanded efuse, default path/app store (Andreas Spiess) send to mac/custom path for image, get rid of BASIC in ROM to make room for network boot). The average building has dozens of IOT devices, must they all have 4mb of flash? Make the flash pins dual use for more GPI/GPIO. I think the ESP designers were already moving in this direction when they chose to move the flash to an external chip and put a large ROM on the ESP32.
- get rid of hall effect sensor, dac and ADC (or replace with ADC block from the S2)
- pick 3-4 hardware bugs (say one each from comms, security, power, etc.) and fix them in the next rev. This is a very complex chip and errata for this type is going to be particularly high. ESP did a pretty good job considering the challenge they undertook.
- add at least one low power change everyone wants in hardware to increase life on batteries?
- I know this is unpopular but onboard USB was a mistake. Too many chips do USB. Not many do Wi-Fi well. That is your strength. embrace wireless even more. dev-kit-c should have usb for power only, use wi-fi for programming/debug. Allow OTA/push/control in more modes such as sleep, program running on other CPU, listen on reset for 1 minute only, etc. Eclipse plugin that uses network.
- OTA AP/simpleconfig (at least)/network boot/app store push to mac capability from the factory image so devices can be manufactured in sealed products and then wirelessly programmed. factory image could also listen for special SSID. broadcast programming for parts that fit a filter for high volume production. At the very minimum, default factory image should have the ability to wirelessly program the device so a physical programming connection goes the way of the dodo bird. This is a wireless device.
I realize OTA can take a lot of space. Wouldn't fit on the current ROM. May need a larger ROM or we are stuck with the flash. Using a standard SSID as a "master" (ESP_xxx) would save space since the STA mode can be used (takes less space than AP mode). Another ESP, altered router or a smart phone could be the master.
- Improve Wi-Fi. incremental improvements to CSI. Chirp ToF, Doppler motion detect, 2.4ghz LoRaWan (3-4Km). WSPR (LOS horizon). A lot of this is in the firmware but the hardware may need a few more knobs
- Wi-Fi CSI fingerprints efficiently compared to training data using DMA with some minimal fitting, scaling, grading. the driver would output score for customer-trained movements (people, vehicles), etc. PIR alternative.
- Receive-only mode for 2.4ghz. magicpacket wake. Wake on energy threshold (deeper sleep, allow clock drift). Oscillator calibrate from APs
- onboard oscillators(s) for crystal-optional operation. If everything is connected, why do dozens of IOT in a house all need their own crystal? use common 2.4ghz APs (and temperature sensor?) to periodically compensate for drift. eat/drink/sleep wireless
- 1/2 size, lower cost module without crystal or flash chip. keep the previous module design as well.
- speed up the I2S peripheral? might even be able to do more video types. add resistor network/LNA/AGC for 16bit ADC/DAC? Minimal extra components (oversampling would require less analog stuff for a given fidelity than the 2.4ghz section) to complete a DC-30mhz SDR that hits several license free ISM bands? multiple WWV. CB. WSPR Mesh around the world. out of the box see a list of radio bbs. see Pi WSPR.
- op amp? for differential input to ADC (load cells, current sense, PIR, motor FOC, etc.)
- GPIO banking? Syncs a bank of the existing pads so they can optionally switch in unison for more current. (current pads are 40mA, adds up quick). external FET gate drive, power LEDs, RF, Amplified Audio, small motors
- improve PWM for smoother class-d, over sampling/dithering (amplified audio output using banks, cleaner RF)
- use opposite side of each port's h-bridge as additional free-wheeling diode (gate connected to drain by small switch) to additionally protect active switch from inductive loads.
- one of the capacitive sense pins uses the existing pre-amp to sense across a optional external current sense resistor on the VDD_SDIO feed. this allows the chip to regulate loads, circuit break (protect ports/banks), PWM LEDs without resistors, BMS (with GPIO banking), etc.
- looking at the multiple power domains on the esp32, I think the designers where moving towards something that worked with the typical options for powering an IOT device with less external components. Continue this trend so that the external 3.3v LDO is not needed as often with the typical primary/secondary battery, solar, usb that IOT typically use. ULP wake from/operational down to 1.1v(see ds). expand internal low current LDO up to 6v (unless it is just impractical). Use GPIO banks with external inductor, cap for more power (transmitter) once the device wakes. external LC costs less, more efficient, same size as/than an ext LDO. underclocking.
- devkit-gee. USB-C for pd only. 2.4ghz pcb. 30mhz loop ant pads. discretes for both rf. no crystal. no flash. cheap inductor/cap for usb/batt buck/boost. boot to network (smart phone/router/url/master device). radio bbs out of the box. mesh that solves the chicken and the egg problem. current sense resistor on sdio. Jumpers to select more gpio or bms in software and pads for LiPo. pads on back for optional flash, ~0.91" serial OLED with capacitive touch zones.
- optional setup ESP32 as an IOT master. server for thin client IOT (network boot). automatically add new devices to wifi. This or implement same function in DD-WRT router firmware. devices can still do a lot without these servers. just use a smart phone or pc with dongle to scan for factory AP, connect, configure, disconnect. now it connects to home SSID on reset and gets firmware from NAS/internet Appstore/router/etc.
- die size is similar (get rid of some blocks, focus on wireless IOT, only add a few things to refine popular functions). most new functions are in software. cost would be about the same because of the huge IP required. modules would cost less, be smaller because parts eliminated. devkit would be a wash. loses the usb to serial junk but picks up more IOT/wireless stuff.
- 2.4ghz PCB isolated comms. Similar effect to an opto isolator. Thousands of volts of isolation between controller and other parts of the circuit. Small switch bleeds RF (before/after?) existing PA to one of the GPIOs. Similar to an antenna switcher. Allows a low power, very short-range mode (can rapidly switch back and forth between this and conventional antenna/power level). Runs RF section at much low power levels (bypass PA or throttle?) so it doesn’t interfere with other parts of circuit (or melt the GPIO port it is using). Example: 4-layer board. Inner layer of traces near (but not touching) each other to talk to other section. Use outer layers to shield inner layers. This mode does not require external shield or module. GPIO pin used would sink directly into the board and RF couple with a nearby chip. Faster than conventional optical isolators. A example system might use a shielded module for central control/wifi with pcb-isolated comms to 2 other esp chips without external shields that each control a bank of FETs, replace ext op-amps for FOC. This would cut the cost of a similar control system in half.

[NiclasH]

Long thread, and can't say I have read every suggestion, but mine are about fixing the "broken" parts in ESP32, before adding "more stuff" (possibly with the exception of more usable GPIOs on the physical chip)

* Interrupt latency is quite poor. I don't understand why, but if 8bit microcontrollers can do that in very few clocks (8031 only pushes return address, status and interrupt regs), then why is ESP32 so slow? Is it related to being compatible with C ISR functions, then we (the community) should look at how that can be fixed? But if it is in silicon, then I urge Espressif to look into it.

* I2S in the Technical Reference Manual mentions that the FIFO buffer can written to and read from via registers. But the ESP-IDF has not mapped that out, and I can't get that direct access to work, so I suspect it is not done in esp-idf because the silicon has a bug. Should be fixed.

* Predictability. In recent project, I was able to lock down the start up really hard, so that I could sync the SPI and a MCPWM timer to within one clock, repeatable on every RESET. BUT, adding some code elsewhere, code that is not even executing yet, threw the carefully adjust sync values off by 100s of clocks, for no apparent reason. Only got a vague "Internal architecture problem" answer, and gave up.

* SPI CS handling in DMA mode, so that continuous DMA (never ends) can also send CS low for N cycles. Useful for ADC/DAC streaming (audio, video, oscilloscopes, etc) where the external chip requires a sync clock, latch pulse, start pulse etc

* A small FIFO on SPI that is directly accessible and not requiring DMA or slow setup to let CPU pump out (and read in) word-by-word.

* Route (pre-scaled) clock(s) to GPIO pin, and not use MCPWM or LED periph.


For more exotic "next generation" chip and "keep dreaming" list;
* Should be called ESP42, because 42 is meaning of life.

* I would like to see 4 user SPI ports. Interesting use-case; neural networks, with thousands of connected ESP32 in a symmetric mesh. Idea introduced by the Transputer in the 1980s, but way too costly ($400 just for the CPU) for most application areas back then.

* On-chip LoRa-compatible radio, and esp-idf support for LoRa and LoRaWAN. I only care about the 868/915MHz bands

* RISC-V is possibly a better choice in the long-run, and probably easier for users to dig into than the Tensilica cores assembler, which is really hard to get enough information about.

* Many others mentions ADC accuracy and both ADC and DAC precision/speed., and I agree.

* And of course; a SoC/PICO version... Love the PICO!

[PeterR]

A fault tolerant CAN implementation. Maybe even option for a couple of channels but mainly fault tolerant & functional.

[zhjerry]

A ESP32 module with onboard Ethernet PHY chip.
Without the 9 RMII lines internally connected there will be 10+ lines left only to be routed outside to make the end-users' RJ45 application much easier!

[Baldhead]

I agree with NiclasH.

* On-chip LoRa-compatible radio, and esp-idf support for LoRa and LoRaWAN. I only care about the 868/915MHz bands

[username]

A ESP32 module with onboard Ethernet PHY chip.
Without the 9 RMII lines internally connected there will be 10+ lines left only to be routed outside to make the end-users' RJ45 application much easier!

Na, that will increase the cost for all who dont even use Ethernet. Adding a PHY chip is ultra simple and easy to do.