PIC, SPI and the RFM12

I finally had some time this weekend so I started the hardware verification, mainly getting the PIC and the RFM talking together via SPI, of which I have had no previous experience.  The PIC is receiving it’s clock source from the RFM12 via the CLK pin so I dont need any external Xtals.  The RFM12 default clock rate on reset is 1MHz, so the first challenge is to change the speed of the RFM12 CLK to 10MHz, that way I know the PIC and RFM12 are talking.

 As I’m doing most of my software development with BoostC (http://www.boostc.com), there is a library to use the on-chip MSSP (SPI and I2C) functions of the PIC16f873A, so I thought I’d use this and the on-board SPI functions to handle all SPI communications to the RFM12, after a very frustrating few hours and with my scope monitoring the SPI pins, I finally got the SPI to spit out proper CLK, SDO, and receiving something back on the SDI line after I realised I had not had my interrupts enabled to allow for the non blocking SPI functions DOH!

Now that something was getting out and back in, however none of the commands I sent seem to be getting through, well at least not interpreted as commands by the RFM12.  After much head scratching and re-reading of the RFM12 SPI timing diagrams It occurred to me that the 16bits that make up the the RFM12 commands were getting send through in byte sized chunks, i.e. 8 bits at a time were being sent through, then the next 8 bits were send with a delay in between the two bytes, this makes sense as the internal SPI uses an 8 bit register that gets transmitted, although the library I was using allows from the transmit of any number of bytes via a buffer.  I figured this was the problem and quickly wrote some bit banging SPI functions to test the theory, and straight away the RFM12 responded to my commands and now I have the PIC running at 10MHz.

So now that  all is working in the land of Oz as far as my PIC and RFM12 and talking to each other it’s onto finishing the RFM12 library I started last week and testing that with the RFM12 Demo board so I can test Tx and Rx functionality without having two development boards set up.

RFM12 Demo Board

Similar Posts:

Print Friendly, PDF & Email

Author: Stephen Eaton

Geek at heart. Loves to tinker and find out how things work, which inevitably leads to items in pieces and not working for much longer :)

3 thoughts on “PIC, SPI and the RFM12”

  1. As a side note I will be re-visiting the SPI library and it’s timing down the track, as the problem with the bit bang functions is they are blocking, i.e. I can’t do anything else until everything is send. The SPI Library uses non blocking functions to do the sending and receiving.

  2. Hi,

    I’m working on project with RFM12B and have been wandering in the dark for 3 days now.
    It seems I that transmitter is working as receiver changes it’s status, but i can’t get and data through.

    The status of receiver in idle state randomly toggles between 0x0200, 0x0220 and 0x0260. If receiver is active this status changes to 0x03DF or 0x03EF (last byte is changing value).

    The transmitter status randomly toggles between 0xA100 and 0x2100.

    I would like to know you get similar status on Rx/Tx side?

  3. Hi,

    It might be best to move this to the forums (http://forums.everythingrobotics.com/ )as I’ve set up a topic dedicated for the RFM12 as I have been getting a few questions.

    When you say the receiver status are you sending a status command, 0x0000, and reading the result?

    I have working code in SVN located here: http://svn.everythingrobotics.com/strobist/mk1/trunk/arch/pic16f88-boostc/src/

    The test_rfm code sends out a string of data on the TX and the Rx receives and lights up led if all good. Code is fairly well documented and the RFM12 library works in polled mode, will also give you base configs to get started, although its the 915MHZ band it should work on 433MHZ

    A couple of things to check:

    1) Before you turn the receiver on are you resetting the FIFO?

    2) If you are using SPI to read data from RFM then make sure you set the fifo to interrupt on 8 bits, that way when you read a status on the reciever the first bit is the receiver interrupt, if this is a 1 then a valid character has been received and then you can read it via the FIFO read command.

    3) When transmitting make sure that when you send out your packet make sure preamble is min of 3 bytes then sync code then your data. Also make sure that there is no interruption or pause in the process, if there is then receiver will loose sync after certian time and you need to repeat the sync process.

    4) When transmitting are you checking the status of the TX register interrupt? it is the first bit of the 0x0000 status when in Tx mode. Only when it is 1 can you write the next byte to the Tx register. What I do is write the first two bytes into the Tx register, turn on the Tx then monitor the status bit, write the next byte and so on then when I’ve transmitted my complete packet I then write a couple of preamble bytes to the Tx register and turn off the TX. so that way the Tx register is flushed before I turn off the TX

    5) make sure when turing on Tx or Rx that you allow for timing for tx/Rx to settle before transmitting. These are in the spec sheet as I can’t remember off hand what they are. i.e. if you are turning on the whole Tx/Rx chain then it takes longer to stabalize than say having the oscillators etc are already enabled and all you are doing is enabling the PLL etc then it’s a very short turn around time.

    6) As its in unlicensed band there will be interference around, try changing frequencies.

    7) Start with a datarate of 9600bps to get it all working then change speed to the required datarate once you are getting successful Tx and RX.

Leave a Reply