Raspberry Pi to Propeller via SPI
Rsadeika
Posts: 3,837
I guess the first question would be, has anybody done this? Would this type of connection between the RPi and the Propeller be fast enough to do anything useful? On the RPi side, probably I would use python code, on the Propeller side, yet to be determined as to what would be used.
Thanks
Ray
Thanks
Ray
Comments
One might think it is impossible for Propeller to fulfill 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?
shouldn't be too hard to configure 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]
Is there something I am missing about the desire to use synchronous rather than assynchronous? I presume that at these speeds you will quickly fill any buffer in a Propeller, and that any data the Propeller might be streaming to the Pi at 3Mbyte is going to create a huge file 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?
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.
As mentioned above, LVTTL serial is the simplest way to go.
The next step will be to find 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 figure 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 different 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 verified 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
Don't forget to disable the kernel from using that UART as it's console port (see boot configuration) and turn off 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:)
Ray
Sounds like an interesting coding challenge to me to prove that figure wrong
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 buffer the incomming data or to immediately process. (It is a pipeline, not a rocket ship.).
That has a 8 bit FIFO mode, and some quick tests here got to just under 8Mbd. (1MByte/sec, one way, 16k bocks )
+1
I fired up the computer this evening specifically to see what Prop-RPi pipe was being proposed. A 74HC299 to propel an SPI slave function sounds great to me!
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 offered asynchronous serial as ports. And each port has a file 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 significantly 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 specific purpose for doing so. Each specific purpose may lead to a separate solution.
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.
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 fill any buffer 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 fibre-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 find space and time to do something else that is necessary and useful?
Sounds like a great idea since we will never see such a hardware function inside any Propeller chip.
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" configuration 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 effect 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,
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.
RTOS or Linux makes no difference. 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.
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 fits in a Propeller. Point is, do the big stuff on the host ARM or whatever it is and do the real-time I/O on the Prop.
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.
I think you would benefit 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 difference between slave and master is who supplies the clock. Bidirectional communication is simultaneous if you want it to be, and I always do.
Higher speeds can mean less latency, and for local links, there is no real benefit from going really slow. (unless you are using the baud-rate itself as the primary means of setting the slave cadence).
Yes, another benefit 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.
I would have to say that higher speed up to a point, is handy to reduce latency, but filling or emptying buffers 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 benefits of an SPI in this context?
Even Heater and i feel that the UART to the Propeller tends to be a good first choice.
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_Interface_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.
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 buffer
- 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!
An HC299 has some fish-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 flip 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 float 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.
Hello!
I am investigating a similar series of ideas. So how did you install the PySerial library?
Ray