Terminal for SPI communication

[Magnus_K]

Hello,

I'm a complete beginner to Raspberry Pi and would like to ask for an advice how to set up my SPI communication.

The module I'm trying to talk to is a CC1101 radio module and I'm looking for a good 'interface' between me and the module.
Is there any kind of program for the Raspberry Pi in which I can enter 1-64 byte and send with SPI to the module. Then get the reply presented in the same window? Like a terminal for UART but for SPI?

Thanks in advance.

[mfa298]

I'm not sure there's any spi console as such, however spi is fairly easy to interface with from most languages. You could probably get a form of spi console with an interactive python or ruby session.

[wayne.dolesman]

When you say you want to send 1-64 byte what exactly do you mean?

A series of bits 1-64 bytes long? (eg 8-512 bits)
The byte value 1-64? (eg 0x01 - 0x40)
Something else?

I could do a simple SPI console app in python but I would need to know exactly what is being sent.

[Magnus_K]

I'm not sure there's any spi console as such, however spi is fairly easy to interface with from most languages. You could probably get a form of spi console with an interactive python or ruby session.

Yes console, that was the word I was looking for. I've found some libraries 'out there', such as wiringPi, but no console types.


@wayne.dolesman:
Sorry for being unclear. I want to send a series of bits, 8-512.
If I understand the datasheet correct for the CC1101 the config register is 64 bytes and also the FIFO (TX/RX register) is 64 bytes. So by having the possibility to send/receive 64 bytes I can R/W the complete FIFO or 'burst write' multiple config bytes at once.
Of course I'd be more than happy if could give it a try.

I know there is one more issue with the communication but I will try to ignore that for a start. When CS for the CC1101 is pulled low you're supposed to wait until the CC1101 pulls the MISO line low before transfer of data. This is due to an oscillator stabilization period etc.
My thought is to just pull CS low and then insert a delay before start transmitting the data. In accoordance with the datasheet it should be well enough with ~500µs.

[KnarfB]

There used to be a command line utility spidev_test.c in the kernel source code. You can download, compile and test it easily.
Form a command shell enter:

Code: Select all

wget https://raw.githubusercontent.com/raspberrypi/linux/rpi-4.4.y/Documentation/spi/spidev_test.c
gcc -o spidev_test spidev_test.c
./spidev_test -h

Of course, SPI must be enabled in config.txt and the SPI device(s) must be present in /dev/spi*

If SPI pins are configured correctly (check with gpio readall) to can test SPI function with commands like:

./spidev_test -D /dev/spidev0.0

hth

Frank

[wayne.dolesman]

@wayne.dolesman:
Sorry for being unclear. I want to send a series of bits, 8-512.

Ok, well the console terminal app is actually fairly easy and generic. That I have below. The spi specifics I didnt do yet because I wasnt sure how it was going to be done. I have attached the app - although for sending bits its not as user friendly just yet because it expected an integer 1-64 so that needs some cleanup.

If I understand the datasheet correct for the CC1101

I tried getting that from Tis site but I think my browser needs to be restarted for the pdf to load. I literally have 100+ tabs open right now due to various projects and I did not want to do that just yet

I will see if I can look at it and use spi_xfer() to send the bits. The way SPI works more or less is send a byte receive a byte. Even if the received byte is just an ACK and has no other value you must still receive it. This is not terribly complex and there are at least 3 libraries I am aware of that deal with sending data.

the aforementioned console app generic wrapper to give you an idea of what I am talking about so far (it runs if you want to test it for suitability). Obviously it needs tweaking now that I have clarification on 1-8 octets being sent but the general flow/usability will remain unless directed otherwise.

Code: Select all

#!/usr/bin/env python

def send_cmd(cmd):
    print "Command "+str(cmd)+" sent"
                

try:
    while True:
        cmd_string = raw_input("Command, 1-64 :")
        try:
            cmd = int(cmd_string)
            if (cmd > 0 and cmd < 65):
                send_cmd(cmd)
            else:
                print "Command must be between 1 and 64"

        except ValueError:
            print "Command must be numeric"
        
