Shop Learn    

Categories Discussions Participated Sign In Register

HOME› GENERAL DISCUSSION

Search 
Raspberry Pi to Propeller
Equip your Genius via SPI
Welcome to the Parallax
Discussion Forums, sign-up to Rsadeika Posts: 3,532
participate. 2013-10-16 07:27 edited 2013-10-26 11:08

Sign In Register

I guess the rst question would be, has anybody

Quick Links
done this? Would this type of connection
Categories
between the RPi and the Propeller be fast
Recent Discussions enough to do anything useful? On the RPi side,
probably I would use python code, on the
Categories Propeller side, yet to be determined as to what
would be used.
All Categories 100.7K

Announcements 803 Thanks

Microcontrollers 65.9K
Ray
Propeller 2 2.4K

Propeller 1 27.4K
Comments « 1 2 »

BASIC Stamp 18.8K

jazzed Posts: 11,803

General Discussion 21K
2013-10-16 07:55 edited 2013-10-16 07:55

Learn with BlocklyProp 2K

You'll need Propeller to behave as a SPI slave

Robotics 8.2K
device for that.
Customer Projects 108
One might think it is impossible for Propeller to
Accessories 3.3K ful ll this function. Well it won't at typical SPI
clock speeds.
Fortunately Broadcom gave some thought to slow
peripherals. RPi can accommodate the Propeller's
lack of a fast synchronous slave serial
receive/transmit.

The driver should be able to set the SPI clock

speed anywhere from 125MHz (clearly impossible
for Propeller) down to 7.6KHZ (clearly possible).

Now all you need is a Propeller SPI slave driver ....

Is there an xGameStation Chameleon SPI Slave
driver?

Mark_T Posts: 1,981

2013-10-16 08:18 edited 2013-10-16 08:18

I'd checkout whether a 74HC299 shift register can

help - it works both as serial->parallel and
parallel->serial so
shouldn't be too hard to con gure as an SPI-style
interface. Parallel load it with the reply, wait for
the clock
to toggle 8 times (with a counter), then read the
parallel pins.

[and it can shift in either direction too]

LoopyByteloose Posts: 12,537

2013-10-16 10:29 edited 2013-10-16 10:29

I suppose that you could use SPI if you desired,

but ttl level RS232 might be quite a bit easier to
deploy on both sides. I presume that the
Raspberry Pi would be using Linux and could
open a serial port as a le in the /dev folder.
Python could then pipe input and output through
that. Speeds up to 3M baud have been done to
and from the Propeller with Tachyon Forth and a
ttyUSB port in LInux.

Is there something I am missing about the desire

to use synchronous rather than assynchronous? I
presume that at these speeds you will quickly ll
any bu er in a Propeller, and that any data the
Propeller might be streaming to the Pi at 3Mbyte
is going to create a huge le analiyse.

Mostly, you are just going to have bursts of

activity with packets of limited size. Or are you
going to have the Raspberry Pi display data in
realtime?

bomber Posts: 297

2013-10-16 10:58 edited 2013-10-16 10:58

As mentioned above, SPI would probably not be

the best form of communication with a propeller.
I have been experimenting around with python
interfacing to the propeller using USB/rs232 style
interfacing (see this post here). I connected the
propeller to my computer(later to be the
raspberry pi), and used FullDuplexSerial to
receive/transmit info to the python code. On the
python side, I used the PySerial library and some
ingenuity.

Heater. Posts: 21,233

2013-10-16 11:06 edited 2013-10-16 11:06

I'd be inclined to go for using the UART on the

GPIO as well. Much easier, the code for the Prop
exists already. I'd also use the Prop's
programming pins for the serial connection. Then
you can program your prop from the Pi itself. You
can develop in Spin and C for the Prop on the Pi
using SimpleIDE. There is a SimpleIDE package
for the Pi here:
https://dl.dropboxusercontent.com/u/81267937/Si
mpleIDE-0-9-43.armv6l.raspberrypi-linux.tar.bz2

Of course that assumes you are not needing the

