What would you like to see in The Next Chip?

[PeterR]

Yea, native CAN-FD. SPI CAN-FD would suck at the higher bit rates on an ESP32. You'd need lower SPI latency & higher bps I think.

Whilst on CAN (& regarding my last post responding to ESP_Sprite's comment) - what CAN track record do ESP have? What internal CAN 'certifiable' & reliable internal controllers have ESP created to date?
I know only about the ESP32 which until quite recently would 'lock fail' on the simplest of use cases (overflow).

So a little uncertain as to where we stand on CAN within existing product lines & whilst blue sky is cool - what about the ppl actually buying chips (us fools)?

[M@rcel]

At least two can controllers would be great. Can-FD would be greater. More than two Can-FD would be greatest.

[ESP_Sprite]

Some responses:

Wrt DMA to/from PSRAM: I think the ESP32S2 already has this; if not, future chips will as we certainly have this.

More pins on the ESP32: we are adding a few more, take a look at the ESP32S2 for instance; it has a few more GPIO pins than the ESP32. There's only a certain limit of package you can go up to before it starts affecting the RF performance, though.

RiscV cores - we technically already have one as one of the ULPs in the ESP32S2 is a RiscV core. Obviously, we're not a RiscV-foundation member for just an ULP, and while I can't comment on exactly what's going to be on the roadmap, but be sure to expect some developments there in the future.

'Sleepy UART' - one of the things we have in mind for some future chips is to add a few more peripherals to the ULP, which will get a bit more powerful in general. That may be a good workaround for your use case - you can even have the ULP see if what's received is worth waking the main CPU for.

Wrt CAN: We are in the process of getting certification for our newer chips that we're compatible with the ISO standard. Not calling our device CAN indeed has something to do with trademarks. I think by now all the places where existing chips diverge from the ISO are in the ECO guide or the TRM/datasheet. Wrt running the TWAI bus faster than 125K: the hardware has not been tested for those speeds, but given that the IP we use is intended to run at the max 'normal' speeds for a much, much slower process node, I think it'll easily run at whatever speed you throw at it. (Wouldn't be surprised if setting all divisors to 1 or 2 will just work.)

Wrt multiple CAN buses and CAN-FD: We heard you on the 'multiple CAN buses' front, I don't have any specsheets in front of me but I'm pretty sure we're going to have some chips with multiple CAN peripherals. We're not planning on supporting CAN-FD at this moment.

[dmaxben]

Wrt multiple CAN buses and CAN-FD: We heard you on the 'multiple CAN buses' front, I don't have any specsheets in front of me but I'm pretty sure we're going to have some chips with multiple CAN peripherals. We're not planning on supporting CAN-FD at this moment.

This is great news that future chips will have multiple CAN/TWAI peripherals! Excellent!

Is there a chance that we might see new chips before the end of the year?

I am trying to decide if I should have another production run made of my product, or if I should wait a couple months for the new ESP chips with multiple CAN/TWAI peripherals...

[ESP_Sprite]

Is there a chance that we might see new chips before the end of the year?

I am trying to decide if I should have another production run made of my product, or if I should wait a couple months for the new ESP chips with multiple CAN/TWAI peripherals...

I can't comment too much on our roadmap, but personally I'd do another production run with the ESP32... Not all the chips we have in the queue are going to have multiple TWAI interfaces or may be compatible with your use case, and in general it takes a while between first release of a chip and general availability.

[PeterR]

Would be interested in who buys ESP32, what volumes & then what do you want (& why)?

IMHO: Another ESP32 bug fixed, more IRAM, better DMA.
Suspect that dual CAN (oops TWAI) and especially CAN-FD will suck without better DMA e.g. circular/dual buffer & triggers.
I'd also focus on the stack and/or IRAM. The stack sucks on IRAM. Most IP stuff could be done cooperative. 'switch: which part of the request am I serialising...'. Don't really see where the user app would block there; ok stupid slow device reads but just read smaller chunks! Most embedded IP stuff I have done was cooperative & unless ESP add another 256KB IRAM then the threaded approach seems daft. PS and especially as the better performance stuff like web sockets etc end up being frame buffered client side (or ignore partial frames and so risk protocol errors) & so we end up blocking! Bring back pbuffs!
The Wifi & BT stuff is especially hard to do once you have a serious application & so more IRAM, lower stack use or maybe better DMA is what I would ask. A couple more pins would help me as then I could quad SPI RAM.
IMHO the ESP32 is perfectly 'good' (erata & lack of official fixes excluded) except for; IRAM, software stack (RAM use & latency) & bus latency issues (software stack again).
More I think then the more I say software stack.

[ESP_igrr]

@PeterR, regarding IRAM, ESP32-S2 and the following chips don't have a hard limit on the IRAM size, like ESP32 had. It is okay to use more IRAM, if necessary, this will simply reduce the size of DRAM available; and vice versa, freeing up some IRAM directly increases amount of heap.
Also on ESP32-S2 and the following chips there is less need to place code into IRAM. On the ESP32, this is mostly needed to allow interrupt handlers to run while any flash operation is in progress. On the ESP32-S2, the hardware is capable of suspending flash operations (program/erase) automatically, if the cache needs to be refilled from Flash. This means that the interrupt handlers can be safely placed into Flash. Support for this hardware feature is planned in IDF v4.3.

Regarding cooperative run-to-completion versus preemptive multithreaded scheduling — there are a few reasons why cooperative scheduling is not the preferred option for us at the moment. The main one is related to integration of third party libraries. Some of the libraries are built on top of BSD sockets, which are not feasible with a run-to-completion (task) scheduler. Other libraries, especially cryptographic and filesystem libraries, may perform very long running operations. For example, an RSA private key operation (even with hardware acceleration) may take a few hundred milliseconds. Filesystem formatting may take several seconds, for a megabyte-sized partition in the internal Flash. Some third party libraries can be hacked up and adapted to do work in smaller chunks, making them cooperative scheduler -friendly, but generally this means more maintenance work to keep up with upstream versions, re-applying these modifications whenever a new version of the library comes out. Multithreading requires more resources (mainly DRAM for stacks, plus task switching overhead), but the alternative would be either additional maintenance work to port and update 3rd party libraries, or fewer libraries and features (cryptography, network protocols, filesystems) available to the developers.

[PeterR]

@PeterR, regarding IRAM, ESP32-S2 and the following chips don't have a hard limit on the IRAM size, like ESP32 had. It is okay to use more IRAM, if necessary, this will simply reduce the size of DRAM available; and vice versa, freeing up some IRAM directly increases amount of heap.

Is (what was) IRAM now 8bit? If so cool, that's an 90K improvement i.e. (my unused) IRAM into DATA. (BTW I meant DRAM - the software stack issue I am describing is about running out of general purpose 8 bit DRAM).

On the ESP32-S2, the hardware is capable of suspending flash operations (program/erase) automatically

That's nice. My animations will no longer stutter on configuration save! In my use/case its a minor (I'm tech not marketing!) but guess many (marketing)will love.

This means that the interrupt handlers can be safely placed into Flash.

Which might help the amount IRAM (guess now general DRAM?) available at the expense of performance. I think IDF 4.1+ had pretty much removed much of the excess IRAM storage and/or allowed user to configure though.

Some of the libraries are built on top of BSD sockets, which are not feasible with a run-to-completion (task) scheduler.

Bring back pbufs!
I understand that use of BSD allows access to a lot of code but it does kick the bucket into developer space on the ESP32 (RAM).
Assuming 8bit on all DRAM and ability to shift from DATA/IRAM etc on the new ESPs then that will go a long long way to improve your offer.

Also be nice to understand your bus/bandwidth improvements - e.g. how DRAM/PSRAM/SPI FLASH/Peripherals access might share a bus and so block each on the various chips (seen some I2C stretched clock issues etc which I guess are ISR or bus contention based). As well as DMA; ESP32 DMA seems lacking IMHO (no dual/circular triggers etc).

[markevens]

Some feedback; I'm not promising anything but just to set expectations:
- USB - I can't promise anything, but as long as you don't expect USB3, we'll likely have something for you.
- More ram: That's kinda hard... the largest part of the chip already is RAM, and making more of it RAM decreases yields and increases cost by a fair amount...
- 5GHz - I don't think it's a secret we're working on that.
- 'Real' deep sleep: Well, the hardware on the ESP32 already supports keeping RAM powered in deep sleep, but there's a physical limit you'll always run into, and that is that keeping RAM powered eats into the power budget by a lot. Maybe later on we can make some kind of 'hibernate' mode that saves the entire state of the CPU to flash, for true zero-power deep sleep and instant state restore... Anyway, what I'm saying is don't expect new silicon to change the status quo here; if we implement something like this, it's probably also going to support the ESP32; the issues are mostly in software.
- RTC 'identical' to DS3231: What functionality are you missing at the moment?
- 900MHz: We're keeping an eye on the developments there.

RTC with external battery backup like DS3232 so time keep after restart or shutdown is possible

[Scott.Bonomi]

I would like to see the real time clock able to survive losing VDD but keeping vdd_rtc. This would allow knowing the time when primary power was restored. I do not expect that the internal oscillator would be keeping perfect time, but it would provide some idea of the amount of down time for logging purposes. For a mesh radio agricultural sensor, knowing if you have been off line for one day or several due to no sun on the solar panel could be important.