What would you like to see in The Next Chip?

[nicolas]

Sprite, my interest in ESP chips is mostly for "hackish" DIY tinkering purposes, and I know you are very well placed to understand this niche crowd, but to know as well that even real products developpers could meet them on some features that look dispensable at first (like repurposing I2S as a generic ultra high speed parallel bus... and why don't have such features if they can easily fit in the design).

When I've first read the ESP32 datasheet, I could'nt repress some (poor hacker's) existensial thoughts, like "where is my third DAC for Blue, so I don't need an additonal triple DAC video for anolog RGB ?", I'm sure you can understand that too... And I'd need another one for sound, obviously.

Still, and I haven't really dig into the present implementation, there are probably more serious application that could benefit from synchronous DACs, with selectable bits. To be clear, I'd like to be able to route any parallel I2S channel to any available DAC, and to any DAC bit (while configuring unused static bits), because I don't want to be forced to reserve 8 I2S channels when I only need to drive 4 bits of the DAC.

With this "any I2S" <-> "any bit of any DAC" matrix, I could do things like driving 4 x 6bit DACs (which are the 4 onboard 8-bit DACs partially used) from the 24 channel I2S, or any other combination like the configurable routes (is it still possible like for the GPIO... again, I don't exactly know what is already possible regarding the I2S outputs now, sorry).
This kind of configurable matrix with 4 independant DACs with selectable/adressable bits (and ideally independtly adressable from any I2S interface) could be something simple and unified enough to implement, but a versatile and very modular solution for many fast/multi-output analog designs (ones you can think of better than me... )

[enitalp]

A complete SDK, like with BTC, WIFI Direct ;p
A real dev environnement with debugger fully integrated in visual studio and visual studio code.
A SDK fully in c++ no more C functions.

[JimmyPedersen]

* Better debugging functionality with more hardware breakpoints (For RAM as well as Flash(cache)).
It would be great if some of these https://sysprogs.com/w/limitations-of-t ... debugging/ limitations could be fixed, either in OpenOCD or in hardware if required.

* A way to use the bluetooth (LE) without using as much current

[permal]

Yes, a better debugging experience is a must to compete with similar devices. (I've still not managed to debug my ESP32 due to those dreaded DIR-errors)

[charma]

Just a few more GPIOs would really make a difference, even 6 to 8 more if the package size can't be increased by much.

Have a way to start synchronized RMT transfers on multiple channels at once.

Fixing the hardware bug (or is it intentional?) where cs_ena_pretrans doesn't work for non-half-duplex SPI transfers. It feels like something the ESP32 should be able to do, especially as you can control the rising edge of CS easily using cs_ena_posttrans. Just need control of that falling edge too.

Personally I'd like to see an external memory interface. It could be slow (multiplexed bus with external transparent latches) like the PIC has, but that would be an easy way to attach memory and memory-mapped devices where speed isn't critical but you don't want to go through many GPIO expanders to mimic a parallel bus.

[rudi ;-)]

cause espressif celebrate 10th anniversary in 2018,
i think we can push some gags in a limited 10 Year special "stamp" package, perhabs as "SIP package"

- No black package but a clear (transparent) package (want to see what is in it like the neopixel with bonds and so on )
- an eMbedded LED ( neopixel ) for Blinky, system warning, boot state, debug controll (( breakpoint, step )), Uart flashing controll......

see it as a challenge, on my thinking - there is no such thing yet.

best wishes
rudi

( or likewise an EPROM window - but it will be "cool" if the package (minimum on TOP) is clearly transparent )

window.jpg (28.41 KiB) Viewed 41297 times

simple test looks promissed

transparent-epoxy-package-for-THE-NEXT-CHIP.png (183.07 KiB) Viewed 41295 times

and now we think to a neopixel for blink in The Next Chip

"cool"

we can select the color for the state of chip
or can use it for the temperature sensor inside
or low battery state
and so on -

just a suggestion what I would want to see in The Next Chip

[mnemonix]

...
- More than 2 cores: Not saying we won't do that, but just curious: can I ask if you have specific use cases you're able to do with more cores that you can't do with two?
....
- Fast lo-res ADC: Can I ask what use case you have in mind for this?

I think of several small cores tied to GPIOs for fast bitbangig peripherals. They need just a little local memory and a way to interface to the Main-cores (shared RAM or some bus). It's the same idea as with CPLD cells on chip - software defined peripherals Only that small independent cores are easier to program than logic cells (see Parallax Propeller or XMOS for example).
Such cores allow to execute Tasks fully deterministic and at highest speed, but are otherwise similar to scheduled RTOS tasks.

A fast ADC with about 8 bits (more is always better) can be used for: SDR, Digitizing of analog video (VGA/Composite) or for Oscilloscopes for example. It would be quite unique for a lowcost microcontroller.

[ESP_Sprite]

Nicolas: As much as my hacker spirit wants to have as many things to play with as possible (and I'll see if I can get e.g. multiple parallel DACS into the thing), stuff does still have to make sense from a cost perspective. Five DACS will be absolutely awesome for that old-school VGA board you have in mind, but if all the use cases for something only nets us a few more sales but a lot more work to implement and/or a much larger chip, it's not likely. I'll add it to the list, but I'm just saying that this may not make the cut.

SDK stuff: That is a separate thing. If any, we'll be keeping ESP-IDF; if something happens with an integrated SDK or a C++ SDK or whatever, it will be on top of ESP-IDF, also compatible with the ESP32, and the release time not connected to the new chip in any way.

Debugging functionality: check. BTLE with low power: we have some things coming up; if any, we want to get light sleep working on the ESP32 in one of the upcoming releases of ESP-IDF, which will take power consumption on the ESP32 down by a fair bit.

Synchronized RMT starts: Agree this will be awesome; I actually wanted to have that in the ESP32 but seemingly the guy who designed the RMT didn't get around to implementing it. The RMT is somewhat funky with sharing of memory, so I don't think an absolute synchronous start can be archieved unless we rework the hardware by a fair amount, but perhaps a workaround for that can be implemented.

SPI dev: Yes, there are a few things that sound like they should work in all modes but don't in the current implementation. We'll see what we can fix.

Fast ADC: I'll keep it in mind. I actually think the current ADC can actually be pretty fast if you turn down the amount of bits, but I haven't played around too much with it yet. Will give it some thought.

Multiple simple cores: Yes, I've thought of that. As a hacker, I really like the idea of this; however, as a programmer, separate AMP processors are a pain in the proverbial ass... We have some ideas here, perhaps we'll be able to combine a few things so you can also do this.

[permal]

SDK stuff: That is a separate thing. If any, we'll be keeping ESP-IDF; if something happens with an integrated SDK or a C++ SDK or whatever, it will be on top of ESP-IDF, also compatible with the ESP32, and the release time not connected to the new chip in any way.

That's fair. IDF as a backend to C++ works splendidly, I'm already doing it

Debugging functionality: check.

Can't stress the importance of that that enough times!

Although this extreme put-any-function-on-any-pin feature is awesome and I see the need, it also makes the device appear much more complex. I don't have any immediate better solution, but if that can somehow be simplified from a users' perspective I believe it will make the device more appealing to the DIY-community and Sunday-hackers. Perhaps it is just a matter of documenting it in a less overwhelming way (that matrix is intimidating at first glance).

[brandon]

Ethernet PHY added to existing MAC. Wireless is great for IoT portable toys but for IoT plant control you need power and reliability of wired connection

Could then build the ESP into the jack
https://www.digikey.com/en/product-high ... ted-pdjack

Bonus would PoE PD control could be in the PHY too, then all that's needed is external magnetics and DC-DC convertor

Can the CAN port extend to other protocols, e.g. MODBUS

A failsafe boot code segment so a failed OTA update can be rescued without needing disassembly to un brick. Don't want this with my devices -
https://techcrunch.com/2017/08/14/wifi-disabled/
On ethernet this is standard protocols, on wireless may set it to AP mode, if no stored credentials, so client app can attach and fix, BT is just a file upload