UART for other purposes. After all it is the Pi's
kernel console port which is pretty useful
sometimes.
Bill Henning Posts: 6,445
2013-10-16 15:01 edited 2013-10-16 15:01

A P1 SPI slave driver would max out at around

1Mbps, while async serial can do 2-3Mbps, so SPI
is counter indicated.

As mentioned above, LVTTL serial is the simplest

way to go.

Rsadeika Posts: 3,532

2013-10-17 02:21 edited 2013-10-17 02:21

Thanks for all the good information, I will be

using the serial solution. I will now start 'My
Common Ground' project, I will be expanding the
RPi platform to include an Activity Board and the
Parallax li-ion power pack. I now have a platform
that has an RPi, a breadboard, and the GPIO
cable that connects to the breadboard. At the
moment I am powering the RPi with a USB cable
that has some connectors to the GPIO, this way I
power the RPi board and I use Putty to get
terminal access.

The next step will be to nd a suitable 5VDC

connection on the Activity Board to power the RPI,
then use Python PySerial to make the serial
connection to the Activity Board via the USB. Then
I will have to gure out how to start the Python
PyComm program on power up from the Activity
Board, I have never created a Linux start up task
before. This should turn out to be a very useful
test platform for evaluating di erent sensors and
equipment that will be handled by the AB-RPi
combination.

Some future tests: the RPi camera module,

possible mounting of the camera to the Parallax
servo operated Ping))) bracket, ..., etc. Once this
technology gets veri ed and functional then it
will be applied to 'My ActivityBot' project. I can
visualize 'My ActivityBot' with the RPi camera
mounted, moving around in either manual or
roam, displaying streaming video on my desktop
system. This should keep me busy for a while,
hopefully with no major setbacks.

Ray

Heater. Posts: 21,233

2013-10-17 03:12 edited 2013-10-17 03:12

Ray,
...'My Common Ground' project...

Interesting. I started on that idea a while back

but things have been held up for a long time. I
want to use node.js on the Pi so that I can go
straight from webserver (implemented in node.js)
to serial to Propeller. BINGO the Prop has a web
interface.

Then I will have to gure out how to start

the Python PyComm program on power
up from the Activity Board,I have never
created a Linux start up task before.

Don't forget to disable the kernel from using that

UART as it's console port (see boot con guration)
and turn o the login shell that is started on it
after boot (see /etc/inittab)

One could be perverse and leave the default Pi

set up as it is. Then the Prop could log itself in as
root and take control of the Pi !

The Prop could issue commands to start and stop

whatever processes you like. Your python
programs could be written to simply talk to
standard input and output like any other
command line program but it would actually be
the Prop it was talking to.

Sounds a bit like the tail wagging the dog but,

hey, this is Parallaxia where many strange things
happen:)
prof_braino Posts: 4,312
2013-10-17 05:00 edited 2013-10-17 05:00

Does the connection speci cally need to be SPI?

On our project we connect the prop pins directly
to the RPi GPIO and communicate with regular
serial.

Rsadeika Posts: 3,532

2013-10-17 05:03 edited 2013-10-17 05:03

One could be perverse and leave the

default Pi set up as it is. Then the Prop
could log itself in as root and take control
of the Pi !

Yes, I was thinking about that, but I want a

situation where more of the RPi RAM resources
are used, the Activity Board has precious little
RAM to work with. If I go that route then I would
need some kind of login script on the AB side,
which would take up a lot of RAM data space. I
guess I have to give this some more thought,
eventually this will end up on the ActivityBot, so I
have to keep in mind how I will be able to access
the AB for programming, and also the
programming of RPi, in a convenient manner.
Back to the drawing board ...

Ray

Mark_T Posts: 1,981

2013-10-17 07:38 edited 2013-10-17 07:38

Bill Henning wrote: »

A P1 SPI slave driver would max out at
around 1Mbps

Sounds like an interesting coding challenge to me

to prove that gure wrong

LoopyByteloose Posts: 12,537

2013-10-17 09:56 edited 2013-10-17 09:56

OMG~ did I actually get this right?

I actually think that SPI and I2C are mostly useful

for chips that require SPI and I2C... which the
Propeller can either use or avoid.

