On STM32 you typically need to go to STOP mode (called deep sleep in places) to get significant power savings. I had F0 and G0 waking up at 100Hz plus on pin interrupts (with maybe 30us latency) consuming 50-100uA (compared to maybe 20mA without sleep). I’m pretty sure you can do better on the WB since it’s actually a low power part, but it all depends on how complicated your software stack is. For example, to get the low latency wake up required only using the low level HAL and custom clock configuration.
Nordic parts are easier - they actually have low power sleep that is fairly automatic.
> Nordic parts are easier - they actually have low power sleep that is fairly automatic.
Came here to say this. Started with the STM32WB5x for a BLE project but got so frustrated with it so I switched over to NRF52. Never looked back. I love (and use) the STM32x for many other applications but the STM32WB BLE-solution is just too opaque with the (close sourced) BLE stack running on the secondary core while still requiring a lot of low level collaboration from the main application core. Would have been a lot easier if was more isolated and just provided a standard HCI interface or something. I suppose one could argue to use a dedicated BLE IC in this case.
Anyway, I'm very happy with the NRF52 I'm using. The events, tasks and peripheral interconnects is also a really nice feature. Documentation is stellar as well IMO. My main gripe with it is that it only comes with one UART port. Two would have been nice. Perhaps the NRF52 successors comes with more. Haven't checked really.
Nordic parts are easier - they actually have low power sleep that is fairly automatic.