Fun with nrf!2010/09/25
So for the past while I’ve been trying to bootstrap some boards based on the various Nordic Semi nrf24 chips, in order to build a wireless program&debug setup for the product I’m working on. Early on it took a lot of work to convince the SparkFun nrf24l01+ modules to talk in the first place, due to a lack of really understandable documentation, tutorials, and example code. I really ought to write something up myself that’s more coherent, if I can get it fully straight myself.
However, the most recent struggle has been getting the nrf24lu1+ to work. The difference is that while the nrf24l01+ is nothing but the radio and has to be interfaced to an external microcontroller, the nrf24lu1+ is an 8051 microcontroller with both a radio and a USB interface on-board. This is great and all, but I’ve got all my toolchain stuff set up for the AVR/Xmega…. That means coercing SDCC into working, straightening out the register file, getting things linked, and overall understanding the ins & outs of the 8051 microcontroller (which sucks, BTW). Then once I have a firmware file, I’ve got to program the beast. That involved writing ioStack code running on my ATXmega256A3 “spider” that could speak the appropriate SPI commands to the chip (after getting it both reset and in programming mode), as well as writing a protocol layer on top of that that mimics the protocol the USB bootloader uses. Finally, the actual programming code on the PC has to load up the IHX file (which coming from SDCC is an abomination) and do things in the right order.
Once I got actual code running on the nrf24lu1+, it took another painful chunk of work to port the general nrf24 code over to it. The interface to the nrf24 is a “soft” SPI port, which bears very little resemblance to an actual SPI port. The biggest “REALLY???” moment came when I finally found in the SDK that there is indeed a “transfer complete” bit, but it’s never referred to anywhere in the “internal SPI” section… I’m finding the 8051, and particularly Nordic’s implementation, to be a really unpleasant thing to work with. It’s making me appreciate the Xmega even more than I already did…
I still have to get a radio protocol figured out that makes ioStack work with multiple end-points, and I still need to figure out why my “bit-bang” PDI interface isn’t behaving right. But when I get those two working, I should be able to both program and debug an Xmega target wirelessly, without Bluetooth going braindamaged about every 5 minutes.