raspberry pi and propellor
Patrick222122
Posts: 30
Has anyone got a propeller and a Raspberry pi to communicate with each other yet. I have tried several methods myself and have not succeed. First I tried usb using libusb for c with no success. Now I am trying serial using the pi inbuilt uart port. If anybody has acheive what I am trying to do, please reply with detailed instructions on how
Comments
You should tell us which programming language you want to use on the RasPi. Anyway, here is an example in C: In other languages it should be similar, you simply have to open device /dev/ttyUSB0, set it to the same transfer-Speed as the propeller-code and send/receive whatever you want.
Here is the Propeller code:
Everything has been tested with a Raspberry and a Quickstart. The stuff has been compiled on the RasPi and the Software has been uploaded to the Propeller by the Pi. I have to search for the thread where I uploaded Compiler and upload-tool.
The read/write functions take the address to an array of bytes as a the data to read/write and a length parameter.
The & gets you the address of whatever variable, in this case the address of the ch byte. The length is sizeof(ch) which is one.
Note the name of an array is a pointer in C. So writing &someArray[0] is the same as writing just someArray.
I have not had any problems using serial comms to the Prop in C or other languages.
I have also used the UART on the GPIO port. Which is /dev/ttyAMA0 although to use that nicely it's best to stop Linux using it as the console port first.
We also have propgcc running on the Raspi if you want to develop on the Pi, no PC required.
I have a customized propeller loader that uses the on board UART if you don't want to mess with USB Serial adapters.
So, this code of course only gives you the basics.
You should come up with concrete questions rather than asking for unspecific advice.
High level only means it supports the propeller, or does it mean in the end the raspberry will be the brain? In other words, who is going to be the master?
The point is, that I'd implement something like a command-loop on the slave-side. As long as there is no problem with transmission-speed, I'd always send commands and parameters in ASCII-text, because then you can "listen" on the transmissions and see what is going on. This of course needs some conversion routines which converts for example longs into strings and on the other side you have to convert the string back to a long, but you can also test the stuff with a terminal program first.
Heater where's the best place to look for information on the Raspi propgcc and customized loader? Have you considered sending a brief writeup to TheMagPi magazine?
Edited to add - it would be cool to support RISC OS as well. The basic on there lets you mix a nice basic with ARM assembly.
http://forums.parallax.com/showthread.php/141469-SimpleIDE-for-Raspberry-Pi-Raspian
Here is a thread describing how to build propgcc on the Pi:
http://forums.parallax.com/showthread.php/141428-propgcc-builds-on-Raspberry-Pi-!!
And here is one re: the SimpleIDE build on the Pi:
http://forums.parallax.com/showthread.php/141429-SimpleIDE-builds-on-the-Raspberry-PI-!!
A ready made package with SimpleIDE and propgcc linked from the first post in this thread:
http://forums.parallax.com/showthread.php/141469-SimpleIDE-for-Raspberry-Pi-Raspian
I did think about a little note for MagPi, perhaps if time permits.
I suspect building propgcc under RiscOS might be fraught with problems.
I finally received my R2.0 Raspberry pi's about a week ago - really neat little boards.
Hello MagIO2,
Thanks for posting your example! I was just getting ready to try something similar and your example should give me a head start.
Robert
Robert
You already added a FullDuplexSerial to your code. The Problem is, that you use it without initializing it. If you would initialize it to use the USB Connection you'd have a Problem with the USB-object, because it is also using those Pins.
setSer /dev/tty/USB0
Assuming your port is USB0.
It does not matter.
If you have only one USB serial device plugged in it should be USB0.
To be sure use the command "lsusb" and it should tell you what is what.
It looks like you do not really understand the code. And I think I gave you a work in progress or a "stop improving because I checked what I wanted to check with it"-version. Well ... let's explain:
argc is the number of arguments you pass when calling the program, so the if checks that there is a parameter (besides the program name itself). If you don't give a parameter, you see the usage-message.
If you give a parameter it is copied as a string to the port-array. This is what you do when you plan to allow calls without parameter and want port to be defaulted to something. This is the part which seems to be unfinished, because when opening the serial interface in any case the hardcoded /dev..USB0 is used. This means that in fact it's currently totally irrelevant which parameter you pass, as long as you pass one.
You can fix that as an exercise if you want ;o)
The code itself is only reading a byte and sending it back. If 1000 bytes have been received you'll see an output.
Now to the propeller code I wrote: It waits for 30 seconds and then starts sending $a5. The other COG is receiving and compares the incoming byte with $a5. When there is a difference, it's counted and the counter value is written to the quickstart LEDs.
somecommand par1 par2 par3
Then the main() function gets parameters argc and argv.
argc is is the number of command line parameters including the command itself. So in the above case argc will be 4.
argv is an array of pointers to strings. Such that:
argv[0] is the name of the command itself. In this case "somecommand"
argv[1] is the first parameter. In this case "par1"
and so on.
In the case of the program under discussion, argv[0] is the name of the program, argv[1] is the serial port path and argc is expected to be 2.
But perhaps you should come back to that when you have everything you want working from the command line first.
You don't have to use argc and argv if you don't want to. For testing you can hard code the values into your program instead of reading them from the command line. Once it is working you can either leave them hard coded or you could store configuration items in a file and just read the file when your program starts to get the name of the USB ports to use and any other configuration you want to change. Keeping those items in a separate file helps if you want to change them since you won't have to re-compile your program to change them.
$ ls /dev/tty*
Should show you the /dev/ttyUSB0 device file.