What would you like to see in The Next Chip?

[aaronw]

The main things I would like to see are:
1. More on-chip RAM
2. Native USB2 support (so I don't need a USB to UART chip).
3. More GPIO pins.
4. Faster processing, especially acceleration for FFT. Maybe move to Xtensa LX7.
5. Better GPIO support for NeoPixels with DMA support (rather than use the IR engine).
6. More stuff in ROM (i.e. drivers, FAT, .
7. Possibly move to ARM core (Cortex-M7 would be nice)
8. Keep the dual core support, which is great for real-time while processing on the second core.

[Baldhead]

...

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).

Nice to know, thank's.

But why single core and not dual core ?
Why decrease static ram to 320KB instead of increasing ?
Why not increase the processor clock ?
See kendryte k210 specs, for example.


I think that adding 2 SQI DDR(internal/external bus) channels would be enough to save pins, but DDR octal PSRAM is nice too.
Suggestion:
* 1 channel SQI DDR for external psram memory with independent cache memory, independent cache controller, independent dma controller and maybe independent internal processor bus.
* 1 channel SQI DDR for external flash memory with independent cache memory, independent cache controller, independent dma controller and maybe independent internal processor bus.

The parallel port(in my case only 8 bits) it would be for communication with the display.
The i2s parallel module are very complicated to configure( many functions in one sigle module ).
If the espressif support didn't help me, i wouldn't be able to make it to work(some bugs in hardware too), and it still took me months.

I forgot to comment that esp32 does not have 8-bit transfer or 16-bit transfer ou 24-bit transfer in the i2s dma.
It only has 32-bit transfer, which, in my case, uses a lot of internal ram and also a lot of processing time and power ( copying from a 16 bits ram buffer to a 32-bits ram buffer) and i need to break 16 bits number into two 8 bits number and save each 8 bits number in a single 32 bits position ( 75% wasted memory ).

Dma linked list with only 12 bits for store the number of bytes to be transfered/received are very little.
I know that i can calculate n nodes in linked list but this are wasted processing power and time, and the developer(me), need time to develop this logic as efficiently as possible.
Why not using only one "big" node ?
Add a new single 32 bit field to dma structure(DW3) for example, and change the number of transfered/received bytes to 32 bits or 24 bits.


And please,
I am not a expert, but i will suggest the following, i dont know if it is possible.

DMA tranfers sizes:

Word size in bits: 8, 16, 24, 32, 64.
"viewtopic.php?f=13&t=12905&start=30"


Thank's.

[ESP_Sprite]

But why single core and not dual core ?
Why decrease static ram to 320KB instead of increasing ?
Why not increase the processor clock ?
See kendryte k210 specs, for example.

Because we're trying to build chips for which there is a market demand, and that doesn't always mean bigger, faster & better in all aspects. The ESP32-S2 is placed in the market as a cost-efficient chip; you can already see it's cheaper than the ESP32. We will be developing higher-range chips as well, and the upgrades in peripheral set will be included in those as well. (And the plan is to have those upgraded chips on the market pretty fast as well; we're not keen on taking anywhere near as long as the time between the ESP32 and ESP32-S2 anymore)

[jcsbanks]

Is it possible to say whether CAN bus is intended to be included in future chips? If CAN has been removed from plans for future designs that would be really helpful to know too.

[ESP_Sprite]

CAN is a bit of a... thing. I won't say we have a CAN controller in our chip (because of ...reasons), but I can say that the ESP32-S2 has a peripheral we call the 'TWAI (Two Wire Automotive Interface) controller'; which happens to be fully compatible with the peripheral you used to use for that on the ESP32. (If it's still not clear, TWAI in chips after the ESP32-S2 should be an 100% compatible ISO 11898-3 protocol implementation; TWAI in the -S2 is 99.8% compatible.) The TWAI interface will likely also appear in selected future chips, and we don't rule out that we may decide to put more than one in a chip.

[dmaxben]

CAN is a bit of a... thing. I won't say we have a CAN controller in our chip (because of ...reasons), but I can say that the ESP32-S2 has a peripheral we call the 'TWAI (Two Wire Automotive Interface) controller'; which happens to be fully compatible with the peripheral you used to use for that on the ESP32. (If it's still not clear, TWAI in chips after the ESP32-S2 should be an 100% compatible ISO 11898-3 protocol implementation; TWAI in the -S2 is 99.8% compatible.) The TWAI interface will likely also appear in selected future chips, and we don't rule out that we may decide to put more than one in a chip.

This is excellent news!! My application requires "TWAI" and its great to know that I wont need to revert to an old MCP2515 on future Espressif chips.

Also amazing that future chips could have more than one "TWAI" controller. Multiple TWAI-controllers would be extremely useful.

[jcsbanks]

CAN is a bit of a... thing. I won't say we have a CAN controller in our chip (because of ...reasons), but I can say that the ESP32-S2 has a peripheral we call the 'TWAI (Two Wire Automotive Interface) controller'; which happens to be fully compatible with the peripheral you used to use for that on the ESP32. (If it's still not clear, TWAI in chips after the ESP32-S2 should be an 100% compatible ISO 11898-3 protocol implementation; TWAI in the -S2 is 99.8% compatible.) The TWAI interface will likely also appear in selected future chips, and we don't rule out that we may decide to put more than one in a chip.

Awesome!!!

[Captain.Chode]

CAN is a bit of a... thing. I won't say we have a CAN controller in our chip (because of ...reasons), but I can say that the ESP32-S2 has a peripheral we call the 'TWAI (Two Wire Automotive Interface) controller'; which happens to be fully compatible with the peripheral you used to use for that on the ESP32. (If it's still not clear, TWAI in chips after the ESP32-S2 should be an 100% compatible ISO 11898-3 protocol implementation; TWAI in the -S2 is 99.8% compatible.) The TWAI interface will likely also appear in selected future chips, and we don't rule out that we may decide to put more than one in a chip.

This is awesome news. What if with the more generic name "TWAI" a more generic functionality would come? I mean there are some more automotive buses which would be also great to be supported. There are some obsolete ones which are simpler than CAN. For example I have a VAN bus reader implementation with the help of the RMT peripheral. Writing with it is also possible however more problematic because of the bus arbitration. Could it be possibble to have a generic solution for that (protocols with arbitration) as well?

[ESP_Sprite]

We have some things in the works for situations where you need to respond quickly to GPIO inputs, yes. We'll phase them in incrementally, if I recall correctly the -S2 already has some way to twiddle GPIOs at nearly the CPU clock speed, but I don't think we have software or TRM support for that yet.

[StefanRvO]

I would like the following functionallity in a new chip.
* USB host controller so the ESP could basically present itself as a mass-storage device. Would be useful to transfer files to an internal filesystem. I guess this is planed as the S2 has usb support as far as i know.
* Better support for ws2812-like LED devices instead of relying on the RMT functionality.
* More built-in RAM, e.g. 1MB.
* An ESP32-PICO-D4 form-factor chip, but with more built-in flash, e.g. 8MB. Don't know if this is even possible due to size constraints.

Of course it would be nice with faster cores, but at least for what I'm doing, I'm more constrained by available memory than the core speed, so i would personally prefer more built-in memory than a faster chip.