Which mainstream micros have the worst documentation, buggiest silicon etc.

[e100]

Or to put it another, way which micros cause you to spend lots of time searching forums for fixes to things that are supposed to work, but don't?

[westfw]

“We” just noticed that the initial 8-pin tiny-0 and tiny-1 AVR DataSheets (attiny412) fail to mention that there are pins connected to most of the timer compare outputs.  That’s a pretty big mistake - 1 pwm output vs 5!
 I normally like the Atmel/microchip data sheets - they tend to be clear and well written and understandable.  But there have been some big mistakes recently.  Apparent cut&paste errors from othe chips in the same family, paragraphs on setting up the UART fifo using a register that doesn’t exist...
Fun times!

[nctnico]

Microchip and Atmel are on my blacklist for various reasons. ST microcontrollers can also be quite finicky to work with.

[ddavidebor]

I have found myself always a bit disoriented from ST uC datasheets, despite loving the STM32 series and their development tools.

Don't know why.

[PCB.Wiz]

Which mainstream micros have the worst documentation, buggiest silicon etc

The newest ones ! 

[bd139]

Microchip and Atmel are on my blacklist for various reasons. ST microcontrollers can also be quite finicky to work with.

That's basically most of them isn't it? 

Z80 still has some weird in it even after 40 odd years.

[MT]

STM32 a pain in the arse basically since i worked most with them but recently there have been a upgrade, the language is different also the documentation style is quite different for some devices, so it seams they finally have hired some native English speaking manual writers. But in general people come and go in documentation departments, companies are bought and sold, back in the day Phillips was always among the best and everyone else the worst.....sort of..... depends on product to i suppose.....But i can imagine others alot worse then ST...i just havent worked with their docs yet.

[garethw]

I would compare MCU datasheets to kitchens. Cooking in your own kitchen where you know where everything is isn’t a problem. Try cooking in someone else’s. A little bit of time spent in someone else’s kitchen and you get to know where stuff is and the quirks.


Sent from my iPhone using Tapatalk

[e100]

Can I turn the question around and ask which micros are least troublesome.
In other words, most things do work just as they are supposed to 

[nctnico]

Microchip and Atmel are on my blacklist for various reasons. ST microcontrollers can also be quite finicky to work with.

That's basically most of them isn't it? 

No. Not by a long shot.

[Dave_PT]

Renesas RX23T...

[brabus]

Microcontrollers: Freescale i.MX

Analog: ST Application Notes. Very well written, but the calculations are often wrong!

[SiliconWizard]

