Hacker News Reader

Comment by rkagerer | Hacker News Reader

Thanks for educating me as to the dumpster fire of patched together steps that take place in the first milliseconds of booting my PC.

With regard to this:

Intel CPUs ship with built-in microcode, but it's frequently old and buggy and it's up to the system firmware to include a copy that's new enough that it's actually expected to work reliably.

...I wish companies put more effort into releasing finished, polished products. Not just Intel. I played with an ESP32-S3 recently and learned not only was the entire digi controller for ADC2 'dropped' from support due to bad silicon, but using ADC1 with DMA was fraught with gotchas and blatently incorrect info in the documentation (reported at least a dozen to EspressIf and they acknowledged).

View on HN

The ESP32 ADC is a dumpster fire. I used one to sample an analog signal at 8Khz, looking for 400uS wide pulses (pacemaker capture pulses.) I originally started with an interrupt that triggered conversion from software. It would completely miss pulses 10-20% of the time and instead drift around, as if the ADC was floating rather than connected to anything. I finally got it to work reliably by switching to DMA through the I2S peripheral.

Pretty much every hobby project I look at, people complain about how bad the ADC is, and then just proceed to take N samples and average them. It's not that the ADC is bad, it's that the underlying firmware is buggy. I suspect there's a race condition with the main CPU and a coprocessor that's using the ADC for some internal wifi stuff.

Yeah I felt that pain :-).

On the ESP32-S3 ADC2 is shared with Wifi, but I don't think that's the case for ADC1. I made headway by throwing away all their boilerplate code and setting up the raw peripheral registers myself. I actually prefer it that way without all the abstraction underneath. Was getting nice results at 80kHz sample rate.

Would love to turn it into a write-up as I'm not sure anyone has done this before with that chip (at least I couldn't find any sample code around). It's actually all in MicroPython at the moment to boot... but wouldn't be hard to convert to C (and might even clean things up due to the more natural fit of that language working with bitfields). What I'd really like is to make it into a DMA-based ADC module for MicroPython but I'm not familiar enough with compiling that platform from scratch, particularly on Windows.

If you do end up writing it up, consider dropping it in the hackaday tip line (https://hackaday.com/submit-a-tip/). It sounds incredibly useful.

This is why companies still choose to buy expensive microcontrollers from big name reputable manufacturers (Microchip, TI, SiLabs, NXP, Nordic, STM, Infineon, Renesas, etc.) instead of going for the cheaper Chinese ARM microcontrollers at half the price.

They tend to usually test their designs a lot more thoroughly, which adds to the final cost, and even when their products do come with flaws, they're more likely to be transparent about it and assist you with workarounds and sometimes send over field engineers on-site to help you.

They also tend to be more honest about the specs, capabilities and limitations of their products in the datasheets. Finding out half-way through the design phase that some claims in the datasheet are bogus is a no-go for most companies.

If you're just doing hobby work, or tinkering, or planning to ship millions of bottom of the barrel products on AliExpress with no intention of providing any warranty or customer support for them, then it's fine to go with whatever's the absolute cheapest, but serious companies like Apple, Sony, etc. who care about the customer experience, won't risk delaying a product launch because they wanted to save 50 cents on a new unproven cheap microcontroller who's ADCs don't work right.

Uh, have you ever seen the length of a typical STM32 errata sheet? ;)

Uh, have you read the part in my comments where I said that they're morel likely to be honest about it? Having a short errata or no errata at all doesn't mean the product is flawless. It could be that they don't know all the faults yet, or aren't sharing them, or both.

For ST it could be that they seem to be the most popular cheap ARM microcontrollers for hobbyists and consumer products, so it's easier to find faults in them since so many companies use them, similar how the most used pieces of software also have the most vulnerabilities reported on them.

Also, maybe ST was not a great example on my end, as they seem to have an obsession lately with outsourcing and farming out everything to the cheapest offshore location possible and penny pinching to the extreme for their consumer oriented parts. I don't blame them though, competition in the generic ARM microcontroller market is cutthroats and margins are slim and salaries are low and your major customers (Sony, Apple, Samsung, LG, etc) keep putting the pressure on you to lower your prices or threaten to look somewhere else.

I've most definitely run into issues with others in that list, and my reports to the companies never generated an errata.

