ESP32 Forum

There is a tendency in the mind set of technical folks (myself included) to want the latest and greatest and to feel "dis-enchanted" when we have "less than possible". With the release of a revision of the hardware that is the ESP32, we now have two variants of it in the market place. This thread is to examine the impact of that and to see if there is any "meat" on moving to the later silicon or even asking the question "what silicon do I have?".

In all my travels in ESP32 land, there isn't a single bug or problem or issue that I have on my list that I believe is resolved by the new silicon. Obviously, the new silicon does resolve problems (otherwise it wouldn't exist) ... and these appear to be listed here:

http://espressif.com/sites/default/file ... p32_en.pdf

This then brings in the first question ....

Q) Other than this list, is there anything beyond that content that is known to be resolved?

Given (for me) there is nothing of import in that list that I have needed, plan to need or even stumbled across, my opinion is for me to "resist" the temptation to get newer ESP32s ...just because they are newer. Based on this, and assuming nothing changes in my needs, then if I were to order some additional ESP32 modules in 6 months and received the older ESP32s, I personally would not feel slighted.

Well first you have to know the difference, then decide if you care.

For battery projects you probably want the new rev. For audio projects you probably want the new rev. For external ram you want the new rev.

For general stuff, you may not care, but you probably don't want to pay the same for it, all other things being equal. It is going to be an issue unless buyers force sellers to disclose chip revision and hold them to it.

For battery projects you probably want the new rev. For audio projects you probably want the new rev.

I would add camera projects to this list.
This is when processing of images above QVGA grey scale is required.

For my current projects I am more than happy with rev. 0.

FWIW, the fix mentioned under 3.3. also applies to ADC1 and ADC2

I couldn't reliably retrigger a conversion if I didn't wait a couple µs between writes to the "MEAS_START" register.

Switching to an alternative address, analogous to the fixed ones mentionend in the PDF made this work as expected.
Cheers

P.S: Is there a downside to using the 0x60xxxxxx address range?

WiFive wrote:For general stuff, you may not care, but you probably don't want to pay the same for it, all other things being equal. It is going to be an issue unless buyers force sellers to disclose chip revision and hold them to it.

Heh. I'd say you're going to have to get something along those lines going. There's enough little "oops"es in this stuff that you need to know, at the very least, what you're getting on these and very much prefer nothing to do with anything earlier than April 17 manufacture date timelines.

Manufacturing date code of XXX-161007 on a WROOM module is going to be a first rev silicon based device. They're still in the channel because I have been working with one on a project for the day job- and mine were bought Mid-Feb of this year. For now, it's "fine". For the follow-on projects, it's as discussed for me- I can develop the software, but the project itself kind of relies on Brownout Reset support, few other things like it.

madscientist_42 wrote:
Manufacturing date code of XXX-161007 on a WROOM module

Turns out it's not a date code.

WiFive wrote:

madscientist_42 wrote:
Manufacturing date code of XXX-161007 on a WROOM module

Turns out it's not a date code.

If it's the XXX...I put that in there. If it's not the date code, what IS it then?

madscientist_42 wrote:
If it's the XXX...I put that in there. If it's not the date code, what IS it then?

https://esp32.com/viewtopic.php?f=2&t=1358#p6182

WiFive wrote:

madscientist_42 wrote:
If it's the XXX...I put that in there. If it's not the date code, what IS it then?

https://esp32.com/viewtopic.php?f=2&t=1358#p6182

Great.

So there's absolutely no way to visually verify anything then?