Also, the issue of higher speed needs to be

looked at in terms of the packet size of the data,
the activity of the task, and the capacity of the
device to bu er the incomming data or to
immediately process. (It is a pipeline, not a rocket
ship.).

jmg Posts: 14,635

2013-10-17 18:40 edited 2013-10-17 18:40

Another approach is to side-step TTL_UART and

SPI entirely, and try a device like FT240X, using
the RPi USB port instead.

That has a 8 bit FIFO mode, and some quick tests

here got to just under 8Mbd. (1MByte/sec, one
way, 16k bocks )

User Name Posts: 1,451

2013-10-17 19:35 edited 2013-10-17 19:35

Mark_T wrote: »
Sounds like an interesting coding
challenge to me to prove that gure
wrong

+1

I red up the computer this evening speci cally

to see what Prop-RPi pipe was being proposed. A
74HC299 to propel an SPI slave function sounds
great to me!

LoopyByteloose Posts: 12,537

2013-10-18 03:30 edited 2013-10-18 03:30

There is really a core issue of what is the chosen

OS on the Raspberry Pi.
Since Android and LInux are Unix-based, I
presume that the Unix scheme is already in place
in some fashion. And that is mostly why I suspect
that SPI is not any real advantage.

Unix essentially divides all data transfers into

Block transfers of data, or streams of 8bit
characters. The Character transfers have
traditionally o ered asynchronous serial as ports.
And each port has a le name in the /dev
directory. You could add more, and you could add
a driver for SPI. Linux has supported SPI like data
transfers for keyboard and mouse services.

But in adding an SPI driver, you may have to get

rather deep into the Kernal to optimize to a
speed greater than the existing asynchronous
services. In doing so, you might just unbalance
the whole multi-tasking scheme in Linux/Unix.
IOW, there is a lot to consider if this is a must-
have item for faster communication performance.
The Propeller side is much easier than the
Raspberry Pi side as the Raspberry Pi is wedded
to a rather large OS.

I guess UserName is considering having one side

parallel and the other SPI to speed things up.

If one wanted signi cantly more speed between

the Propeller and the Raspberry PI, Block
transfers are a very real alternative. Maybe a full
parallel exchange.

A lot of enhancements for the sake of speed can

be done, but I still don't grasp the speci c
purpose for doing so. Each speci c purpose may
lead to a separate solution.

Heater. Posts: 21,233

2013-10-18 03:59 edited 2013-10-18 03:59

What unix does is not really relevant. Char and

block devices are only an abstraction (admittedly
based on what hardware could do when it was
devised), and you can apply that abstraction how
you like. For example I have just created a Linux
driver for a 96 bit parallel I/O card. It happens to
group bits into 8 bit ports that can be con gured
as input or output. Those ports are presented as
character devices, open the device, write a byte
there and the output bits adopt the pattern of
the char you wrote. If those bits were driving
some external RAM or some such I might have
presented a block driver interface.

Linux on the Pi supports SPI as a master. It is easy

to use as this article shows:
http://www.100randomtasks.com/simple-spi-on-
raspberry-pi
No doubt the same can be done from C or your
language of choice. I have no idea how the speed
of this compares to the UART.

The main issue here is: Do you need that UART to

continue to function as the Linux console port?
That can be very useful especially if you are
running without a screen.

If the OS on the Pi is not Linux based then, I'm out

of the picture.

LoopyByteloose Posts: 12,537

2013-10-18 10:27 edited 2013-10-18 10:27

And so, the Raspberry Pi appears to have only

one UART in silicon. Is that occupied with serial
when the USB interface is used for console as
well? Might a second bit-banged software UART
provide the Raspberry Pi with a console interface,
while the physical UART is allocated to greater
speed?

If you consider that the Propeller has 32K of RAM,

at 3Mbits/second... you can either dump all and
everything in the Propeller in less than a second
OR ll any bu er in the Propeller to full in less
than a second. That is why I keep asking why
there is such a demand for higher speed
communications when the Propeller is involved.

The issue of communications speed would be

better applied to trying to keep up with a bre-
optic internet connection. There, the Raspberry Pi
can stream audio or video.

