Not since they acquired atmel. Atmel documentation was shit and microchip documentation since they acquired atmel has become shit. Written badly, lots of information missing, datasheet format changed so that a 300 page document has become 500+ page with zero added information, it's just the layout with nonsensical page breaks, unreadable graphs and so on. Wouldn't have minded if atmel doc style stayed with atmel parts
Eh? I found, at least the classic MEGAs (32, 328, etc.) very well formatted. The peripherals are simple, registers documented inline, and even example code is given in both ASM and C.
I found the XMEGA+ documentation more frustrating, that the naming conventions are all more opaque. I've often found myself skimming through the io*.h header to find what the hell something is actually named. They do seem to use it consistently, at least, so it's usually just a few guesses nowadays to find what something is named. The most annoying recent example being AVR-Dx's bimorphic TCA (everything is TCA
n_
SINGLE_reg, etc.).
Other than that, I found most XMEGA prose to be usable, no particular problems getting something to work. That the ADC is offset is...weird (single ended mode), but, it seems to do what it says on the tin, in any case.
What I take issue with -- and I also get the impression of a slow decay in quality here -- is the AVR-Dx descriptions of peripherals, TCD in particular, but also TCA (and TCB could still be clearer). The organization is terrible, if you want to know some particular aspect you have no choice but to read the whole section front to back, hunting for any least bit relevant information. The explanation is far, FAR more complex than it really is (TCB in particular is guilty of this, being actually an extremely simple device, but
much more seems to be implied by the text!).
Whereas, original Atmel explanations were helpfully redundant: every section is self-contained, repeating anything in common with other devices, so that you don't have to jump around to get the full picture. It's generalized just enough, so that you aren't left guessing about anything. (For example: you might only have TC0 and TC1/TC2, but each is explained as if there could be multiple; on low end parts, it's true, while on bigger parts, you have many to choose from -- well, moreso with USARTs and such, than timers, but you get many more of both on XMEGAs for example.)
I think they've taken the same tack that a lot of other manufacturers have: outsourcing not just manufacturing, but service, and indeed now engineering as well. Combined with the contraction/ongoing restructuring of labor forces these days, there's altogether less engineering support, less responsible management thereof, and less quality oversight, of these processes.
TI for another example, is headed full steam into this layout. Of this, I am sure. There are too many signs of dropped quality, and design, and service, that are outwardly visible. I have no idea how much they still have in the west, but I can't recall ever seeing a non-Indian name on their e2e forum, so, that's service engineering outsourced at the least. I actually had an online meeting with one the other day (about an unrelated chip), and he admitted he doesn't know what or why sales/marketing is doing what they're doing -- he tells me the chip in question is NRND, but you wouldn't know that based on its product page or lifecycle status(!!!).
So, for MCP, I suspect the problem is, not only has service and documentation been moved over to India or other low-cost countries, but there are poor oversight/management/quality processes in place to handle it. Mind, their grammar is excellent -- I don't recall spotting a typo. It's well written, at face value, as English goes. Presumably, the techs/engineers they've hired, are near/at the top of their field; I have no problem with that at all. But there is still so much missing, that a couple also-top-of-field editors or managers or QC crew could cover, and it's just... there's no connections there, it's all dropped on the floor and left to rot. So we get documentation that is, despite being facially well-written, is just so poorly organized and non-descriptive.
The worst in production microcontrollers.. I guess those which i find the worst to work with, so worst dev tools. That's going to be Silabs and STM for me
Oh yeah, that reminds me of one I recall... FTDI Vinculum apparently is shite.
That was enough years ago (almost a decade actually, heh), so besides FTDI being lower market share nowadays(??), the whole line maybe is irrelevant? But, as things go, that was what I heard...
Have also heard negative about Si, but no direct experience.
1st/2nd hand experience with STM: middling. It's economy market: cheap parts, for everything that word entails. They're good for what they are, low enough bugs/errata, and powerful enough libraries and tools, that you can do real work without having to spend infinite digression dealing with bugs -- you still will spend some time on them, sure, but not most of your time. And the result will be bloated, sure, but not so badly that you're prohibited from making a thing. They have ample Flash and RAM to handle their shitty libraries. Optimization doesn't sell products, products sell products. Make the thing first, cost reduce it later -- if it even makes sense to at all.
Analogous to other things that people complain about, but not so badly as to give them up (or drive them to make newer/better). JS, Python, etc.; whether by themselves, or more particularly with the various libraries and ecosystems i.e. NPM, PyPI, etc. they're typically used with. They might suck, but not so badly as to want to go and fix the problems yourself (rather than work around it), and you're still making productive* applications.
*Again, in the most basic and most important sense: i.e., it earns money on average.
Tim
Home
Help
Search
Login
Register
