3 ms·
I used Nordic SDK's for years and didn't like them. There were many problems: - They released new versions often, and they were tied to new versions of the ha
by rapjr9 6y ago
I used Nordic SDK's for years and didn't like them. There were many problems:
- They released new versions often, and they were tied to new versions of the hardware. So you HAD to upgrade your SDK to use the new hardware. And they would drop support for the old hardware so if you wanted to be able to buy chips you had to upgrade.
- They changed the API's often which broke all my software. Not little changes either but major ones.
- They have lots of examples programs but the examples can't be combined. Want to use the interrupt handling example with the timer example? It doesn't work and you have to reverse engineer their code to find out why.
- The example programs are not updated until long after the SDK changes. Because the changes in API's are large the examples often don't work.
- Some features didn't work. We specifically chose the nRF51822 because it was supposed to be able to do simultaneous send and receive of BLE on multiple channels. Turns out that was marketing hype, the feature was experimental, and they didn't deliver a complete working example for years.
- The debugger was useless. It worked for simple programs but this chip is a real time system and turning on the debugger broke the real time operations. Often it didn't even work at all, returning random values for variable contents.
It's difficult to find out things like this when all you have is the spec sheets and forums to rely on. It's only when you get deep into the system you find them out. That's why developers often stick with one microcontroller forever; they know it inside out and all the tricks to making it work. I have a suspicion that some of the problems were intentional to get people to buy their development services.
Microcontrollers themselves are still stuck in the dark ages. Atmel introduced some positive changes but most MCU's are still really primitive and difficult to use. A 5000 page manual? You've got to be kidding! And critical changes to the info in the manuals is published in errata sheets? Unusable! If I turn on a UART why doesn't it default to a standard configuration instead of making me set bits in registers? Perhaps it would increase cost slightly but there should be much more standardized automation in MCU's and more should be done in hardware rather than requiring software. There should be autonegotiation of communication protocols. MCU design hasn't changed much in decades and is ripe for disruption.