Group Actions
Engagement
  • Author Author: crosseyejack
  • Date Created: Date Created
  • Views 813 views
  • Likes 0 likes
  • Comments 10 comments
Related
Recommended

Forget me Knot - SPI Woes

crosseyejack

First sorry I've not been about. Work and family commitments have been killing most of my time :-(

 

So what have I been up to? After getting getting the RF Sockets working with OpenHAB I set out getting some wireless transceiver modules working with OpenHAB too. If I wanted an easier time I should of researched it more, but then again I've always like a challenge.

 

The modules I choice were the MRF24J40MA modules from Microchip. They are an SPI driven module and I thought I would easily integrated with the PI. Before I ordered them I did some quick Googling and some some code that got them working so I thought I wouldn't have too many issues. When I came to trying it myself though I just kept banging my head against the wall.

 

My plan is to use these modules to create my own wireless sensors/actuators. I easily got these modules talking to each other using some ATMega's and some Arduino code. But then I tried to port this code to the Pi I just couldn't get the thing to talk correctly. After a week of trying and failing I decided that my SPI skills still need a lot of work.

 

SO instead of scratching my head over this issue (for now) I decided to work around the problem. In the past I have successfully got the Pi to communicate with a microcontroller with both SPI and i2c, so I decided to use an intermediate micro to get the Pi communicating with the wireless module.

 

As the module uses SPI I decided to use i2c to talk to the Pi. So the set-up if currently set up like this:

PI <--i2c--> ATMega <--SPI--> MRF24J40MA.


The ATMega is running some Arduino code based of a modified version of KarlP's library for these modules.
KarlP's original lib

The modified version I an currently using

The Arduino Sketches I'm currently using

 

What I am doing for the MRF24J40_RX_Test code that is being used on the intermediate micro is waiting to receive a valid transmission from the MRF24J40_RTX_Test code, reading out the sender address, RSSI, LQI and the payload data and copying that into a buffer. The micro then sends a pin high which is connected to an interrupt pin on the Pi.

 

The MRF24J40_RTX_Test code reads an analog input from an Analog Devices TMP36 formats that data and broadcasts the data to the module connected to the micro attached to the Pi.

 

A piece of software running on the Pi waits for this interrupt, reads out the data, preforms some sanity checks, processes that data and hands that data off to OpenHAB via its REST API using curl. I have uploaded the software I am writing to do this to GitHub https://github.com/CrosseyeJack/atmega-rpi-openhab-i2cbridge

 

This software is nowhere near complete, but right now it can receive the temp reading and hand that off to OpenHAB. At the moment pretty much everything is hard coded, runs in the foreground and has debug messages all over the place.

 

My current plan of action if to to the following

  • Figure out how I want to transmit the data. The data is currently transmitted as <Pin Type><Pin Number>;<Value>; so for example the transmitter code transmits A0:18.7; using this method I should be able to break down what data is being sent (is the first char a A or a D? what is the number following the first char upto ":"? What is the data between ":" and ";"? Is there any more data being send after the ";" terminator? If so rinse and repeat.
  • Decide on how I want to store OpenHAB item mappings. Do I want to store such mapping in a config file with the application which I believe would be the easier way or should try and read the mappings from the item in OpenHAB? This is something I will have to ponder.
  • Modify the RX code so it has an incoming data buffer which I can write to from the Pi and transmit that buffer to a wireless module.
  • Modify the bridging software running on the Pi to create a named pipe so I can pass it data from OpenHAB or other programs which will be passed onto the micro to be transmitted out.
  • Modify the bridging software so its hard coded, but I need to decide on how I am going to store the mappings first.
  • Turn the bridging software into a daemon application (this is pretty easy to do, the code is already there I just need to trigger it)

Once I have got most of the code running on the intermediate micro I will move it onto the board that is also home to the 433Mhz transmitter used for controlling the RF Sockets. For now I am programming and testing using another Raspberry Pi.

 

With only a month left I think I am going to have to ask the Bosses if I can take a week off.

Not really go much to show you in the way of pictures, but here are breadboards I have using building this crazy concoction with.

image

And here are few screenshots of the bridging software running on the pi printing out its debug messages and the OpenHAB webUI in the background displaying the value.
imageimageimage

As always, feel free to leave any questions in the comments and I will get back to you. Gotta run out for a short while and then track back on with the bridging application.

 

Dan.

  • in reply to ipv1

    Sorry but Python just isn't the language for me.

     

    If I want to daemonise an foreground application (any application) and not add daemonise code in the application itself I could just call

    nohup /application > /dev/null 2>&1 &

    But I can easily fork the code into the background within the application itself. I plan to call my application from OpenHAB and not rc.local only because OpenHAB will call it late into its startup process, so helping prevent my application being triggered by the micro and calling the API before its ready. As for compiling, my app takes next to no time to compile and run. If compile time ever becomes an issue I could just cross compile.

  • in reply to crosseyejack

    OK...

    Well just take a look at python as well. No need to compile and lots of examples online. Wanna daemonize? Sure put it in the RC.local

     

    Will be waiting for a more detailed update.

    Cheers

    Ip

  • in reply to ipv1

    Sorry, this is where my Dyslexia kicks my ass. That short blog post still took me over 2 hours to write and I still didn't explain myself correctly, and this post isn't going to make much sense because I had a bit of a shitty day at work and needed to go and unwind at my local.

     

    ANYWAYS. On the Pi side of things I am using C/C++,because I spent a week getting nowhere writing my own code for the SPI bus for the wireless modules and I needing to get something done to present in a blog post I cut a corner and used wiringPi (http://wiringpi.com/) for interrupt and i2c (I do plan to roll my own code for these but I needed working code). For a HTTP Lib I am using libcurl.

     

    I'm using C/C++ because I know it and I and compile it into a single application which once I move it out of "debug" I can daemonise the code and have OpenHAB run it after its own start-up (atm I want it to give me as much information as I want).

     

    Once I have finished the "get stuff out of the micro into OpenHAB" side of things I will give the code a FIFO/Named Pipe so I can send data from openHAB (or other software) back to the micro which will then broadcast it to other devices (For Example: Hacking into the RF Sockets I have so I can have 2 way comm's with them).    

  • in reply to crosseyejack

    Excellent.

    What language are u using on the Pi? Python has an HTTP library and I thought of writing a script that runs in the BG and monitors say a SPI BUS. When data comes in, parse it and send it via the REST API to the PI. That's what I will try for my RPiSOC image

  • in reply to ipv1

    Well I'm already doing that but I'm just writing my own code for it.

    I had a quick look at firmata after you mentioned it and it seems to be designed to talk to the host computer over serial so it wouldn't solve the issue that I would have to use a USB-Serial converter as the serial port exposed on the GPIO of the Pi is being used by the EnOcean Pi. Maybe I'm looking at the wrong pages on the firmata website.


    <EDIT> I found another page that suggests I can use other ports to talk to and from the Micro. I'll have a deeper read of it later on this Evening (I'm currently at "real world" work).</EDIT>

     

    I'm making good progress on the code I am working on. It uses the i2c bus of the Pi so I can add it to my addon board I'm making without have to have a lead coming off it to connect to a USB port on the Pi.

     

    I am in the process of reworking it so it can handle multiple data points but I already have it receiving data from a wireless test set-up and handing that data off to OpenHAB.

    image

    Top terminal is my app getting a notification that the ATMega has data for it, getting that data over i2c, parsing the data and passing it over the REST API to OpenHAB. The webpage in the middle is a confirmation that OpenHAB has actually updated the value and the bottom terminal is the debug log output of OpenHAB accepting the data and storing it in to a MySQL Database.