I decided to update BUGGER status while we are switching gears between the projects and I have a few spare minutes to write this up.
The BUGGER finally got it's long promised nRF24L01 transceiver. Now we can control BUGGER with RFL robot remote. It's definitely fun watching this tiny four-wheeler buggering through cluttered table environment while you doing your best not to run it off the table. We also lowered the camera to reduce platform profile so it could squeeze into even tighter places for undercover missions.
On software side, we forgone using Arduino IDE to write code and used AVR Studio with AVRLib instead. The reason for this is that we found a nice nRF24L01 library
that works well with Procyon AVRLib
. And benefits of saving time on software development process under current circumstances tipped the scales towards non-arduino software. Great thanks to Stefan Engelke
and Procyon guys for creating and maintaining great software libraries.
A few words on nRF24L01 handling logic . The code monitors for logic change on PD2 pin. Once PD2 goes low, interrupt handler routine kicks in and sets global dataReceived flag signaling that we received data on nRF24L01 module. The routine also clears nRF data_received status register. During main program loop execution, the code checks if dataReceived flag was set and if it was it will go over SPI to retrieve the data from the transciever module. Now there might be a better way of doing the same thing but it currently works for the BUGGER so we will stick to it for now. The main advantage of this approach is that we don't need to pool nRF24L01 module for data every time we start a new loop, we will only initiate SPI transfer once we were notified by the transceiver about the 'incoming'. This approach should save us a few processing cycles so we could use them for some greater good. :-)
Here is a few links that we may suggest for your independent research in case your project needs some wireless connectivity and you are new to nRF24L01 module.
Pololu's Baby Orangutan controller is connected to nRF24L01 module using SPI pins. One of the intricacies about Baby Orangutan controller boards (green versions) is that PB2 pin that's used as Slave Select (SS) line in SPI setup is hardwired to run on-board LM1836 motor controller. This is because PB2 is also PWM-capable and it's needed for motor speed control.
So to circumvent this issue we used PD7 as a slave select (SS) instead. The pin needs to be toggled manually to simulate slave select logic. You also need to make sure to set up PB2 as an output pin in your initialization code so Atmega's SPI sub-system would ignore logic level changes caused by PWM oscillations on this pin. AVR SPI sub-system will transition into slave mode once slave select line (PB2) goes low. Now once you've addressed both issues, you should have a working SPI sub-system on your Baby Orangutan (Atmega 48/168).
After we had SPI hardware issues resolved, we moved on to digging through open-sourced Active Innovations' RFL remote firmware. The experience was a breeze since fellows from Active Innovations did a great job writing and documenting the code.
A few key points on how to initialize your nRF24L01 module so it can capture RFL remote output. nRF24L01 is configured through registers. Here is key values that we used to get it initializes correctly.
// RFL remotes use special demo channel - 7 for new remotes, regular operation channel is 10 or 120
#define mirf_CH 0xA // using RF channel 10
#define mirf_ADDRESS 2 // default address
#define mirf_PAYLOAD 10 // payload length 10 bytes
// Enable CRC, CRC encoding scheme - 2 bytes
#define mirf_CONFIG ( (1 << EN_CRC) | (1 << CRC0 ) )
Connecting nRF24L01 to DEV-32 board is straight forward and doesn't involve any trickery. The board doesn't contain any extra hardware and no pins are committed to specific functionality. Please, refer to the diagram for details.
More BUGGER pictures...