Feedback on what ESP32 "2.0" should be

[PaulNi]

Hello,

This is a follow up on https://www.esp32.com/viewtopic.php?f=2&t=10713.

Previously I had a conversation with some of you on Twitter: https://twitter.com/EspressifSystem/sta ... 1474898944. I made a summary of that with some new thoughts:

1. At least some high speed peripheral I/O option. I think it's a must.

There is a huge gap in between basic MCUs and smartphone class SoCs. I can say that using a full sized SoC is very often an overkill for a typical gadget. When we try designing new things we try really really hard to fit everything within MCU limitations, but a single whim of a client like "I need USB C" or them wanting an nicer IPS graphical panel often force us to put a full sized SoCs.

Even such simple things as kitchen appliances, bicycle locks, digital picture frames and such often have to use Allwinner or other cheaper SoCs just to drive a MIPI display, or native type-c.

Having even 1 high speed interface will open door a whole lot of new options: with MIPI you can use MIPI displays, single chip SSDs, new sensors, bridges to displayport, hdmi, i3c, pcie and much more

2. I heard it's possible to drive both MIPI and USB from a single PHY.

I was once told that Arasan and Cadence have IP for a PHY that can talk both USB 3 and MIPI. What do you think of prospective of putting a single PHY and then allow users to switch in between USB and MIPI over it? How costly it will be? How much will it affect WiFI (USB3 works very close to WiFI frequency)

3. Some analogue and RF peripherals will be nice.

On analogue side, you are more or less round. The only big issue I can think of is antenna tuning. It is a big problem for portable electronics and smart furniture. I can make a real time antenna tuner, but it will cost $100+ — not a solution for an MCU based product.

How real is the possibility of putting even a simplest tuning network into the package?

4. Power, some officially approved designs will be nice.

Power should also be a part of a "solution" package. DC, AC, POE, coin battery, AAA, li-ion with charging, solar, etc all require some inventiveness for maximum power/cost efficiency in every use case.

I think somebody can start doing a "reference design" library with some level of official support from Espressif. I'm in particular looking how to implement "power feedback" to reduce switching speeds of bucks and boost converters during wifi inactivity.

5. Type-C is a very hot feature.

I think everybody heard of this already, but it feels to be a hard nut to crack.

In our company, dealing with type-c it is a non-stop pain. USB PD 2.0 is a nightmare to handle in software. There is simply "no chip to do it all." on the market and I think that's a commercial opportunity.

Few consumer products on the market with "native" Type-C are all built on FPGAs, and those are not cheap.

6. SPI/QSPI MRAM.

Well, if you went to support QSPI DRAM, why not put some software support for SPI/QSPI MRAM. Those are not cheap, but they are often the only suitable solutions for logging, or design requirements for unlimited write cycles (automotive)

7. Display options.

I think you got that cared off in S2, but the market for nice "direct drive" parallel interface LCDs gets smaller and smaller with each year. Some times, it's easier for us to buy a nice MIPI panel with touch screen from smartphone maker leftovers than look for serial interface LCD, especially for larger sizes. And as a bonus, such panels often come with own digitisers for touchscreens.

So, some dedicated IF to drive modern display panels will be really really nice.

8. Packaging.

Custom packaging options, new "System on Package" options - very very handy for portable electronics, they needs more coverage and attention. You know, lots of smaller PCBas and ODMs in China still don't have tooling for tiny pin pitch components.

9. Other suggestions in general.

Above all, it needs to be more "thought through." For example, ethernet phy and reset/reflash sharing the same pin was a showstopper for POE devices, it's possible to work around, but still somebody should've though of pin conflicts at least on reset pins.

[mikemoy]

9. Other suggestions in general.

Above all, it needs to be more "thought through." For example, ethernet phy and reset/reflash sharing the same pin was a showstopper for POE devices, it's possible to work around, but still somebody should've though of pin conflicts at least on reset pins.

Can you elaborate, I have made a POE device and it does not suffer from what I understand you to say here.

[PaulNi]

9. Other suggestions in general.

Above all, it needs to be more "thought through." For example, ethernet phy and reset/reflash sharing the same pin was a showstopper for POE devices, it's possible to work around, but still somebody should've though of pin conflicts at least on reset pins.

Can you elaborate, I have made a POE device and it does not suffer from what I understand you to say here.

This guy describes the problem more in detail: https://www.crowdsupply.com/silicogniti ... reset-saga

There are other ways around that of course, but things could've easily be made way more straightforward if somebody thought of that at the design stage.

[mikemoy]

Ok, now I understand. IMHO they did think it all through. Its most of the users did not take the time to read all the material.
Many people got banged up with the GPIO0 issue. I don't know why because they had this function:

static void phy_device_power_enable_via_gpio(bool enable)

All one needed to do is tie the EN pin of the OSC through a resistor to GND, and to spare GPIO pin. This would have solved the problem. But sadly most did not figure this out.

[ESP_Sprite]

To be fair, in hindsight, the GPIO0 mixup was not the smartest decision we could have made; it needs everyone to work around it in some way while it could've been transparent if we used a different GPIO. We're well aware of this and the philosophy for the ESP32-S2 has been to not mix special function outputs and bootstrap inputs.