I can see how you can open more 8bit ports to

aggregate into larger transmissions, but when is
the Propeller going to nd space and time to do
something else that is necessary and useful?

jazzed Posts: 11,803

2013-10-18 10:34 edited 2013-10-18 10:34

User Name wrote: »

+1

I red up the computer this evening

speci cally to see what Prop-RPi pipe was
being proposed. A 74HC299 to propel an
SPI slave function sounds great to me!

Sounds like a great idea since we will never see

such a hardware function inside any Propeller
chip.

Heater. Posts: 21,233

2013-10-18 10:57 edited 2013-10-18 10:57

Loopy,
As far as I know there is only one hardware UART
usable on the Raspi. It has Tx and Rx pins
available on the GPIO header. By default in the
"out of the box" con guration this is used as the
kernel console port displaying boot up
messages, and then when everything is up and
running there is a login shell available on that
port.

Very useful if your Pi has no display, like when it's

buried in the middle of some robot or whatever
you are building.

What happens on USB is something else. Plug in

a USB serial adapter and it will show up as
/dev/ttyUSBxx and you can do whatever you like
with it. This has no e ect on that GPIO serial port.
It's a totally other device.

I really would not attempt a "bit banged" UART on

some GPIO pins. Except at the slowest speeds.
Linux is a multi-tasking OS, It might be very hard
to bit-bang a UART and get those edges timed
right without stalling everything else that is going
on. If it's possible at all. Certainly a lot or work.

You might have more luck bit-banging over a

parallel interface of 8 bits plus handshake
signals. Where the Pi controls the handshaking.
That is a big waste of GPIO pins though and not
necessarily any faster,

LoopyByteloose Posts: 12,537

2013-10-18 11:33 edited 2013-10-18 11:33

Years ago I got into RTOS (real time operating

systems) as it seems that robotics needs
deterministic computing. Linux and multi-tasking
OSes tend to be at the opposite end of the
spectrum... very un-deterministic.

So, for me personally, I can't see how I might use

a headless Raspberry Pi to enhance a Propeller
driven robot unless it was an extremely
ambitious navigation and mapping system in the
background. One device is deterministic, the
other is something else --- there appears to be a
natural division of labor in play.

Okay, it appears Heater has SPI up and running

on the Raspberry Pi. If someone has a role for a
Propeller as an SPI slave, the issue is resolved.

When I look at the GPIO interface for an

OpenARM board, I am stumped as it seems that
most of the pins are allocated to tasks and that
bit-banging is not a realistic option. My
Cubieboard will load Ubuntu 12.04, so I am
thinking mostly in terms of what I know about
that OS. My preferred use of the Propeller is in
Forth and the asynchronous full duplex serial
holds more appeal to me personally.

I do suspect that you could shift the Console

serial over to an ttyUSB device when one is
present. And then you would have the UART
available for direct lvttl asynchronous to the
Propeller. You would also have the advantage of
full duplex and not have to rely on a Master/Slave
arrangement. I am not sure that I want the
Propeller to always operate as a Slave and the
OpenARM to operate as a Master.

Heater. Posts: 21,233

2013-10-18 12:03 edited 2013-10-18 12:03

Loopy,

RTOS or Linux makes no di erence. If you want to

bit-bang serial at 115200 baud you have about
8.6 micro seconds per bit. For a 700 MHz CPU that
is about 6000 instructions per bit. You want full
duplex of course so thats only 3000
instructions. With the overheads of task
switching, virtual memory and so on you are
going to hang up your whole CPU doing that from
a user space program.
What you need then is to do it from an interrupt
handler or two. One interrupt on the incomming
edges for RX and one on a timer for the TX. Then
you are into some serious device driver writing.
Been there done that. No one wants
to do that.

Believe it or not modern Linux is a very capable

real-time OS, preemptive scheduling, task
priorities and all. Still I would not want to use it at
such speeds.

I can't see how I might use a headless

Raspberry Pi to enhance a Propeller
driven robot

Robot was only an example. Even there I can