except KeyboardInterrupt:
    print "Exiting..."
except:
    print "Aborting"
finally:
    print "bye bye"
#    GPIO.cleanup()

[joan]

pigs will do this for you.

man pigs # for help

SPIO c b spf - SPI open channel at baud b with flags

Typically pigs spio 0 100000 0.

SPIX h bvs - SPI transfer bytes to handle

Typically pigs spix 0 0 1 2 3 4 5 6.

[wayne.dolesman]

This radio is a bit more complex and a simple terminal probably wont work the way you want it to. Just initializing the radio to get it to go into Tx or Rx mode requires quite a few steps. Setting the frequency requires 3 writes after doing some math. An interface library is the way to go for this bad boy.

Fortunately I started one. The datasheet is really helpful, massive but helpful. https://github.com/Nom-DePlume/libCC1101

Just the initial commit so far, but it can turn the radio on, set the frequency (although I do NOT set some other things I need to in order to make it work such as the state machine inside the radio).

I do have a link in the project readme to my amazon wishlist which contains one of these radios ($7 or so). As a poor student I cant spare that. It would make writing this library much easier since I have no real way to test my code right now.
/begmode

[Magnus_K]

Wow, what a fantastic response, thanks everyone!

I will go through each post at the time and give it a go. I'm afraid wayne.dolesman is completely correct about this harder than it looks.

[mfa298]

Wow, what a fantastic response, thanks everyone!

I will go through each post at the time and give it a go. I'm afraid wayne.dolesman is completely correct about this harder than it looks.

For talking to a radio module it probably makes more sense to try and use it within a programming language rather than sending spi commands from the command line.

Do you have much programming experience - which languages ?

[Magnus_K]

Unfortunately I don't have much programming experience. Maybe some C while programning PIC microcontrollers, but at a very basic level.

I was hoping that by doing the communication manually, at a start, it would make life easier when moving over and make it with code instead. But I'm probably wrong about that as well.

[wayne.dolesman]

Unfortunately I don't have much programming experience. Maybe some C while programning PIC microcontrollers, but at a very basic level.

I was hoping that by doing the communication manually, at a start, it would make life easier when moving over and make it with code instead. But I'm probably wrong about that as well.

If you look at the test program that I have done so far (its far from complete) it shouldnt be that hard to figure out what you need to do to make it do what you need. If you have ANY programming you should be able to grasp what is going on quickly. It is python but its not so dissimilar from C that its unreadable.

from https://github.com/Nom-DePlume/libCC110 ... er/test.py

Code: Select all

...
cc1101.setFrequency(433e6)
cc1101.enableRx()

The names are obvious, the only thing that isnt immediately obvious might be the frequency. 433e6 is the same thing as 433,000,000 (e6 - scientific notation or *10^6).

Setting the packet radio up, reading the Rx FIFO buffer, filling the Tx FIFO buffer should be similarly easy. And once enough of the library is done it should examples could be made that do what you want to do.

For example one script could do APRS to send/receive messages, be a beacon transmitting location, whatever. Another could do garage doors or read power meters or whatever else (my power meter is not encrypted until it hits a phone line per the manufacturer - that includes the kill/shutdown command )

[mfa298]

Unfortunately I don't have much programming experience. Maybe some C while programning PIC microcontrollers, but at a very basic level.

I was hoping that by doing the communication manually, at a start, it would make life easier when moving over and make it with code instead. But I'm probably wrong about that as well.

I'd go for doing it in a script, ideally using/writing a library as Wayne has started to do. Python is probably the easiest way to start.

For basic testing just putting the set of commands into a script is probably better than just sending commands from a command line. I started doing something like that for a different spi radio module (rfm69). My original attempt for that was https://gist.github.com/m1ari/11190249 the advantage of writing it in a script is you can easily change a single parameter and then re-run everything (rather than trying to remember all the right commands in the right order)

[wayne.dolesman]

Added more code. It is still not fully functional, but its getting there. I am just going page by page in the data sheet adding functionality. The test.py program is similarly being updated to show how to use the new features.

https://github.com/Nom-DePlume/libCC1101

Pull requests welcome.