Baremetal Drivers: RFM69HCW and FRDM-K22F

Writing register level code is something I have always viewed as both a blessing and a curse. The blessing is absolute control over almost every aspect of the system while the curse is trying to understand all of the system requirements at the lowest level.

As I have previously mentioned I am working on a micro-satellite prototype for my senior electrical engineering design project. My role in the project is the communication system. I was required to select and setup the hardware and software to be able to transmit data from the satellite to the ground station with handshaking and error correction. 

HopeRF RFM69HCW Transceiver Module
This is the transceiver chip that we decided to use. It is surprisingly inexpensive considering the features it includes. The version we are using is the 915 MHz model (ITU ISM band in the Americas) to avoid having our own spectrum license or to have to request usage of an amateur radio band. 

One of the instructors in the course is refusing to let groups use any tools that makes the software design easier. This removes the possibility of using things like Kinetis Processor Expert or ARM Mbed. This forces us all to develop our own baremetal drivers for nearly everything.

The project started with simply getting SPI to work. I had a conceptual understanding of how SPI works but the gritty details were something I was not  familiar with. I first considered using an Arduino to setup SPI so I could get some practical experience but the configuration was so highly abstracted from the hardware that it wouldn't have been much help.


Say hello to the FRDM-K22F. This board has been rather frustrating to work with but not due to NXP (Freescale)'s fault. A slow clap for Microsoft as they have Windows 10 brick the on-board K20 whenever you try to read/write to the board. I found this issue to be an excuse to use my linux partition more frequently which has made me SO sad. There is (was?) a service on Windows 10 where it will try and manage the board's memory. It decides to have a hissy fit and die.  

After getting past the initial hump of SPI drivers, the task of trying to setup the RFM module to be able to transmit and receive was the next mountain. The documentation for the RFM was surprisingly readable but the complexity of programming it was still relatively high. 

There are many different modes of operation (transmit, receive, sleep, standby, listen, etc.) and what feels like a thousand configuration registers and flags. To make matters worse, there is many ways to perform the same task. Reading a flag could be done through an external pin (see 0-5 on the board above) or by reading the register and masking the result for the flags you want.

After many, many, many hours I finally got a baremetal SPI driver working and then the driver to use the RFM69HCW. I have also managed to transmit an image across a room which is a major relief. The camera resolution we are using is relatively low at this time but it is on the list of things to do before the completion deadline.

Excuse the selfie quality but success just felt so good to have it working.

Successful image transmission

If you have any questions about the hardware or software I will happily discuss it with you.

Comments

Popular posts from this blog

Data Processing: Matlab, Python or Octave?

Ongoing Linux Cheatsheet