What would you like to see in The Next Chip?

[ruppie]

#WhereIsWifiP2P

@Gfast2

As i told you in the "your" OPCUA forum:
The problem is not that ESP-32 does not support the Open OPC UA lib,
The problem is the library itsself.

Example:
"Matrikon" provides working examples for some emdedded plattforms based on lwip.
I showed a reference based on the XMC_4800 Ethercat relax kit to you
There solution (comercial) is runnung smoth and is customized very easily.
The reason why there are only a few (none currently, working as i know) open source libraries about OPC UA exits,is that providing an OPC UA SDK, expecially for embedded systems is part of buisiness modells and comercial products.

Very subrisingly, not everything on the internet is for free

It is not up to ESP-32 to do the work it is up to us (contributors of open OPC UA stacks).

Marc

[dmaxben]

Couple things I would really love to see in the next chip..

second CAN controller

native USB

more GPIO's

Everything else Im 100% happy with!

Additional memory is always good too, but I dont think I'd ever have a project to use it...better to have extra and not use it, than not have enough and need it though.

[Vader_Mester]

I would like to see a bit more GPIO pins.

Also, since the ESP32 has an amazingly fast Clock, if you can include a MIPI DSI phy peripherial into the ESP, that would be a killer chip and wash away competion.

Like STM32F469 sieries controllers have integrated MIPI DSI phy, but it only has a single core (although dedicated graphical controller), and the cost of them is very high, compared to current ESP chip costs.

I have seen the tendency that there is actually a requirement for ESP to implement grapchics, since the fast clock and 2 cores makes it very capable of doing so.
With the multiple core option on the next ESP chip, 1 core could be dedicated to crunch the display data, and using the fast clocks, output the data on MIPI DSI, you open the way of making cheap IoT stuff with ease
And MIPI DSI is supported in almost all LCD-s.
(Also MIPI DSI would only use just a few pins (2 pins for clock, and up to 8 pins for 4 data lanes, not that much).

I hope you consider this option
Vader [BEN]

[rudi ;-)]

i think, this suggestion is done here in the list more times,
but i want make it again that this becomes a high priority
that it will not be forgotten because it would be incredibly important
not only because of technical requirements / wishes,
but to keep up in the competition.


- USB HOST / DEVICE ( OTG ) >= 2.0

so please don't burn out it again from 108 basic'S if you use this architectur as base

Diamond_WP.pdf

(683.36 KiB) Downloaded 769 times

108.png (102.83 KiB) Viewed 14018 times

thanks

best wishes
rudi

[rwel59]

My real struggle with the current chip is making it function in a low-power environment. This primarily means (at least to me) the ability to run for an extended period on battery without losing the ability to interact with the system, i.e. receiving either/both wifi and ble requests, waking up and responding to request, going back to power-saving sleep.

Scrambling for workarounds with this lack of current capability and starting to think of moving to another platform since it doesn't appear as though these will be solved near-term.

[hassan789]

Indoor positioning with Wi-Fi RTT (Round Trip Time) also known as 802.11mc WiFi protocol

[Vader_Mester]

My real struggle with the current chip is making it function in a low-power environment. This primarily means (at least to me) the ability to run for an extended period on battery without losing the ability to interact with the system, i.e. receiving either/both wifi and ble requests, waking up and responding to request, going back to power-saving sleep.

Scrambling for workarounds with this lack of current capability and starting to think of moving to another platform since it doesn't appear as though these will be solved near-term.

To be honest and not to be rude, this is in fact implemented. You will never find any other chip, with the capability you describe. What sounds good on paper may not be as good in the real implementation.
In fact the ULP coprocessored is designed to do just that, wake the chip up to do stuff and sleep.
Powering a receiver and amplifier costs current on any platform, so think again

Also, frankly speaking, if it is a commercial product then probably someone above you will decide to go with cheaper components like the ESP... as usual

[ESP_Sprite]

Lemme give a few responses here. Again, I'll give no hard guarantees about our roadmap and anything I say here may change at the last minute.

• Chip with LPDDR/EMMC: That will perhaps happen somewhere in the future. We have a few plans for a chip where this will be applicable, but they're all mostly in the planning stage.
• Pulse counters in the RTC domain: Hmm, should have read that a few months earlier. I'll keep that in mind, however.
• Active filters mostly is a software/DSP thing; the ESP32 can already do this (we have e.g. a MAC instruction to do FIR/IIR filters easily). We're thinking of ways to make it even faster in the future, though.
• More DAC (pins/resolution): Don't expect anything in the near future wrt more DACs; we'll certainly keep it in mind, however.
• LoRa-integration: Nothing is planned short-term.
• Better debugging integration: That's mostly a software thing. We're however working on something to make you not lose 4 pins to JTAG anymore. No promises, however.
• USB: This has been mentioned so often, we're probably going to put it in a new chip just to not hear requests for this again
• More GPIO: This also has been a thing internally, and we're taking this request seriously.
• No fixed input/output pins: This is kind-of hard for some peripherals as they need a specific pad driver (analog functions) but our digital team say they have a trick or two up their sleeve to make more digital pins flexible.
• More RAM / more options to move stuff to external RAM: In the ESP32 we have now that has indeed been limited by a few hardware things. We're working on removing these limits in the new chip.
• MIPI-DSI: We've been thinking about this, but unfortunately it's not as easy as just dragging&dropping a MIPI DSI controller into the design...
• Rudi: We don't start out with an existing system and then remove parts that's not how it works. If you buy an Xtensa, all you get is the capability to generate a version of the bare core. All the other peripherals, you'll have to pay for the IP and integrate it into whatever system you need; for stuff like USB2.0 (mostly high-speed) you have the added issue that the analog bits of the PHY then also need to fit into whatever analog process you use. Still, we know that USB is a much-requested thing, and we'll try to at least meet you guys halfway there.
• Low-power: Gotcha. The next chip we'll make probably will only be somewhat more efficient than the ESP32 (and even in the ESP32, we can squeeze out some more efficiency in software) but longer-term we do have plans for something.
• Wi-Fi RTT: We actually have a fair bit of the hardware needed for something like this already; we just haven't had any requests from big customers to write the added driver support for it (at least, that's what I understand); also, I'm not sure if hardware support actually has been tested in any way; for all we know it may be broken. Don't be surprised if something like this pops up in esp-idf in an upcoming version, however.

[Vader_Mester]

Reading Sprites post, I'm very happy, he summed it up, with teasing short term things as well

I was just thinking about the GPIO thing the other day.
As far as I know, the ESP is only 1 version of silicon, to make only 1 design, and manufacture everything veeeeery cheap, hence the extremely low price of the system.
However as far as I know, it is not impossible, to use 1 silicon for several GPIO amounts.

What would make a change is not necessarily the GPIO pin count, but the package. Iwould like to see a BGA version of an ESP chip however, that would be interesting for the indusctrial level makers, to create even smaller stuff.

[BrucePerens]

Your strategy of leveraging as much Open Source as possible is working out great, it would be nice to see more of the low-level code opened up. For example, it looks like you have an SDR of sorts in there to do WiFi and Bluetooth, some of us would like to put it to use in other ways, perhaps as a high IF for a radio on another frequency. I buy Lime Micro for that right now, but it's way too big for some jobs. Note the extent to which RTL-SDR has ignited a market by accident, much as ESP-8266 did when it was marketed as a radio modem with AT commands rather than a general-purpose processor.

Thanks

Bruce