One fun one was that when accessing the External Memory Interface module (think: parallel ROM) and switching from Bank 1 to Bank 0, the HDMI controller would get reset, but only when configured for two banks of 32 MB.

If I did one bank of 64 MB and just used the extra pin as CS, it worked just fine.

There are lots of similar quirks in every chip.

From my time in the semi industry, when reporting issues for the erata, it depends who you are.

Are you some hobbyist or small company who sent your issue report to some generic company email address? Then your report most likely neve reached anyone on the team working on that chip, but probably reached some clueless jobsworth who didn't know what to do with it because large semi companies are highly siloed and there's no centralized management for such things, so you need direct contact with the team responsible for that chip.

If you're large customer, you then have direct email addresses of support engineers, application engineers and the engineers who worked on the chip itself, and so your reports will definitely taken seriously.

There's also another issue. There's public datasheets and eratas which are often not updated or fully transparent, and then there's confidential datasheets and eratas, which are updated and issued under NDA to industrial customers on a need to know basis. As a hobbyist you rarely get all the truthful info.

It's not ideal, but the semi industry mostly focuses on large customers who buy in large volumes of product, not on hobbyists and tinkerers.

Sounds like an open source/wiki for errata could be useful, at least then reports like yours could be published of the vendors do not

And that cost cutting is likely due to the rise of Chinese STM32 clones from companies most of us have never heard of such as GigaDevice, CKS, Geehy, MindMotion, APEX Semiconductors, etc...

Some die photos here: https://mecrisp-stellaris-folkdoc.sourceforge.io/clones-stm3...

I'd rather have a long errata sheet than no errata at all. I'll take truth in advertising any day over burring my head in the sand and pretending that everything's perfect.

I would generally agree with this, however I do find the esp32 on the whole has been as reliable as any of the major brands (although haven't had to use an ADC). We don't drive them too hard though, but their cheapness has pushed the bigger guys to get more competitive on pricing which is a good thing. TI in particular seems to have sharpened their pencil a bit, maybe due to all their new fabs coming online?

The big guys still screw up, and over the journey I've noticed quite a few MCU subfamilies go EOL far before they should and it's usually due to silicon that has too many bugs in it. Maybe the big guys told them 'no' so there weren't any decent volumes on them anymore and they were forced to adapt.

Sometimes they're a bit more subtle. You've probably seen quite a few 'A' revision part numbers recently where they clearly keep the same MCU but fix the bugs. See this on other IC's as well.

For us, logistics (supply chain) and a solid support team are the highest importance. It's rare that we're locked into a single vendor due to a must-have-feature. These requirements narrow down our choices very quickly, and I'm sure it varies region-by-region (and how much $$$ you spend).

Yeah I do like the chip and feel it would be fantastic if it all worked according to original design intent.

I don't know about all of that. TI's Stellaris microcontrollers were probably the worst chips I've had to deal with including sketchy Chinese chips.

I think my favorite part of this discussion is that most developers give this sort of process/code a mystical vibe. Like it's some sacred code built by a priesthood of the world's greatest and smartest programmers. Not accessible to mere mortals.

I encourage developers that work for me to just read the code and documentation. My advice to them is usually something along the lines of...

Think of how you would have done it as a sophomore in college completing an overdue assignment... chances are it works just like that

Sure but I have some sympathy here … a contemporary CPU probably has a million different capabilities and if some not-even-single-digit-percentage of them don’t work that’s a lot of errata. Plus it’s hardware! So it’s hard to fix it once it’s out.

Single digit percentage? CPUs are generally bug-free to several orders of magnitude greater than that.

Almost as if they have a not-even-single-digit-percentage of bugs...

Thanks for the tip about the ESP32-S3 ADC2. Coincidentally, I was about to embark on that trail only to learn the hard way. You've likely saved me a good deal of frustration.

> dumpster fire of patched together

That's more or less the history of the x86, from the 8086 and on. I'd add a couple extra expletives as well. I can imagine a number of better ways seeding CPU state prior to starting it in a way they could all be neatly started in parallel.

> I wish companies put more effort into releasing finished, polished products.

Some do. It's just that their hardware is expensive and not very available outside some niches.

Reply on news.ycombinator.com