61–70 of 103 posts
- a family guide describing all features of microcontroller family, usually >500 pages long
- concrete microcontroller guide describing specifics of a single microcontroller, usually >50 pages long
- errata guide describing all(?) known silicon bugs with their workarounds
Also, Clang has a backend for MSP430 by default: `clang -print-targets`
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.
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 so…
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 tooli…
I also really like ST. At a previous job our go-to processors were Nordic for wearables or anything that needed BLE, and STM32 for pretty much everything else. Wasn't unusual to have an STM32 for all the peripheral I/O and an nRF52 hanging off an I2C port just to talk to an app.
Nordic is OK. Starting up a new project is nowhere near as easy as STMCubeMX and they do tend to update their SDKs frequently which can be annoying if you have to support legacy projects, but we used them for years with no problems.
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.
Why though? This is clearly a problem I just don't understand what the vendors are getting out of it.
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 tooli…
Earlier quoted context omitted.
I really like the STM32 ecosystem, but you have hit the nail on the head - there's too many variants. You really don't need 200 variations of a basic M0+ part, and having all those SKUs hurts availability because you're playing roulette when it comes to what will actually be in stock when your CM goes to order parts.
I did not like that part of it. Personally I've standardized on just three STM32 parts: * L031 for throwaway-cheap stuff where I'm never going to do field firmware updates (so no need to burn flash on a proper bootloader) and just need to toggle some GPIOs or something * L431 for most "small" stuff; I use these heavily on my large/complex designs as PMICs to control power rail and reset sequencing. They come in packa…
This is the approach I took at my last job: we standardized on a small handful of CPUs selected for a certain level of complexity. Before this, choosing a CPU was an agonizing task that took days and didn't add a lot of value. The only time it actually mattered was the one time we got an order of several 100,000 units. In that case, you want to get the BOM cost as low as you can.
Trying to get the same thing implemented at my current job. I'm seeing the same behavior where a team takes forever to choose a processor, and a "good enough" choice would have taken a couple of hours.
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 so…
Ran into this at Google. Qualcomm compiler for their DSP was an expensive branch of GCC. I asked my manager if we could just ask them for source instead of paying per-seat license. He said that “ our contract with Qualcomm specifically prohibits us from asking them for the source of this compiler”. They found the workaround tor GPL I guess.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 tooli…
> The only vendor I actually enjoy working with to any degree is ST, and only design boards using their uC's for that reason. ST has good documentation most of the time, but for a while some of their higher end MCUs had a lot of weird bugs and errata that were simply not documented. I haven’t used any of their modern parts recently but I’ve heard the situation has started improving. I have some friends who were ready…