Summary

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.

Deets

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:
https://github.com/LonelyWolf/stm32/tree/master/nrf24l01
for a few reasons:

• it is fairly minimal and stand-alone, and so didn't incur too much dependency hoisting
• it has a well-defined partition between the board specific stuff (for SPI, interrupts, chip selects) and the chip-specific stuff (functions for writing registers, etc.)
• if nothing else, it saves my the transcription of all the relevant constants, etc., from the datasheet

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

• the division between the board-specific stuff and chip-specific stuff strikes me as imperfect, because for example the chip-specific stuff presumes the existence of a single-byte-wise SPI transaction, and multi-byte transfers are synthesized from that in the chip-specific layer
• somewhat related, the lack of multi-byte transfers in the board-specific layer obviates the utility of interrupt- and dma- driven SPI operations, since as defined they are just single-byte
• there is no provision for chip generated IRQs; i.e., as implemented, handling of chip events (e.g. rx data available, tx completed, error) must be done in a polled mode in protocol layer code (there isn't really any protocol layer code in the library, per se; any 'protocol' is simple point-to-point operations made in the demo code in main())

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.

Next

Continue factoring existing library code and making needed modifications.