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.
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 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.
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.
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 packages ranging from QFN-32 to 100-ball 0.5mm BGA which gives a nice range of IO densities.
* H735 for the main processor in a complex design (the kinds of thing most people would throw embedded Linux at). I frequently pair these with an FPGA to do the heavy datapath lifting while the H735 runs the control plane of the system.
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.
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 to abandon ST altogether after losing so much time on a design to undocumented bugs and parts not behaving as documented.
I haven't been bit by an undocumented silicon bug, but I step on documented STM32H7 bugs on a pretty regular basis and there are some poor design decisions around the OCTOSPI (in addition to bugs) that make me avoid it in almost every situation.
But at least they document (mostly correctly) the registers to talk to their crypto accelerator unlike the Renesas and NXP parts I looked at as potential replacements, both of which needed an NDA to get any info about the registers (although they did supply obfuscated or blob driver layers IIRC).
I'd love to hear stories of what it's like to work with chips from these companies.
If you're working at one of the big companies (e.g. Microsoft), they'll give you access to the documentation and source code that should be open for everyone, but even then you're going to spend time reverse engineering your own documentation because trying to get details from them is a months long process of no one being willing to say yes. It's painful. Best to stay away unless you have no other alternatives.
For larger volumes, ~100,000 you get to talk to a distributor yourself and design your own pcb. You still won't get to talk to anyone at BigSemiCo, but you will get access to datasheets and (probably) drivers. You will have to sign an NDA.
For their largest customers, they go all out. The customer gets significant input into the design roadmap years in advance. They can get cost-reduced versions of existing parts that leave off blocks they aren't using. reference board designs and example software are provided (to the extent that low-margin, enormous volume customers sometimes just change the html logo and ship). If the product needs integrating, Field Engineers will be flown out to assist.
There are some levels between these last two, where they will talk to you but not invest as much.
Take the above numbers with a pinch of salt; it's been a while since I was in that industry
When I first started the project in 2012-13, Vitesse was just as NDA-happy and I ruled them out. The original roadmap called for a 24-port switch with 24 individual TI DP83867 SGMII PHYs on three 8-port line cards.
I poked at a vsc73xx-based switch in the past and wrote my own test firmware, but had problems with packet loss since I didn't do all the necessary phy initializations I guess, in case this might be of interest: https://github.com/ranma/openvsc73xx/blob/master/example/pay...
Also on the device I had the EEPROM was tiny and the code is loaded from EEPROM into RAM, you were pretty much stuck with 8051 assembly that had to fit into the 8KiB of onchip RAM :)
I've yet to see anyone here talk about silicon labs microcontrollers. Why's that?
I do remember trying different browsers and even different machines, to no avail. Quickly gave up.
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.
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.
Dealing with small clients is not a priority for most part vendors. Many of them won’t even sell you chips at all until you can qualify yourself as a big customer or, in some cases, buy a license to start designing with their parts for six figures or more.
Unfortunately for the small players, it’s not a priority for most companies to support small customers who might only buy a couple thousand parts or less.
If you want to sell or limit support, why not do that without the documentation complications?
Yes, absolutely. Notoriously, smaller customers are more needy in fact. The bigger the customer, the more competent their engineers tend to be (or, the more time they have to spend figuring out how to use your stuff). Smaller customers try to offload support onto vendors, which pushes burden onto internal vendor teams (who don't want to provide the support...).
Maybe. The other thing is that public documentation gets a lot more scrutiny than internal documentation. You don't have any resource to talk to, so something like typos or mistakes need to be corrected rather than just papered over by a helpful applications engineer.