Sorry about that, but... so far: the Kendryte K210. (Ok it's not mainstream...)
 

Other than that, Microchip tended to release long errata for many of their MCUs. They used to have good documentation, I think not so much anymore.

[aldi]

The wireless cortex series from Silicon labs. I've used the EFR32 series, and they are by far the most buggy/crappy I've ever used. Avoid them at all cost.

[IDEngineer]

IMHO, the Microchip spec sheets are pretty well written. Sometimes the placement of data seems less than obvious, but so far it's always been in there with a single exception that I can remember in the last ~7 years or so. I'm speaking here of the PIC18 and PIC24 families.

On the flip side, I find the STM32 family spec sheets to be almost unusable. So far the ones I've tried to use read more like marketing puff pieces, lacking very basic technical details that made it impossible for me to even determine if the part could do what I needed. I remain open minded since the STM32 is so popular - maybe it's just me.

[mark03]

The wireless cortex series from Silicon labs. I've used the EFR32 series, and they are by far the most buggy/crappy I've ever used. Avoid them at all cost.

The EFR32 saga suggests another rule of thumb, besides the one above about newer parts being buggier:  Those parts which had repeated delays / broken promises in their release process may be wise to avoid!  There are times when everyone in a company realizes they have a turd on their hands, but they have to at least recoup some of the development cost, so the only thing left to do is polish the turd as much as possible and hope for the best.  We've all been there.  You just don't want to be on the customer side of one of those parts.

[SiliconWizard]

On the flip side, I find the STM32 family spec sheets to be almost unusable. So far the ones I've tried to use read more like marketing puff pieces, lacking very basic technical details that made it impossible for me to even determine if the part could do what I needed. I remain open minded since the STM32 is so popular - maybe it's just me.

With STM32's, the technical info is like spread out between datasheets and reference manuals. If you look at datasheets only, you won't get very far indeed.

The Ref Manual for the STM32L4 series for instance is almost 1500 pages. 

[MT]

Can I turn the question around and ask which micros are least troublesome.
In other words, most things do work just as they are supposed to 

68HC11, HC811 HC11F1, etc but thats 3 decades ago. things was simpler then.

Edit: like to add MSP430 untill and after TI mask revision period faffing.

[amyk]

Can I turn the question around and ask which micros are least troublesome.
In other words, most things do work just as they are supposed to 

68HC11, HC811 HC11F1, etc but thats 3 decades ago. things was simpler then.

I'll add 8051 to that list.

I agree about ST's documentation; excepting some Chinese-translated docs, they've been the most memorably difficult to understand out of the dozen or so uC families I've looked at.

Regarding PICs and their long errata, at least they have published errata...

[nigelwright7557]

The PIC's tend to have bits all over the place.
Things like powering up with A2D converter enabled when you want to use that pin as GPIO.

I recently had a buffer problem on a PIC32.
The buffer was getting corrupted.
Turned out the buffer was being filled by USB via DMA and DMA doesn't update the cache.
You have to make the buffer "coherent" so it isn't cached.

[hans]

  => PIC32MZ (EC errata..)

But still would like to call them out for integrating a USB2.0HS peripheral on their new chips (which for their EF series looks very attractive), but then go on to only provide register level documentation for the USB peripheral. No procedures, no step by step initialization or guides of doing things, nope.
Either it is NDA (which seems strange to release half a document), or they really want to force you into using their Harmony framework. The latter sounds like a blunt mistake to me, as I don't see any reason why a manufacturer will force such a large dependency on their customers.

This experience was quite orthogonal to me with the PIC32MX. I think I once wrote a driver for their ethernet MAC controller from scratch in a few hours.
---

I agree with the general consensus about ST. However, I would like to make a counter argument that their power consumption charaterisation for their L series part is very detailed. Of course any documentation will miss things at low power stuff (the golden standard is still experimentation and measure your application), but I found their datasheets revealing far more information than for example a modern MSP430 chip with FRAM, which seems to be lacking so much detail in that regard.

[Kilrah]

but then go on to only provide register level documentation for the USB peripheral. No procedures, no step by step initialization or guides of doing things, nope.
Either it is NDA (which seems strange to release half a document)

USB-IF licensing shenanigans maybe? As in MCP can't include in their public datasheet stuff that would tell too much about what you're supposed to pay USB-IF to get?

[T3sl4co1l]

=> PIC32MZ (EC errata..)

The PIC24E series too.  Nevermind that any PIC24 is a bizarre hack of PIC architecture with more bits, but apparently the E is particularly bad.  I didn't work with it myself, but coworkers said it was a mess.

Tim

[Rerouter]

Yeah gaps in the datasheet is annoying for some of the AVR stuff, e.g. there capsense peripheral, they have hardware in the device (registers that control it), to fairly accurately measure external capacitance, but its completely undocumented, only available through AVR studio.

[hans]

but then go on to only provide register level documentation for the USB peripheral. No procedures, no step by step initialization or guides of doing things, nope.
Either it is NDA (which seems strange to release half a document)

USB-IF licensing shenanigans maybe? As in MCP can't include in their public datasheet stuff that would tell too much about what you're supposed to pay USB-IF to get?

You can find far more USB2.0 HS peripheral documentation in datasheets of ATSAM V71 parts or STM32F4 series.

Sure there will be gaps in any documentation, but outright not documenting a "flagship" peripheral (i.e. at the time of release there weren't many USB2.0HS + phy MCU's) is appalling.