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.
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.
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.
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.
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.
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.
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).
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.
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
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).