PropBerry - Propeller & Raspberry Pi combo
TonyD
Posts: 210
The idea of using a Raspberry Pi to host the props development tools is great, so with this in mind would anyone be interested in an Propeller add-on board for the RPi?
I was thinking using a prop as a super i/o co-processor for the RPi. The PropBerry would be a board the same size as te RPi and connect directly to it's expansion header for power and interboard comms.
Some of the details to work out, such as:
Interboard comms: Serial, I2C or SPI?
RPi to emulate Prop's EEPROM ?
RPi EEPROM programmer?
I've already made several RPi add-on boards so I'm happy to make one for the PropBerry as well.
I was thinking using a prop as a super i/o co-processor for the RPi. The PropBerry would be a board the same size as te RPi and connect directly to it's expansion header for power and interboard comms.
Some of the details to work out, such as:
Interboard comms: Serial, I2C or SPI?
RPi to emulate Prop's EEPROM ?
RPi EEPROM programmer?
I've already made several RPi add-on boards so I'm happy to make one for the PropBerry as well.
Comments
We have been discussing about this kind of board with Heater. for a while now. Idea has been the same, so now when we have development tools running in RPi we could have the Propeller as programmable I/O co-processor on top of it. Regarding communication I guess there will be many opinions(?) but I would just like to have RX and TX lines (which are in RPi header) doing the communication. These can easily be accessed via /dev/tty without any hassle. Also since RPi doesn't have RTC chip, it could be added to this board too (not connected anyhow to Propeller) so we could get the time right also without network connection for RPi. Naturally the board should distribute Propeller pins, but it should too have RPi GPIO pins distributed in case we still need those. Only programmable LED on RPi is by default reserved for SD activity, so it could have LED with necessary resistor connected to free RPi GPIO pin, so state of the RPi could be easily programmed. Maybe there should be another LED for Propeller too, so we could see RPi and Propeller states independently.
Heater. was also thinking about having VGA connector for Propeller.
I was planning to do some drawings with Eagle this week, but I haven't had the time yet.
This link isn't working for me.
Mickster
Not only the Spin tools but propgcc, the proppeller loader and simple IDE are all working on the Prop.
As Copter says we attended the first Helsinki "Raspberry JAM" on Saturday, well the two of us discussing over a beer, and ended up exploring the same idea under the name "Propeller Pi".
Here are some ideas as to what we would like to see in a Propeller add on board for the Pi together with some rationale/issues:
1) Raspberry Pi form factor, piggybacking onto the raspi GPIO header.
The form factor is a must, I'm curious as to how it works out as the Pi has no mounting holes to bolt anything to securely.
2) A DIP propeller.
We like big. If we go to a surface mount Prop then perhaps there should be two of them.
3) The Raspi console port (GPIO14, GPIO15) wired to the Props programming pins.
Sadly there is only one UART raspi UART available and it is by default used as the Linux console. It would be nice to be able to preserve that (see below). Using this UART is the simplest way to be able to program the Prop from the Pi.
4) One raspi GPI used for Propeller reset.
The best bet here seems to be GPIO 17 on header pin 11. That is designated as UART0_RTS in ALT3. I have no idea how to get that pin into use as RTS, if need be we can modify the Prop loaders to tweak that pin as a GPIO for Prop reset.
5) A real time clock chip.
The Pi needs an RTC when not connected to a network. This could be independent of the Prop(s) and directly connected to the raspi GPIO, as Copter says, but there might be some mileage in having it connected to a Prop and read by the raspi via serial or other protocol.
6) VGA output from the Prop.
The Pi does not have a VGA output. Seems to me that would be very nice to have especially as the Prop can perform the function of a VT100 terminal for for the Linux console port. Just a few resistors and a VGA connector.
7) All free Prop pins available on connectors/headers.
8) All Raspi GPI available on connector/header.
9) At least one LED driven from Raspi GPIO.
10) At least one LED driven from Prop pin.
We like LEDs. Especially a TX/RX activity LED(s) on the Prop/Pi serial link. A simple Power LED would be good as well.
11) I'm thinking that possibly this board should be functional without the Pi or at least programmable from the PC as well to that end the normal PropPlug header should be provided.
12) I guess this should have it's own 3.3v regulator.
The glue card could have the RTC on it, maybe a barrel jack for power, regulators if needed/wanted.
If you do go with a new board, I like the idea of the RTC as a peripheral to the Prop and the Prop providing RTC services to the RPi since the RPi doesn't have an RTC, it may as well be a "Properipheral" as just a regular peripheral. The RTC could also be an option on the glue card if you needed it.
The mechanicals involved in mounting anything to the RPi is going to be interesting. The glue car could just be attached with a ribbon cable and then it could be in the stack of Quickstart or PP-USB (DNA) cards.
We're planning to use the prop(s) for connecting big groups of sensors and actuators, prefiltering, logging and streaming; and using the RPi for display, user interface, pre-crunching, and communications services; and using a full on workstation (possible at a remote location) for full on crunching, database services, and long term storage.
In propforth we have synchronous serial connection so we can talk to many cogs at once over the same connection. This just needs an I/O pin on each end and maybe a resistor ( the prop doesn't NEED a resistor, but we always put a 220 ohm in because the designer says its a good idea). We can have stacks of props. The synchronous interface is available in windows and Linux using GO language or Python-CSP. We use Go but haven't gotten started with the Python people yet. When I get my RPi I plan to start looking at Go for RPi. I think somebody smart can implement the channels interface in C if its not done already (I avoid C when I can so I'm not up on this topic, but there's enough folks around that might be interested).
You are right that the mechanics are interesting, I can't see how it works yet. At least it needs to be clear of the metal connectors on the Pi which seems to require custom header breakouts that are taller than normal (according to Adafruit).
Or should the plate have cut outs that go around those big metal connectors allowing it to sit lower? That sounds messy.
The lack of mounting holes on the Pi bugs me.
http://todayimade.co/items/joe-walnes-made-a-tiny-breakout-board-for-raspberry-pi
Yeah, the lack of mounting holes on the RPi is a pain. To make a card a add-on stable I would make PropBerry like this protoboard I designed.
This uses a connector which is ~10.5mm high, which when mated with the pin header of the RPi's expansion header gives a height of ~14mm, This is enough height to clear the RCA and RJ45 connectors. A small slot is used to avoid clashing with the dual USB connector
That is very neat. Perhaps an optimal solution between a rectangular board that sits above all connectors and a monster with cut outs to clear them all.
The cutout isn't bad since it's mostly unusable space unless you can find headers that raise it enough to clear solder bumps but then you need a rubber bumper over the RJ-45 like Adafruit did.
If you put the VGA, KBD, Prop, RTC and 3v3 regulator on the new card, you'd have a standalone PropTerminal (maybe SDRAM and Flash socket too?) that was pretty powerful on its own and added lots of features to the RPi. Moving the KBD to the Prop frees up both USB for more useful things (WiFi, PropPlugs, USB connected Prop Boards, USB disk, etc.)
I'd even scrape the rust off my command line skills with something like this available.
I did do a design where it was a single rectangle board but getting a 26W connector with a height > 15mm that didn't cost a packet was a problem. In the end I settled for a 3M connector I could buy for ~ 3GBP from RS/Farnell (still expensive).
The board shown above is very stable, it actually sits on the RCA and RJ45 connectors making pillars unnecessary and the slot helps stop any turning motion. Only downside is there's a couple of keep out areas for through hole components but in the end it was a fair trade off.
Yes, I forgot the need for a keyboard port for the console terminal interface. Kind of fundamental.
Also that neat cut out around the raspi ethernet port helps to lock things in place and make them nice and stable.
I think we have a plan here:)
On PropBerry-1, should there be a second Prop for general Prop usage? (real-time I/O, device controllers, servos, etc.)
Should there be a PropBerry-2 which just has a general usage Prop (with RTC, SDRAM, Flash) for the headless RasPi scenario? Put a Wifi dongle in the USB and you have a pretty small, pretty powerful PropBerry robot controller.
Of course, with the joys of the Propeller soft peripherals, you just don't load it up to look like a terminal and you have the headless PropBerry.....
Either way, put my name down on the pre-order list!
By the time your Prop code is big enough and can be slow enough to use that it's probably better to run that code on the PI.
So far we have used 8 Prop pins for VGA, one for keyboard I guess, is it three for RTC? And two for the serial comms to the PI.
Leaves 18 for other good stuff.
Not bad.
Of course a two Prop board might be interesting as well.
I can concede the RAM and FLASH, I guess :frown:
Actually, figuring out how to do some things using the RasPi peripherals from the Prop and the Prop peripherals from the RasPi could be fun.
A second Prop is always interesting. (You can always run PropForth on it!
This sounds like a good start for version 1!
Interesting perspectives.
Do you think of creating a Linux program for the Pi that uses hardware services provided by the Prop?
Or do you think of a Prop program that just happens to need the file system, networking, GUI etc of the PI?
At this moment I'm leaning toward the former.
If Prop Plug connector will be included for external programming of Propeller chip, then maybe we could have a switch that allows other use of the connector too. Meaning that we could use Prop Plug also with RPi RX and TX pins, adding possibility to select is Prop Plug connected to RPi or Prop, this way we could use RPi via serial tty too if needed. So modes would be like "Propeller, RPi and straight". This could be done using jumpers too if there's no suitable component.
Today for some reason I started thinking the other way for some tasks. A Prop doing data logging for an attached peripheral and needing to dump data to the Pi's disk every so often. through a Pi service. A Pop-up message handler so the Prop can display messages if needed.
The lines kind of blur at times who's the master and who's the slave. There could be a network of Propeller (Xbee mesh?) that is really run by and for the Props and one of the Props just happens to be connected to the Pi and has access to the outside world and special non-Prop services through it.
It's going to be interesting, fun and at least in my case generally non-productive!
To get this working nicely we need to assign one RPi GPIO pin that will be signalling into which mode this switch has been set. If it's set to RPi, then daemon in RPi will read the state of the pin and spawn tty. Otherwise tty is not running and port is usable for other applications. Maybe setup some kind of autokill function to this daemon, that when tty is spawned, then processes X and Y are killed before and when tty is closed, then applications will be started again.
There is a saying that "form follows function". As it stands on this thread we are discussing the form of the thing without having a function in mind. As a result it is not clear which way to go. Just a vague idea of the Prop as some kind of general.purpose real-world, real-time interfacing thing.
In that case, yes, forget the VGA and just aim at getting, comms to the Prop, maximum I/O potential and the RTC because the Pi needs it.
The VGA idea comes to my mind because at this time the world is full of VGA monitors and the Pi cannot drive them. Just so happens that the Prop can.
Perhaps the Propeller powered VT100 terminal for the Pi is another project altogether.
You are right, we need more beer to think about this:)
[Edit: Struggling along on my own without the beer. Drat!]
mindrobots, If you are going to take this combo with you on a speaking tour and use VGA, then somebody needs to come up with PowerPoint for Propeller, since VGA will be outputting picture created by Propeller chip, not the one that RPi outputs into HDMI or RCA..
Although I like the idea of a PropTerminal for the RPi. There are classrooms full of VGA monitors and PS/2 keyboards and mice which could be reused with the PropBerry and PropTerminal.
Both of these are the main thrust of propforth v5.3 not limited to the RPi, PC running linux and xp are also in scope.
This is the intent of 5.3. If it works, other folks may want it.
Incidentally, there's lots of places where one might want separate display for diagnostics, data, etc that is independent of the fancy video and graphics.