nRF24L01+ Basic Smoke Testing

A project log for Mosh Nyetworking

My Attempt at Creating a Mesh Network Suitable for Mosh Pits

ziggurat29ziggurat29 07/08/2018 at 17:210 Comments


Simple low-level tests of the nRF24L01+ module on the 'Blue Pill' STM32F103 board were performed to validate that the uC peripherals were configured correctly, and that the attached radio is responding as expected.


Since I had more-or-less decided on using the low-cost Nordic Simiconductor nRF24L01+ radio, and the 'Blue Pill' STM32F103 board, the first step was validating that the hardware combination was working OK.  This meant setting up SPI, and communicating with the radio in some trivial way.  This in turn meant understanding the registers, etc., at least a little.

Before setting out writing my own 'driver' for the radio, I did a little research for existing ones.  This radio is not new, and is quite popular, so surely there is a plenitude of useable stuff out there.

I found several candidates, but ultimately liked the one from 'LonelyWolf' the most:
for a few reasons:

That being said, it is not 'perfect' for my needs, so I will be altering it a bit.  In particular:

So, there will be some factoring down of the multi-byte transfer code into the board-specific layer to faciliate interrupt and dma driven IO, and some IRQ provision once I concoct an architecture for that.

Also, since I'm planning to have DMA and IRQ support, I'm goign to implement a packet buffer pool that the 'protocol' layer will be using (i.e. 'getBuffer()', 'returnBuffer()', etc.), and this design may have some impact on the existing PAI definitions.  It's too early to know yet, since I'm still learning the chip.

In the meantime, I did get the extracted code (just two implementation files, and headers) integrated, and I did manage to verify trivial SPI communications with the chip.  I used the same method LonelyWolf's library used:  set the chip address, read it back, and validate that the setting stuck.  So SPI to the chip seems to be validated; yay!

Now, I need to do the rest of the factoring I mentioned above so that I can move onto considering the for that the protocol layer will take.


Continue factoring existing library code and making needed modifications.