NRF52 vs STM32 Development Experience

[jumper385]

Hey All! A mate and I are scoping out a suitable ARM based BLE SoC for a project. We've found the most viable options right now are the NRF52's and the STM32WB's. We have Dev kits for both options.

We've found that most people favor the NRF52's however, our experience with the SDK has limited our development . Additionally, we've got pretty good experience with the STM32 ecosystem .

We'd like to know why the NRF52's are so popular and what are the caveats of using the STM32WB series.

[Siwastaja]

Code: [Select]

Horror scale

<-- absolute horror                                                    absolute delight -->

N                                                                                           n
                                           S  s

Legend:
S = STM32 with libraries / development tools
s = STM32 bare metal from scratch with manual
N = NRF52 with the SDK
n = NRF52 bare metal from scratch with manual



I think NRF52 is the best MCU experience I have ever had when you don't touch the SDK even with a ten-foot pole. The peripherals and their interconnects are just well designed, documented and simple, and nearly free of HW bugs / brain farts. Maybe not as powerful as in STM32, but the generic event/task routing system compensates.

[uer166]

I found the nRF peripherals limiting even with the event system, but I certainly haven't used it at scale yet. STM32 is very usable both bare metal and with the Cube code generator. They're about equivalent pleasant-ness as Siwastaja's chart says, I've done both, but for production/release prefer the Cube/IDE way.

[Siwastaja]

I found the nRF peripherals limiting even with the event system

Do you have any specific example in mind?

Has served me well, but to be honest I haven't done much beyond timers, radio, SPI and some UART-based protocols.

In addition to the event/task routing, I like the idea how they managed to force people into using DMA by making it actually easier than not using DMA. So basically if you want to receive up to 10 bytes by SPI, you just put the address of the buffer and the length (ten) into the SPI peripheral registers and it just works, instead of mapping DMA channels and configuring DMA config registers and whatnot. Also easier than getting an interrupt for every byte and managing the buffer in software. Win-win.

[uer166]

Do you have any specific example in mind?

It was that slightly shoehorned BLDC application. I'm used to having a bunch of DACs, OPAMPs, comparators, separate good quality ADCs, ramp generators etc in STM32G4, but of course nRF lacks mixed-signal in a major way. You can still do a lot with it, but maybe not an interleaved SMPS or a dual motor controller.

Of course that's okay, it's a radio chip, not a true mixed signal job that a lot of STM32 are nowadays.

[janoc]

Hey All! A mate and I are scoping out a suitable ARM based BLE SoC for a project. We've found the most viable options right now are the NRF52's and the STM32WB's. We have Dev kits for both options.

We've found that most people favor the NRF52's however, our experience with the SDK has limited our development . Additionally, we've got pretty good experience with the STM32 ecosystem .

We'd like to know why the NRF52's are so popular and what are the caveats of using the STM32WB series.

Depends on what you want to use it for.

Nordic chips are great for anything radio (BLE, Zigbee, Shockburst, anything except Bluetooth Classic and Wifi, basically) related, their documentation is great and Zephyr has a first class support for them.

STM32s are better if you need some complex peripherals e.g. to drive motors and such. NRF52 peripherals are rather basic in comparison but probably more than adequate for a lot of things. And one can always use a second MCU ...

[Siwastaja]

Do you have any specific example in mind?

It was that slightly shoehorned BLDC application.

Yes of course, I remember the discussion, just tend to forget about names and mix up people...

Indeed the analog features are lacking.