imagine that a robot might like a wireless
internet connection for command and status
monitoring together with TLS security and so on.
Or perhaps my robot would like a bigger "brain"
than ts in a Propeller. Point is, do the big stu
on the host ARM or whatever it is and do the real-
time I/O on the Prop.

I do suspect that you could shift the

Console serial over to an ttyUSB device
when one is present.

Yes you could. You can get console access

however you like. USB, ssh network connection,
whatever. The beauty of the console being on the
onboard UART is that it works from the get go.
Before any OS is acually running, before device
drivers are loaded. You can even talk to your boot
loader on that port, which is useful if you kernel
fails to boot for some reason.

Having said that, I would still go for using the

UART to talk to the Prop.

User Name Posts: 1,451

2013-10-18 13:40 edited 2013-10-18 13:40
 Loopy Byteloose wrote: »
If someone has a role for a Propeller as
an SPI slave, the issue is resolved.

I think you would bene t from looking at the

whole matter from a higher level of abstraction.
The Propeller would be (for starters) a general
purpose peripheral of the RPi - something like a
smart PIO. That it happens to communicate with
the RPi through an SPI is almost incidental,
except as it impacts latency and maximum
throughput.

But if we were to descend the abstraction ladder

to the hardware level, it is worth noting that an
SPI Slave is not a bad thing to be. In the world of
SPI, the only di erence between slave and master
is who supplies the clock. Bidirectional
communication is simultaneous if you want it to
be, and I always do.

jmg Posts: 14,635

2013-10-18 17:20 edited 2013-10-18 17:20

Loopy Byteloose wrote: »

That is why I keep asking why there is
such a demand for higher speed
communications when the Propeller is
involved.

Higher speeds can mean less latency, and for

local links, there is no real bene t from going
really slow. (unless you are using the baud-rate
itself as the primary means of setting the slave
cadence).

jmg Posts: 14,635

2013-10-18 17:23 edited 2013-10-18 17:23

Heater. wrote: »
 Having said that, I would still go for using
the UART to talk to the Prop.

Yes, another bene t of UART protocol is that you

can be more easily portable, and testing is
simpler because you can use any PC.
SPI will need custom SW at both ends, and so
restricts testing choices.

LoopyByteloose Posts: 12,537

2013-10-19 01:59 edited 2013-10-19 01:59

jmg wrote: »
Higher speeds can mean less latency, and
for local links, there is no real bene t
from going really slow. (unless you are
using the baud-rate itself as the primary
means of setting the slave cadence).

I would have to say that higher speed up to a

point, is handy to reduce latency, but lling or
emptying bu ers faster than they can be
processed in a 32K ram seems odd to me. There
just seems to be a more is better perception of
higher and higher speeds, regardless.

The odd thing is that I seem to think of SPI is

more useful when you don't have precise crystal
driven clocking and want to use slower speeds..
maybe even a variable clock to reduce power
consumption. Desktop computer used this kind of
interface for the keyboard and mouse just
because the support chips were cheaper.. not
because they required more speed. Early on,
speed seemed to always go to parallel interface
(until it seemed that cross-talk was messing up
the parallel approach).

SPI is handy when a UART is not provided, or too

much an expense to include in an accessory chip.

I just can't seem to get excited at using it for a

jump between the Propeller and Raspberry Pi. I
guess I envision some kind of peer-to-peer dialog
that has both listening and both transmitting
data that the other needs to know and interpret.
Master/slave relationships can be useful, but
they do impose limitations to communications.
Waiting for the Master to inquire might make any
enhancement of speed rather moot.

Am I completely missing the bene ts of an SPI in

this context?

Even Heater and i feel that the UART to the

Propeller tends to be a good rst choice.

Heater. Posts: 21,233

2013-10-19 02:21 edited 2013-10-19 02:21

"The need for speed".

I don't know, it's cool.

What if I want to use my Prop as a VGA VT100

terminal display for my Pi, which does not
support VGA? Faster is better.

What if my Prop is connected to a bunch of other

serial links and multiplexes those over a single
link to the Pi? Faster is better.

And so on.

UART or SPI?

I don't know. Check the pros and cons here

