This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Do I want nRF52 Serialization or Module or Hybrid?

I read this older post (devzone.nordicsemi.com/.../) and have a similar issue but with enough differences that I felt it was worth a new question.

I have an STM32 MCU and need BLE. I don't want to deal with FCC cert, so I'll be buying modules. This first specific project will always be a peripheral, I doubt I'll need central role in the future but like the idea. As I see it I have three main options if I stick with Nordic currently:

  1. Serialization of an nRF52 part. I set it to serialization and toil with trying to get the STM32 to do the work. I know nothing about BLE setup so this is intimidating. I'm running RTX RTOS on the STM, which goes to timing. I'll be responsible for all BLE spec.

  2. Buy an nRF52 module, have it run autonomously by itself. When the phone connects it handles all aspects in it's own code. STM32 can request and receive data over SPI/UART. This isolates the STM32 code from needing to know anything about BLE. The nRF52 would "assemble" the smaller GATT data into full meaningful packets. Nothing proprietary or important would be on the nRF52. It's a waste of the IOs, peripherals, and the processing power of the nRF52. It MAY be possible to farm this out. This appeals to me except for development costs.

  3. Buy a simpler module. I'm REALLY not crazy with the nRF8001 because of it's age and speed. I want decent throughput so the 1 packet vs 6 packets per interval is a factor. I looked over the code example for 8001 and wasn't thrilled with some aspects. For the most part, I'd be back to using the STM32 to handle the settings for BLE (which again, I know nothing about yet) in an OS thread. I'd have to do the "data work" and assemble locally on the STM32. The nice thing about this is if I have GATT requirements change, I can simply include them in the latest STM32 firmware update.

Thoughts and Questions:

  • I'll have 32-64kb firmware transfers. So I'll need a strategy of DFU and Flashing the STM32. It would be nice to have a comm processor offload this task of assembling and dealing with the phone/user.

  • The bluetooth comm will run rarely, user settings and firmware updates. I need very low power (under 1mAh) for the entire circuit in sleep mode; during use I have infinite battery.

  • No specific range requirements.

  • While I doubt I'll ever use this as anything but a peripheral, I'd like a module I can grow with. At the same time, I do not want to have multiple versions of the same product I need to support. I want to choose wisely.

  • The 8001/8002 are at least 7 years old now. It seems like I'd be shooting myself in the foot to deal with them now, not that Nordic will kill the module - rather that it simply can't be the best option.

  • I like that the nRF52 has OTA DFU, but I can imagine few scenarios where I'd want to update this code. If I have a solid setup that assembles packets, feeds my STM32 the GATT data, and is largely transparent to me, it may never need updates. That's the ideal scenario at least.

  • I'm only interested in phone to device. Aspects like increased throughput from BLE v4.2 won't matter as IOS doesn't support it (yet?). Same with NFC. I don't think the nRF52 would be utilized well, but no one has ever had too much power/ram/rom, right?

I'd be interested in any tips or past experiences. Thanks!

Related