What would you like to see in The Next Chip?

[Archibald]

In my view the main thing that needs sorting out for the next chip is the analogue to digital converter (ADC).

The issues with the ADC at present are:
1) Severe non-linearity with 11dB attenuation;
2) With a fixed input voltage, the digital readings vary significantly from one sample to the next (I guess this is due to noise on the reference voltage);
3) Inability to measure down to zero volts (currently only down to about 0.17V depending on attenuation setting);
4) There's no point currently having 11 and 12 bit resolution while there is so much 'noise'.
5) Atmel chips have sample-and-hold but I'm not aware of ESP32 having sample-and-hold. From Wikipedia:

Since a practical ADC cannot make an instantaneous conversion, the input value must necessarily be held constant during the time that the converter performs a conversion (called the conversion time). An input circuit called a sample and hold performs this task . . . .

I wonder whether some users would like flash ADC converters available to give very much faster sampling times, even if the resolution is say only 8 bits.

The option with Atmel chips to have an ADC working between zero volts and VDD can be useful, for example with joysticks.

[woofy!]

No promises on more RAM, although we're certainly looking at our options. (Issue is that RAM is relatively expensive; iirc, 3/4th of the silicon of the ESP32 is taken up by it.)

Here's an ESP32 die shot. https://s.zeptobars.com/esp32-HD.jpg.
Just for fun, can anyone spot the two CPU's.

[Vader_Mester]

No promises on more RAM, although we're certainly looking at our options. (Issue is that RAM is relatively expensive; iirc, 3/4th of the silicon of the ESP32 is taken up by it.)

Here's an ESP32 die shot. https://s.zeptobars.com/esp32-HD.jpg.
Just for fun, can anyone spot the two CPU's.

Just took a look. Sprite was not joking, holly s!

[loboris]

No promises on more RAM, although we're certainly looking at our options. (Issue is that RAM is relatively expensive; iirc, 3/4th of the silicon of the ESP32 is taken up by it.)

Here's an ESP32 die shot. https://s.zeptobars.com/esp32-HD.jpg.
Just for fun, can anyone spot the two CPU's.

Just took a look. Sprite was not joking, holly s!

Maybe a higher density lithography process could be used instead of 40 nm (32, 28, 22 nm) to keep the same die size and have more RAM ...

[ESP_Sprite]

We are certainly aware of that option. Unfortunately, it's not as simple of putting the design under a photocopier and setting it to 70% and shipping the result to TSMC...

[PaulFreund]

It's not really a request but rather a feeling, not even rational. Every time I am encountering a bug there is a voice in the back of my head that fears the Xtensa core or compiler might be at fault (even as this is highly unlikely) even tough it is my own fault most of the time.

Having an ARM would certainly create a safer feeling. For the long run having an open RISC-V core with a widespread and open source toolchain would be my dream.

Apart from that you really created an awesome piece of hard and software, thanks for that!

[georgeou]

Some feedback; I'm not promising anything but just to set expectations:
- 5GHz - I don't think it's a secret we're working on that.

Is there an estimate on when we can get a 5GHz ESP SoC?

[neltnerb]

To be honest, the ESP32 is so incredible compared to every other chip I've used before at that I find it hard to think of improvements!

Adding hardware USB 2.0 would be nice so that I can avoid adding a USB converter chip and I imagine potentially higher speeds, so long as it's still simple to upload code over USB. I'd also suggest using a switching regulator on your development boards since this chip is frequently targeted at low power applications, or provide a way to give the board 3.3V directly and bypass the linear regulator, but that's not really an ESP32 complaint.

If you're asking for a ridiculous wish list, add a FPGA to your modules so that we can add custom peripherals

Here's one of the few things that I simply cannot do efficiently right now. I often build equipment that requires high resolution data logging. A chip that I want to be able to use is the AD7768 which is an 8-channel, simultaneous sampling, 24-bit ADC that can be daisy chained to give an arbitrary number of ADC channels at 256kSPS. Problem is, to get data out that fast you're basically required to use octal-SPI.

I just barely got this to work by dropping the sampling frequency (to unacceptable speeds, but at least it worked), monitoring the CS line with an interrupt, and then using polling to read each of the eight data lines, but it's simply not fast enough to do that way. I tried just using the clock edge for interrupts, but the interrupt call time is too long to reliably read the data pins.

It would be amazing if there were a way to do arbitrary-width SPI slave in hardware to let me read a full byte per clock pulse. Of course, an integrated FPGA in your module would take care of that

I'd personally also find it a little nice to have a higher resolution DAC, 2x 10-bit DAC outputs seems to be common and 1024 steps is a lot nicer looking in a synthesized sine wave than 256 steps. I wouldn't prioritize it, but 8-bit DAC is a bit low in 2018.

I'd also add a formal ground pin to the external pins on your SIP package like the ESP32-PICO-D4 so that we actually don't have to solder the pad under the chip. The datasheet is actually very misleading on this one, but it was so hard to submit a note to espressif that I gave up. The datasheet for ESP32-PICO-D4 says that the pad doesn't need to be soldered for thermal performance, but it's also literally the only ground pin on the part so it obviously has to be. It would be much easier to solder by hand if I could rely on an outside pin for the ground connection and just leave the thermal pad touching the ground copper but not soldered.

I'm definitely planning to standardize on the ESP32-PICO-D4 or it's spiritual successor with the next ESP chipset, it's a beautiful product. My use case would be to connect the antenna through a u.Fl connector since I always use metal enclosures, it would be really incredible if the PICO had an integrated u.Fl connector somehow. I can't imagine how you'd do it though. I'm currently figuring to just use a super short trace to a u.Fl connector right next to it to try to avoid needing to build an impedance controlled board, which will hopefully work okay on a 2-layer PCB.

[ESP_Sprite]

Whoah, I never noticed the Pico-D4 only has the middle pad as a ground pad. It's not a good idea to not solder that one then, obviously. I'll ask the docs team to clean that up. If you ever run into something like that again, feel free to post something on this forum and we'll pick it up again. Also, good point wrt it being more easier to get a good connection to 'normal' pins. The thing there is, I believe, that you'd need multiple ground pins to get the same low impedance as with the center pad, bumping the package up to a bigger one with more pins.

WRT embedding an FPGA in the fabric: let's just say we're keeping all options open.

Wrt octal SPI: Have you looked at our I2S peripheral? it can also do 8, 16 or 24-bit parallel input and output (the 'camera' and 'LCD' mode) and has DMA to read/write the data without processor interference. It may make reading those ADCs a lot easier.

[neltnerb]

Yes, and an added ground pin would make the QFN asymmetric, you'd probably end up just putting a ground pin on each side. It's rare to find a sophisticated chip that only has one ground pin lately. I'm not so worried about the soldering, I have a hot air rework station and solder paste so I can definitely get the bottom pad. The datasheet was just misleading about it, and having the paste pattern recommendation in the datasheet would be pretty nice. I just made sixteen 1mm squares apertures, which I expect will be fine.

Footprint ESP32 Pico D4.png (8.89 KiB) Viewed 12536 times

I have not ever used I2S before, I had no idea it did that! This is the first chip I've used that had it built in. I'll have to read up on the specification, I thought the point of it was that it carried a clock pulse to set the output timing from the attached audio DAC but I wasn't doing that so I didn't read up more. I will check it out, maybe experiment with combining the chips, that sounds pretty great.