http://en.wikipedia.org/wiki/Serial_Peripheral_Inte
rface_Bus A lot will depend on your application of
course. Perhaps you need that SPI for other SPI
things, or you need the pins it uses for GPIO.

What if you want the Prop to be able to send to

the Pi at anytime without the Pi having to
constantly be clocking the SPI?
It might be nice that one could hook multiple
Props and other devices on the SPI bus.

UART is much easier to use and test code with.

Bill Henning Posts: 6,445

2013-10-19 08:50 edited 2013-10-19 08:50

Please do, I'd love to see higher speed SPI slave!

I based my calculation on:

- 80Mhz P1
- 6 cycle minimum to wait for clock edge (high or
low)
- 4 cycles to get I/O bit into carry
- 4 cycles to shift it into byte bu er
- 6 cycles to wait for opposite clock edge

minimum 20 clocks per bit if everything lines up

perfectly, not reliable until at least 40 clocks
(Nyquest)

Ok, so 2Mbps slave may be possible.

Now for SPI devices that also expect to receive a

byte when sending a byte, add 8 cycles per bit,
for 28 cycle minimum, 56 with Nyquest factored
in.

That brings us down to 1.428Mbps max @ 80Mhz

SPI master can be MUCH faster for send, as much

as 20Mbps (as we supply the clock), with 10Mbps
receive.

The mention of the 74hc299 earlier in the thread

is a good point, while it would take more Prop
pins, it should allow MUCH faster SPI slave!

Mark_T wrote: »
Sounds like an interesting coding
challenge to me to prove that gure
 wrong

jmg Posts: 14,635

2013-10-20 18:19 edited 2013-10-20 18:19

Bill Henning wrote: »

The mention of the 74hc299 earlier in the
thread is a good point, while it would take
more Prop pins, it should allow MUCH
faster SPI slave!

An HC299 has some sh-hooks.

It has a single clock, so parallel load needs the
Prop to have data ready, and the host has to give
one (or more) clocks to load, then it needs to ip
the HC299 to shift, and pause when done, until
the Prop has read
The Prop timing between bytes becomes very
important, and relatively large between byte
pauses would be needed.

There also is no OE on the Q7 (MISO) pin, so a SS

cannot oat multiple SPI slaves.

It may be possible to use a /toggle mode, similar

to EE Memory for the host to check 'Prop read ok,
but Prop write would have to be inferred.

An alternative device could be a pair of

HC40105/HC7403 FIFOs : to each side they look
like slave devices, so Prop runs in faster master
mode.
With 4 lines possible, a SPI link plus select lines
can transfer info like command/data controls
from host

The Prop can start reading quite soon after Host

starts sending, and 16/64 bits can be sent, and
read and write are duplex from the Prop. If the
Host can start clocking before the Prop loads
data, one of the spare outgoing lines could be
used as a frame signal, very like i2s, that toggles
every 16 bits
 For higher performance, and higher production
volumes, the OTP Lattice CPLD QFN32
ICE40LP384-SG32 (1: $1.65) would allow a quite
comprehensive Dual-port SPI to be built.

Buck Rogers Posts: 1,981

2013-10-26 10:41 edited 2013-10-26 10:41

bomber wrote: »
As mentioned above, SPI would probably
not be the best form of communication
with a propeller. I have been
experimenting around with python
interfacing to the propeller using
USB/rs232 style interfacing (see this post
here). I connected the propeller to my
computer(later to be the raspberry pi),
and used FullDuplexSerial to
receive/transmit info to the python code.
On the python side, I used the PySerial
library and some ingenuity.

Hello!
I am investigating a similar series of ideas. So
how did you install the PySerial library?

Rsadeika Posts: 3,532

2013-10-26 11:08 edited 2013-10-26 11:08

sudo apt-get install python-serial. Another

interesting program that I found, sudo apt-get
install xrdp, then you can get to the RPi desktop
from Windows using mstsc.

Ray

« 1 2 »

Sign In or Register to comment.

© 2021 Parallax Inc. | 599 Menlo Drive, Suite 100 | Rocklin, CA 95765 | USA

