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.
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.
Some research was done into existing projects. It's still not clear if I should attempt my own twist on a mesh networking protocol intended for mosh pits.
I am setting up for experiments with the nRF24L01+ modules, and 'Blue Pill' STM32F103 boards.
Deets
I did some initial cursory research. As expected, simply doing a web search on 'nrf24l01 mesh' yielded many existing projects, libraries, and other sundry mish-mash of mesh. Some standouts:
This looks like a very high-quality project. Maybe it will obviate my doing any work, but I need to review it more. It seems to be oriented towards being able to deploy nodes in an ad-hoc manner around the house, and have a self-organizing mesh evolve from that. That's great! However it does also seem to be designed for more-or-less fixed placement of nodes, rather than rapidly moving (which is fine for it's design intent), so I should look to see if that is an issue. I'll probably have to build it and try it out to know for certain. Also, it seems to be designed for a reasonable number of node for a home mesh -- 255 max, which is too low for my application. Maybe that's adjustable somehow. Lastly, there are distinct roles that nodes play, with routers and non-routers. This is quite common in mesh networks, but I was hoping to have the various nodes be a strictly peer-to-peer implementation.
Still, it looks like a greate project, and I will have to kick the tires with the firmware, regardless if I wind up using it in this application.
This is a library/project specifically for nRF24L01+ devices. It looks pretty stable. It involves a 'node' for tracking address assignment, which doesn't fill my heart with joy. Also, there is a 255 node limit. Still, the code is worth a look, I think. There will be something to learn, I'm sure.
While researching some general mesh routing topics, I came across an experimental protocol named B.A.T.M.A.N. Some things which caught my eye were the motivation to distribute the routing information in sub-graphs, rather than having a full topology graph stored anywhere. I think this sort of thing will be important for handling rapid local topology changes that are expected in the mosh pit.
This protocol is intended for use over IP and UDP, and talks about 'small packets' of 52 bytes, which is larger than the absolute maximum packet size of the nRF24L01+, so regardless of what it is, it will need some modification. Still, it seems worth further study.
In a more general sense, I came across several academic publications about current mesh routing algorithms, so I will need to familiarize myself with all of those, and their relative strengths and weaknesses. E.g.
OK, coming out of the library with my eyes glazed over, I needed a little break with some hardware. Regardless of what I'm going to do, I still need to have a board with a radio on it for experiments.
I did discover that I have 14 nRF24L01+ modules laying around. I've never used them before. I bought them on a whim thinking they might be useful someday, and I guess today was that day.
I need to have something to drive them, though. I have a pile of boards, but for this project I thought that I might use the "Blue Pill" STM32F103C8T6-based board. I have 4 of those on-hand. They don't have honking RAM/Flash, or particularly exotic peripherals, but since this is a research project focused on the networking, I think they will be well suited. If I can get the whole thing working in the 20 KiB RAM, then that will be 'good' relative to integrating the result into other projects of larger scale. (I don't know if I'll need 20 K -- maybe (hopefully) much less. However, these nodes will often have to function as the network's router, and that may impose larger working set sized requirements than a conventional TCP/IP client node. Maybe. We'll see.)
So, the first step, as usual, is creating a project. Fortunately, I had created a boilerplate 'BluePill' project for the STM32 CubeMX, so I start with that. I picked some pin assignments for the SPI to the radio, and a couple gpio for 'IRQ' and 'CE', and that's all I'm goign to hook to the module. I'll use USB CDC for any debug I/O to the board (when I get that far).
This also gave me an opportunity to finally try out the cheap Chinese ST-Link knock-off. It's really quite amazing. The radio is about USD$ 1, the microcontroller on board with connectors is about USD$ 2.50, and the ST-Link is about USD$ 3. Free shipping, lol. You just have to wait 4-6 weeks for delivery (an eternity now, but this was the standard expectation for everything in the 80's).
I configured the project, burned, and validated. So, now I have an initial testing node. I went ahead and ordered 10 more BluePills so that I can make at least a few nodes to play with.
A couple tips on using the ST-Link V2 knockoff:
it is an st-link v2. NOT a v2.1. There is a subtle difference in a feature, and if you select 2.1, you will likely get confused by it's not working
notice that the BluePill has 4 pins on the side for the SWD debugger port. In particular, it does not have reset (NRST). That pin does exist, it's on the edge, near the yellow jumpers, but you don't have to connect to that. What you do have to do is tell the dev tools to 'connect under software reset'. This means that there will be a SWD command sent to cause the processor to be in reset, rather than using the reset signal line. The challenge is that the project, by default, will choose 'hardware reset', which will cause the dreaded 'failure in lauch sequence' message. (and this message means nothing; a zillion things can cause that, this is just one of them) What you have to do is drill down into Debug Configuration..., then the Debug tab, then there is a button 'Show generator options' (the debug script file is dynamically generated). Click the button to show the goodies. The goodie you need is under 'Mode Setup', 'Reset Mode'. Select 'Software system reset'. Now it will use SWD commands to reset the board.
While you're in that dialog, on the 'Startup' tab, near the bottom is a checkbox 'Runtime Options' 'Set breakpoint at' main. I uncheck this. This simply always puts a breakpoint at the start of main, and I will do that explicitly if I want one there, thank you very much. Breakpoints are a precious resource on these chips. You get six max, and one is needed to facilitate single-stepping, so I don't want to waste one on 'main'.
OK, having gotten the board up and sanity checked the build system, now I need to test sending SPI to the radio, and hopefully making it do something interesting.
This project is to give me a sandbox platform for developing/experimenting with mesh networking. In particular, the goal is to end up with an uber-cheap, rapidly self-healing, zero-configuration mesh network that is intended to operate in spatially dense physical setting.
Deets
In a discussion with some folks on an unrelated topic, I had a stray thought regarding enabling the project with networking capability. Because that project was intended to be a semi-disposable semi-novelty item, I wanted it to be:
uber cheap
requiring zero configuration
able to function effectively with a large number of nodes in close physical proximity. 'Large' equals around 10k min, I think. 'Close' means around 1000 units in a 10x10x10 volume, I think.
be able to self-organize effectively when the physical relationships between the nodes were frequently and perhaps rapidly changing
I have long been enthusiastic about mesh networking, and years ago had considered designing in some ZigBee modules. It was as IIoT project for a commercial client, so the cost of the ZigBee modules was not much of an issue. It used GSM networking to the Internet, but I was hoping to have the site specific networking to be done via mesh, and just have one device effectively be the 'gateway' for the entire site. In the end, the client didn't care if every node has a GSM modem in it, so we didn't go the ZigBee route, and now I have a little sack of ZigBees waiting for the day they will swarm forth again. But today will not be that day. They're too expensive, and I think they are more intended for ad-hoc networks of semi-stationary nodes.
My first idea was to do InfraRed, but I quickly withdrew from that thinking because I suspected that line-of-site will be a bit awkward to maintain in a rapidly moving environment. So my thoughts then turned to radio. There are some stunningly inexpensive radio modules out there, and I thought I remembered I had a sack of Nordic nRF24L01 modules that I had never used. Those cost USD $1 each, so definitely fit in with the cost objective. If I can use them. But that's my first hypothesis.
Like any project, it behooves one to do some research first. If this has already been done, then why don't I avail myself to that existing work, instead of re-inventing (and quite possibly poorly) the same functional thing. I have a feeling there are a cornucopia of mesh networking projects out there, and maybe even many for the nRF42L01 specifically, since it is such a popular module.
Another task is deciding whether and when to publish the project. In some ways, I'd rather do the feasibility study off-line first. If the project just winds up finding something that already exists, then that's the end of the project, and there's not much to report. On the other hand, if I don't start creating logs immediately, then I'll lose some history and the project documentation will have a sterile, pre-fabricated feel to it, as if it was first born into complete and correct implementation, which as we know projects to not actually evolve that way. At least not interesting ones.
Another vitally critical task to which one must immediately attend is to come up with a project name -- ideally with a corny pun. Because this notional mesh network is intended to be used in a potentially densely populated and changing physical arrangement, this evoked in my mind a 'mosh pit' at a concert. So it was definitely going to be 'mosh networking'. Because one pun is not enough, I punned 'nyetworking', because... Well, I don't really know why other than that I was craving a pun. Maybe I'll wind up jinxing myself with that one, but I suppose I can change it later. So, it is hereby dubbed 'Mosh Nyetworking' until such time as I grow weary of it.
The next most vitally critical task is to have a nifty graphic for the project. I am not graphically inclined, and so I usually just use a stock photo of some representative component. But there isn't really anything of that sort here, so I'm going to annoy a friend to make something for me. There will be much eye-rolling, but I think I can persuade. Maybe beer will help. Maybe beer will help before I ask!
ziggurat29