P1<--Raspberry Pi
Rsadeika
Posts: 3,837
I have a set up where I have a Raspberry Pi(RPi) and a breadboard right next too it which has access to the RPi GPIO. Now, on this breadboard I have plenty of room for a P1 chip, and access to 3.3V from the GPIO to draw the power. Also, the GPIO has access to SPI and I2C, plus other things, which could be connected to the P1. Now, my question is, what would it take, on the RPi side, to get access to and/or be able to program(use) the P1 from either C or Python on the RPi side. I know that SimpleIDE for the RPi is available, but I would like to have access to the P1 while using either C or Python on the RPi.
I am not sure if anybody has thought about this approach or maybe somebody has already done something like this. A good test project would be to have an LED on the P1 p0 pin, an LED on the GPIO available pin, and be able to use C or Python program on the RPi to blink the LEDs of both chips within the same program.
For the RPi there is bcm2835.h which I use to get usage out of the GPIO, what would it take to do a similar thing for the P1 chip? If I am not mistaken, I believe that the add on boards for the RPi that have an Arduino has a similar approach, you access the Arduino via C or Python on the RPi.
Are there tools available for accomplishing this?
Ray
I am not sure if anybody has thought about this approach or maybe somebody has already done something like this. A good test project would be to have an LED on the P1 p0 pin, an LED on the GPIO available pin, and be able to use C or Python program on the RPi to blink the LEDs of both chips within the same program.
For the RPi there is bcm2835.h which I use to get usage out of the GPIO, what would it take to do a similar thing for the P1 chip? If I am not mistaken, I believe that the add on boards for the RPi that have an Arduino has a similar approach, you access the Arduino via C or Python on the RPi.
Are there tools available for accomplishing this?
Ray
Comments
Generally, when I see something like this talking to an Arduino, there is some sort of monitor program running on the micro. In the case of the Arduino, it could be Firmata or some custom monitor written to support the library functions of the RasPi. That's one of the problems with the Propeller and something that needs to be developed. You want the RasPi program to be able to send a "P1 HIGH" command to the Propeller and have the Propeller understand and act on it. This means you need to have code running on the Prop. This makes your potential usefulness of the Prop only as great as the sophistication of the monitor code.
The big issue isn't the physical connectivity between the RasPi and the Prop, it's the glue software: the library on the RasPi and the monitoring code on the Prop. This is one of the reasons I like PropForth (or tachyon or pfth) - these give you a very capable and expandable "monitor" program running on the Prop. The connection is a simple serial link and the "Command Library" on the RasPi is only limited by what you can generate and send/receive across a com port. I haven;t set this up with my RasPi yet but I've done it across a serial link from a PC so it's the same thing.
If you want to use SPI, then you need to have code loaded in the Prop so it can be an SPI slave - I don't believe this currently exists, The P1 can be a SPI master but currently not a slave. I2C would require the same type of code on the Prop. Once you could see it as an SPI or I2C generic device, then you would write soft peripherals to run on the Prop to provide specific capabilities. Letting the Prop do what it does best in becoming a GIGANTIC SPI or I2C soft peripheral. Again, though, this a case of needing a bunch of "monitor" type code to run on the Prop that doesn't exist yet.
I'm not sure about powering all of the Prop from the GPIO 3.3v supply. One place the RasPi is fragile is in it's power supply. I'd grab power from the same powered USB hub that is supplying the RasPi.
Certainly a fun and doable project. Anything you come up with as far as Prop software to act as glue will be usable by others exploring in these areas.
And I strongly suspect that the same conclusions might be arrived at. The Raspberry Pi to the P1 would best use a RS232 via ttl as its link.
Programing could be done with any Parallax software and IDE as they all use RS232. The Raspberry Pi would need to be in a Linux OS to support such.
And if you wanted real-time control of the P1, any of the Forth on Propeller solutions would allow you to program scripts in Python, or just about any language that provides for scripting and an RS232 interface in Linux.
Due to the Raspberry Pi being an SOC (system on a chip), it seems that you either have to use Android or Linux. And since Linux is open source, it is likely the best fit. Though the GPIO seems like in might do fantastic things, the OS dependency really limits the GPIO to being rather limited in tasks. It is much better to off load ADC, DAC, PWM, and real-time motor control to the P1, while have the Rasp Pi provide a terminal, file storage, and an IDE environment. In some case,the Rasp Pi can provide a RTC and a communications link onward to a LAN.
My opinion is based on the realities of the available software resources and the original purpose of the SOC concept.
You can connect those pins directly to the Propeller programming pins (or other) and have a serial link between Pi and Prop.
On the Pi this UART shows up as /dev/ttyAMA0 you can use it from C. Python, whatever just like any other serial port.
BUT:
1) The Raspi Linux kernel uses that port as it's console port. Boot messages are sent to it as as well as any run time errors. You can disable this by removing the console port configuration from the kernel command line arguments that is in one of the text files in the boot partition. I forget what it's called now.
2) Raspbian also runs a login session on /dev/ttyAMA0. If you connect that UART to your PC you can login to the Pi using Hyperterminal or minicom or whatever terminal program. You can disable that by commenting out the line in /etc/inittab that runs "getty" on /dev/ttyAMA0.
With those little changes you are free to use that UART for whatever you like. On the Prop side you are going to use Spin and the FullDuplexSerial object. You just have to write a few lines of code to accept your commands from the serial link and do the required action, turn LED's on and off etc.
You can use C on the Prop if you like. Either way SimpleIDE is available to run on the Pi itself. I'm haven't yet finished hacking the loader to use that UART yet so it still needs a PropPlug to program the Prop via USB serial.
I finally got tired of hearing you all talk about the Pi and feeling left out so I ordered one to get in on the action! :-)
As for the "glue" program on the P1, it almost looks like it would have to be some kind of kernel with a lot of drivers for the anticipated use of the pins. This would be one heck of a way to learn PASM, I do not see anything else that could do the kernel justice.
On the RPi side, first you would have to work in some code that would prep the UART for a condition to talk to the P1, then reinstate it back to its original state once you are done with the P1PiPlate. Also you would probably have to develop some sort of library for the C and Python programs so you could have some kind of commands or functions that would access the P1.
I just had a strange thought, am I having a senior moment, could the "glue" on the P1 be written in FORTH? But then how would FORTH behave with a C or Python master? Wouldn't that be a strange beast, an RPi to do the heavy lifting, a P1 to do the slave work, and FORTH to bind the two together, what a strange beast indeed.
Ray
It's like the command shell (DOS Prompt) it can be written in anything and as a user, you really don't care as long as you can type in "dir" and get a list of files displayed, etc.
The monitor needs to be able to accept input from the RasPi in comes manner (serial, SPI, I2C), understand and process that input (recognize P1 HIGH and run code on the Prop to raise P1 to a high), and then respond to the RasPi in some manner to acknowledge the command or return a status or value or something you have agreed upon as being meaningful. That's it, anything from a very simple serial pin# and state (1 1 0r 1 0) to a complex protocol to set up completely independent functions like you would do for an SPI or I2C peripheral. It can be very simple just to meet your immediate needs or it can be a more sophisticated kernel/driver arrangement - your choice since one hasn't been written yet!
Personally, I'm going to choose a Forth for the monitor just because it is quick to get running (for me), easy to develop and debug by just using a terminal and writing the Forth code you need interactively, and probably speedy and memory efficient enough for doing the things I want to do with the Prop. Others will write their monitors in SPIN/PASM (if you want a soft peripheral that already has OBEX code), C (because that's what those people do), BASIC, etc.
If Parallax develops a standard library for the RasPi and a standard monitor for the Prop, all the better, otherwise as with most things in Propeller Land, there will be many choices of different implementations and capabilities buried in the forum threads for people to hunt for and use and change as they see fit.
I'd try to use the existing RasPi libraries for Python, C, etc. so at least one side of the connection is consistent. If someone takes the micro-controller code that exists for other controllers and ports it to the Prop, more the better for the Propeller users, new and old!
I spent the night tossing and turning about that second UART on the Raspberry Pi. Is it being deployed to the USB interface?
Also I wonder why one cannot have the USB interface connected to a USB to RS232 adapter and have that provide a second active serial port. This would mean that the Raspberry Pi could provide a role as a headless Linux machine simultaneously with having an active Propeller hooked up to the other serial port.
This is normal configuration at my house. A headless RasPi with a powered USB hub and multiple Propeller boards connected to it. Works like a champ!
Same thing most of my Propellers are doing right now. Not much!
I think I have 3 Quickstarts currently. One is running Propforth 5.5, one has the new 6.0 on it and I don't think the other one is currently doing anything. I had just hooked them up to the RasPi so I could SSH to it and then minicom to the Propellers to play with Forth. The one that isn't doing anything was going to be a target for SimpleIDE on the RasPi but I got distracted/interrupted before I got all the pieces working.
It's more just to show that you can have multiple USB connected Propellers than anything practical.
I often find myself not near a Propeller and wanting to play, so I hooked them up this way for remote access.
I just did a mini project with the RPi and a Sensirion sht11 module which was done in C, but I think that I would like the sht11 attached to the P1, and then have access to it from the RPi. This would get me some experience in attaching gadgets to the P1, and then controlling/using them with the RPi. I think that this might be more suited to my programming capabilities at this time.
Ray
The monitor program on the P1 won't care how it is connected.
The only real GPIO advantage I see is if you have a dedicated Pi-P1plate or want to use SPI or I2C.
Gurus, please advise if I'm missing something.
They are out there generally. You might see if there are any small shops or consultants in your area looking for help on the software side. If you don't have any contacts to reach out to now, try looking around online and in local publications. If you can just get your foot in the door, make some contacts, you won't have much trouble from then on.
Control the Propeller
Prop1_IO.high()
Prop1_IO.low()
Control the GPIO
extgpio.high()
extgpio.low()
extgpio.waitMS()
I have an LED on the breadboard with the GPIO, so now I can program, using Python, to blink the LED via GPIO, and have the Activity Board LEDs on P26 and P27 blinking all at the same time.
This is what the monitor program looks like so far:
/* test2.c December 30, 2013 */ #include "simpletools.h" #include "simpletext.h" #include "fdserial.h" int main() { // Add startup code here. char inBuff[40]; int inDec; /* Rx Tx Mode BAUD*/ serial *term = fdserial_open(31,30,0,115200); while(1) { // Add main loop code here. readStr(term,inBuff,40); if(!strcmp(inBuff,"high")) { readStr(term,inBuff,40); { inDec = atoi(inBuff); high(inDec); } } else if(!strcmp(inBuff,"low")) { readStr(term,inBuff,40); { inDec = atoi(inBuff); low(inDec); } } else { print("?\n"); } pause(50); } }RayWhy don't you just use TACHYON Forth or PropForth for this? Otherwise, you will either have to do a lot of programming(which may be the point), or have the P1 just serve as a glorified port expander.
The thing the Pi needs is real time IO, and the Propeller can handle that. The Prop needs a good interface, and for me, I like Tcl/Tk for that which the Pi can provide.
I am guessing if you wanted to make a P1Piplate, you could pass through most of the GPIOs and use other GPIOs to bitbang an interface to the prop. Has anybody done a bitbanged serial port yet on the Pi?