The thing I loathe the most about embedded work is dealing with silicon vendors and their boneheaded refusal to publish the fucking documentation and tooling.
Microchip in particular is very bad at developer experience and tooling. The only vendor I actually enjoy working with to any degree is ST, and only design boards using their uC's for that reason.
I've heard good things about Nordic, though. Might try them out at some point.
Microchip's own IDE and project generator spit out a hello world project that didn't even compile. NXP wouldn't even let me download their tooling even after their obfuscated sign up flow.
I was on the Microchip bandwagon until the PIC32. Little MIPS MCUs with onboard RAM and graphics, awesome! ...except they came with an errata that listed huge problems with every interesting peripheral, and it didn't improve for ages. They may still suck, I don't know.
A while back I tried out Espressif's esp32 and I was impressed by what they were offering. Their devices seem to be well documented and the esp-idf framework is really pleasant to use. It's much easier to work with than STM32Cube and ST's sprawling documentation.
Which NXP tooling did you have trouble with? I’ve downloaded MCUXpresso earlier this week, no NDA or anything (yes you do need an account), it’s never been hard to get…
Perhaps they think that by forcing everyone to go through the sales dept just to get the basic docs, they'll get better sales opportunities.
How do you upsell a hardware engineer who just wants to buy a specific chip, and already has everything to evaluate and use it? You don't. So you force everyone to go through sales, and then sales wants to talk to non-engineering higher-ups, and then the upsell happens - while the people who actually knew what they wanted remain as far away as possible.
And if you don't have the pockets deep enough for the sales dept to acknowledge your existence, then you might as well not exist.
They don’t care about ‘upselling’ - it’s just that they only really care about the orders that are at least in the tens of thousands of units (or for the Broadcoms of the world, hundreds of thousands) per year, and ongoing.
If you even promise to buy a few hundred a year through a business, it puts you in a different category and everything gets much easier, but you usually have to go via a distributor (Avnet, Future, Arrow etc.). But if you’re big enough (the hundreds of thousands + qtys) these companies will actually send dedicated support engineers to work with you and help you integrate their parts into your product.
I wish that Microchip would officially publish the programming algorithms and EE bit maps for the Atmel ATF16V8, ATF22V10 SPLDs and ATF15xx CPLDs. They programming algos have been mostly reverse-engineered (or otherwise figured out), but it'd be nice to have those published in the open, and I don't think the ATF15xx maps are completely known.
The ATF15xx have BSDL files released, but that's only for testing/bypass.
I'm really enjoying this series, and this one is a good example of how working with hardware can be really difficult as manufacturers aren't always fully open (or honest) about device's capabilities. But typically you don't find that out until you're already a long way through bring-up.
This was an impressive amount of research to get what he wanted out of the device!
The same is common in software. A real nightmare for me was a client insisting their entire library was single threaded only to discover one small but aspect wasn't deep into development and debugging. Had to refactor a huge chunk of the project.
On the topic of Microchip and secrecy: I downloaded and installed their IDE, MPLAB X IDE v6.20. It is for a pic3mx chip. The compiler looks like a completely generic gcc, built to cross-compile on a Windows host. However, they want a $1000.00 “licensing fee” in order to enable any optimization level above -O0.
This seems wrong. Wouldn’t this be a violation of the copyleft license covering gcc?
I’m guessing there’s some loophole, since otherwise EFF and folks would be going after them. Or perhaps they don’t know about this situation? Should I alert EFF to this situation
The GPL in no way forbids that. However, if they are obeying GPL you can ask them for the source code and then remove that limit yourself. If you ask for the source and they don't give it to you, then alert GNU.
Of course that depends if the optimization was compiled into the version they have. One can imagine two binaries with the optimizations just missing from the free one.
How much does it look like gcc? Can you run it on its own with a --version argument, or run it through strings to get the text out of it.
If it's actually gcc, a copy of the GPL should have come with the software. A bunch of other compilers mimic a lot of its interface for compatibility’s sake.
Yeah I’m really not a fan - we had some designs with PICs on them and ended up switching to NXP micros (MCX-A and i.MX-RT) instead, partly because of MPLAB and also because the Microchip ones had some annoying quirks. NXP’s documentation I find a lot better too. I literally try to avoid Microchip where I can from the experience…
Personally I hated the NXP's docs for the ARM M4 core. Bunch of dry tables listing each register in details, lacking the juicy diagrams and descriptions on how the bits integrate to work as a subsystem. I constantly needed to cross-reference 3+ documents (most of which describe the whole family and not the specific IC). Their HALs and code samples were obviously written by students/interns.
I liked working with Microchip uC, but this was back when the whole IC (PIC24) was described in a single ~1000 page document. I found it very readable and instructive in general.
If I had to pick something today it would be with RP2040/2350. The docs look awesome and there's a huge community that is not locked down in some corporate moderated forum but spread organically, with actually useful GitHub projects. It is the only embedded product where it felt like the open source community is along for the ride and not just picking up the scraps. I hope they continue this line of products.
Yeah, NXP in my experience had an issue with having too much documentation. In the sense that you get drowned in a 3000 pages PDF that lists every detail but becomes hard to parse unless you want to base everything around that specific platform for years. Though that sounds like an awesome "issue" to have in some circumstances.
It's been this way forever... They do distribute source (but last time I checked it is with incomplete build info). I think there is also some BS fine print about the licensing fee being for the provided header files.
- you can charge money for things
- anything that's not built with the "official compiler" is not "supported"
I've interviewed for a junior embedded software engineer when i was in university and when i started mentioning i had experience building cross-compilers i was immediately stopped by the guy interviewing me (he literally didn't even let me finish the sentence) and told me "Absolutely no. We don't want to maintain our own toolchain and we want everything to be coming from the BSP [Board support package] and integrated nicely with the vendor's IDE.
They used ARM chips, so not even anything strange...
The real issue would come if they did not provide the source code for the gcc build they sell you, though.
Token ring was old in 1996 when my masters thesis focused on error handling behavior and simulation thereof.
I wonder if there are certain elements in certain "industrial complexes" that need to maintain or interface with legacy TR systems and that's why it's still hanging around in "dark silicon".
While not technically TR, it does use a token that moves from device to device.
It would be interesting to know if TR is better at contention management than broadcast ethernet - which nobody does anymore because everyone uses switches.
AVB and TSN are relatively new addition to Ethernet, and specifically designed for realtime AV use. Traditional Ethernet is not really intended for tight real-time use.
There is audio distribution real-time and nuclear reactor (or avionics, medical, etc) real-time. I assume the people doing (or certifying) the latter will want better guarantees.
Microchip seems to be reasonably good at opening stuff up that it's bought from other companies; various Atmel security ICs which were previously very secretive now have full datasheets freely downloadable from their site.
The thing I loathe the most about embedded work is dealing with silicon vendors and their boneheaded refusal to publish the fucking documentation and tooling.
Microchip in particular is very bad at developer experience and tooling. The only vendor I actually enjoy working with to any degree is ST, and only design boards using their uC's for that reason.
I've heard good things about Nordic, though. Might try them out at some point.
Microchip's own IDE and project generator spit out a hello world project that didn't even compile. NXP wouldn't even let me download their tooling even after their obfuscated sign up flow.
I was on the Microchip bandwagon until the PIC32. Little MIPS MCUs with onboard RAM and graphics, awesome! ...except they came with an errata that listed huge problems with every interesting peripheral, and it didn't improve for ages. They may still suck, I don't know.
A while back I tried out Espressif's esp32 and I was impressed by what they were offering. Their devices seem to be well documented and the esp-idf framework is really pleasant to use. It's much easier to work with than STM32Cube and ST's sprawling documentation.
Which NXP tooling did you have trouble with? I’ve downloaded MCUXpresso earlier this week, no NDA or anything (yes you do need an account), it’s never been hard to get…
True, and Microchip is still good when compared to the likes of Broadcom and Qualcomm.
I don't do embedded work, but I see Broadcom and Qualcomm show up a lot in Linux bugs.
I'd love to hear stories of what it's like to work with chips from these companies.
Oh yeah definitely.
Why though? This is clearly a problem I just don't understand what the vendors are getting out of it.
Perhaps they think that by forcing everyone to go through the sales dept just to get the basic docs, they'll get better sales opportunities.
How do you upsell a hardware engineer who just wants to buy a specific chip, and already has everything to evaluate and use it? You don't. So you force everyone to go through sales, and then sales wants to talk to non-engineering higher-ups, and then the upsell happens - while the people who actually knew what they wanted remain as far away as possible.
And if you don't have the pockets deep enough for the sales dept to acknowledge your existence, then you might as well not exist.
They don’t care about ‘upselling’ - it’s just that they only really care about the orders that are at least in the tens of thousands of units (or for the Broadcoms of the world, hundreds of thousands) per year, and ongoing.
If you even promise to buy a few hundred a year through a business, it puts you in a different category and everything gets much easier, but you usually have to go via a distributor (Avnet, Future, Arrow etc.). But if you’re big enough (the hundreds of thousands + qtys) these companies will actually send dedicated support engineers to work with you and help you integrate their parts into your product.
I think the short answer is because manufacturers don’t care.
I wish that Microchip would officially publish the programming algorithms and EE bit maps for the Atmel ATF16V8, ATF22V10 SPLDs and ATF15xx CPLDs. They programming algos have been mostly reverse-engineered (or otherwise figured out), but it'd be nice to have those published in the open, and I don't think the ATF15xx maps are completely known.
The ATF15xx have BSDL files released, but that's only for testing/bypass.
I'm really enjoying this series, and this one is a good example of how working with hardware can be really difficult as manufacturers aren't always fully open (or honest) about device's capabilities. But typically you don't find that out until you're already a long way through bring-up.
This was an impressive amount of research to get what he wanted out of the device!
The same is common in software. A real nightmare for me was a client insisting their entire library was single threaded only to discover one small but aspect wasn't deep into development and debugging. Had to refactor a huge chunk of the project.
On the topic of Microchip and secrecy: I downloaded and installed their IDE, MPLAB X IDE v6.20. It is for a pic3mx chip. The compiler looks like a completely generic gcc, built to cross-compile on a Windows host. However, they want a $1000.00 “licensing fee” in order to enable any optimization level above -O0. This seems wrong. Wouldn’t this be a violation of the copyleft license covering gcc? I’m guessing there’s some loophole, since otherwise EFF and folks would be going after them. Or perhaps they don’t know about this situation? Should I alert EFF to this situation
The GPL in no way forbids that. However, if they are obeying GPL you can ask them for the source code and then remove that limit yourself. If you ask for the source and they don't give it to you, then alert GNU.
Of course that depends if the optimization was compiled into the version they have. One can imagine two binaries with the optimizations just missing from the free one.
If they distribute the one with optimisations, then they need to make the source available.
In some jurisdictions you may even be able to sue them for the source code without bothering GNU.
How much does it look like gcc? Can you run it on its own with a --version argument, or run it through strings to get the text out of it.
If it's actually gcc, a copy of the GPL should have come with the software. A bunch of other compilers mimic a lot of its interface for compatibility’s sake.
Yeah I’m really not a fan - we had some designs with PICs on them and ended up switching to NXP micros (MCX-A and i.MX-RT) instead, partly because of MPLAB and also because the Microchip ones had some annoying quirks. NXP’s documentation I find a lot better too. I literally try to avoid Microchip where I can from the experience…
Personally I hated the NXP's docs for the ARM M4 core. Bunch of dry tables listing each register in details, lacking the juicy diagrams and descriptions on how the bits integrate to work as a subsystem. I constantly needed to cross-reference 3+ documents (most of which describe the whole family and not the specific IC). Their HALs and code samples were obviously written by students/interns.
I liked working with Microchip uC, but this was back when the whole IC (PIC24) was described in a single ~1000 page document. I found it very readable and instructive in general.
If I had to pick something today it would be with RP2040/2350. The docs look awesome and there's a huge community that is not locked down in some corporate moderated forum but spread organically, with actually useful GitHub projects. It is the only embedded product where it felt like the open source community is along for the ride and not just picking up the scraps. I hope they continue this line of products.
Yeah, NXP in my experience had an issue with having too much documentation. In the sense that you get drowned in a 3000 pages PDF that lists every detail but becomes hard to parse unless you want to base everything around that specific platform for years. Though that sounds like an awesome "issue" to have in some circumstances.
It's been this way forever... They do distribute source (but last time I checked it is with incomplete build info). I think there is also some BS fine print about the licensing fee being for the provided header files.
That's such a weird thing to do. MPLab used to be completely free to encourage people to use their chips.
The GPL doesn't say you can't charge money for things. Do they provide patches for their changes to the source?
I think that the issue here is the following:
I've interviewed for a junior embedded software engineer when i was in university and when i started mentioning i had experience building cross-compilers i was immediately stopped by the guy interviewing me (he literally didn't even let me finish the sentence) and told me "Absolutely no. We don't want to maintain our own toolchain and we want everything to be coming from the BSP [Board support package] and integrated nicely with the vendor's IDE.They used ARM chips, so not even anything strange...
The real issue would come if they did not provide the source code for the gcc build they sell you, though.
Offloading the liability for a compiler sounds like common sense to me. How many heads did this company pay? 100, 1000?
Related, compiler bugs aren’t uncommon in the arm-none-eabi family. Especially the cortex m0 seems to have a few that recur every few years.
Token ring was old in 1996 when my masters thesis focused on error handling behavior and simulation thereof.
I wonder if there are certain elements in certain "industrial complexes" that need to maintain or interface with legacy TR systems and that's why it's still hanging around in "dark silicon".
The ideas behind token ring underlies DOCIS.
While not technically TR, it does use a token that moves from device to device.
It would be interesting to know if TR is better at contention management than broadcast ethernet - which nobody does anymore because everyone uses switches.
Off topic, but clabretro did a series on Token Ring if you want to relive the nostalgia: https://www.youtube.com/@clabretro/videos
What i know from the past is for realtime guarantees ethernet does not cut it. So you might be right.
AFAIK Ethernet is used for realtime audio distribution, so that can't be completely correct.
AVB and TSN are relatively new addition to Ethernet, and specifically designed for realtime AV use. Traditional Ethernet is not really intended for tight real-time use.
There is audio distribution real-time and nuclear reactor (or avionics, medical, etc) real-time. I assume the people doing (or certifying) the latter will want better guarantees.
There were still using it for the desktops at IBM when I was there in 2001, although they were starting to phase it out.
Microchip seems to be reasonably good at opening stuff up that it's bought from other companies; various Atmel security ICs which were previously very secretive now have full datasheets freely downloadable from their site.
This is amazing.
Oh, no wonder this is so comprehensive and fearless. It's Andrew Zonenberg.
I adore this series and other deep dives like it.
If anyone can suggest others I would be grateful.
This has generally been my experience of PHYs in general, lots of twisty passages all different
In perhaps a feat of nominative determinism, both the website and the feature are named serdes.
SERDES is an acronym, it means serializer / deserializer, in the same way that MODEM is modulator / demodulator.