Fast connections between RPi and Teensy 3.1?

[Zeph]

Connections I've considered:

BlueTooth - channel limited to about 1 Mbps at best
Async Serial - perhaps fast if Teensy side uses DMA?
SPI (RPi as master) - perhaps fast if Teensy side uses DMA?
I2C - not very fast
USB - can this be done?
ethernet - 10 Mbps throughput with Wiz820io?

Any tips or experience with using these between RPi (2) and Teensy 3.x? Or other options?

I'd prefer not to have to use a BeagleBone Black with its shared memory PRUs.

 

[mlu]

So how fast must it be? How much hard work must the RPi and the Teensy do apart from communications ?

USB in serial mode should work very well, the Teensy can deliver up to 10Mbps over serial usb,
with the RPi beeing Linux, USB serial should work as a charm.

Async serial is in general a simple and easy to use, and can be clocked quite fast with short cables.

RPi I2C hardware is a bit buggy, not handling clock stretching correctly, tested to be not 100% reliable.

I dont know why the shared memory PRU's on the BBB would be a problem, you dont have to use them and if you do
they can with some hard work be made to do some nice tricks, including fast communications.

 

[Zeph]

Thanks for the tips.

So how fast must it be? How much hard work must the RPi and the Teensy do apart from communications ?

Good questions. I have several projects in mind and it may vary. One for example is a POV display with a rotating line of APA102 LEDs, to be updated as fast as possible (this chip has 20 KHz PWM and data can be clocked at 20 Mbps, so > 1000 updates per second is reasonable). There's no fixed speed requirement, but the faster I can get data to it, the more resolution - so I was wanting to explore just how fast that can be. There are other potential projects as well. And it's a matter of technical curiosity...

USB in serial mode should work very well, the Teensy can deliver up to 10Mbps over serial usb,
with the RPi beeing Linux, USB serial should work as a charm.

OK, that is a leading contender; that's about the throughput others have given for Teensy + Wiznet 820io ethernet.

Does anybody have any practical experience with fast USB serial between RPi and T3.1 specifically?

Async serial is in general a simple and easy to use, and can be clocked quite fast with short cables.

I'm guessing that async is still going to be limited to around 1 Mbps, tho, right? Can they go any faster?

And there probably isn't any route to isochronous serial between the two (UART based but with one clock per bit rather than using 8x or 16x edge detection; the ATMega328p has this via XCLK).

RPi I2C hardware is a bit buggy, not handling clock stretching correctly, tested to be not 100% reliable.

Let's rule that out then. It was never a leading contender anyway.

I dont know why the shared memory PRU's on the BBB would be a problem, you dont have to use them and if you do
they can with some hard work be made to do some nice tricks, including fast communications.

Actually, I realize that given enough effort, it might be the best solution technically - the shared memory is a big plus. It's the learning curve that puts me off. I'd rather if possible continue to use the Teensy 3.x which is more familiar to me, is used in other projects, has many libraries I'd like to make use of, etc. I'm also not a linux expert, and the RPi has a larger community.

So this thread is about exploring what's possible in terms of high speed RPi <-> Teensy connections - for my projects or anybody's projects. I couldn't find such a thread on the forum. (Pointers welcome tho).

There is another option I'd like to hear about from those with more knowledge - SPI. How fast can a RPi master communicate with a Teensy 3.1 via SPI? I'm assuming the slave Teensy might need to use DMA to keep up with fast timing set by the RPi master, especially if the master is reading info from the slave.

The last option (not included in OP) would be an 8 bit parallel transfer. I don't know if that's possible (at high speed). There was a time when we could crank out some decent transfer rates over the simple IBM PC parallel port (decent for its time).

 

[JHGildea]

Registered to second this thread. Been lurking here and there for the past two years.
From what I've read, the SPI on the RPi2 has some kinks to work out in the >1Mbps region.
There appears to be a 4 ms delay because of driver issues. However, I might have misread this 10 page thread discussing it.
https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=19489&sid=7964b72111e9ae2b121b77cbb4670fbf

Currently I'm looking into a little server hosted on a RPi2 which is SPI connected to a Teensy which is USB connected to the PC.
This is in effort to explore how to "isolate" the PC from the router with >4Mbps reading for fun.
I realize I can just connect the RPi2 to the PC but I want to try parsing streamed data, and also learn some of this thoroughly non-standardized SPI system.

 

[PaulStoffregen]

You should use USB in Serial mode. Speeds of approx 1 Mbyte/sec should be possible, though it would be wise to design your project to use less than 100% of that possible bandwidth. Especially on the Linux side, speeds can vary as you do different things.

While other approaches like SPI and parallel buses might be possible, to facilitate a fast LED project, you need both speed and efficiency. USB is very efficient, because hardware handles the movement of data while leaving the CPU mostly free. Driving those APA-102 LEDs will consume massive CPU time, so you need hardware that can efficiently receive the next data with little CPU impact while you're running CPU-intensive code to use the current data.

 

[PaulStoffregen]

Also, for a persistence of vision (POV) project, buffering some or all of the displayed data on the Teensy side can dramatically improve performance.

For example, if you have 250 LEDs spinning fast with 25:1 multiplexing, then your image is effectively 25 frames of 250 LEDs. That would require a 18750 byte buffer to hold all 25 sets of 250 LEDs. Teensy 3.1 has 64K of RAM, so this should fit nicely.

The huge advantage of having the entire data set buffered on Teensy's RAM is Teensy can respond with microsecond accurate timing. Whatever approach you use to know when the LEDs are in a region where they display particular data can immediately update the APA-102s from RAM. USB typically has latency in a millisecond range, or about 1000X less precise timing. By holding the entire set in RAM, you can decouple the low latency POV updates from the high latency USB communication.

If you have a lot more LEDs, you might consider driving them in smaller groups, with one Teensy 3.1 per set.

If you're considering more sparsely than 25:1 multiplexing, APA-102 may not be bright enough.

 

[mlu]

Reverting a bit to the more general question of fast communications between a Teensy and a RPi, or similar.

Wiz820io is ethernet so it can handle 10Mbp why is it not competitive ?
There are several hurdles to climb before reaching this limit.
- General protocol overhead
- Wiz820io is programmed over SPI, and needs a mix of commands and data, so if SPI is not 10Mbps then Wiz is not.

So it is not reasonable to expect local point to point communications using Eyhernet/Wiz820io to be faster than SPI, or much
more than a fairly small fraction of maximal speed.

TBH I have not tried it, and if you prove me wrong, the beer prize will be avaliable to claim in Scandinavia .

So why is USB serial better than "ordinary" asnync serial ?
A better defined electrical protocol that works reliably up to 12 Mbps !!
Cable point to point communications.
Teensy has a full speed on chip implementation, no slow writes to external chips are needed.

 

[Zeph]

Great information, thanks.

@mlu - I saw 10 Mbps mentioned elsewhere on this board as the best NET data throughput using the Wiz820io with T3.1 (after removing protocol overhead). Yes, the SPI connection between T3.1 and WizNet would have to be faster than that to achieve such a result.

@paul - the point about using hardware support for USB makes a lot of sense.

I'm not quite sure what you mean by 25:1 multiplexing in regard to the APA102.

The APA102 is a PWM LED pixel chip similar in niche to the more familiar WS2812b (ie: pixels using integrated 5050 RGB LED+control logic), but it uses two wire SPI for its control rather than the single wire pulse timing protocol of the WS281x. This can load data into the pixels far faster, and it has a 20 KHz PWM rate vs the 400 Hz PWM rate of the WS281x. This makes it potentially interesting for POV displays. Even if you were to update it 2000 times/sec, there would be 10 PWM cycles per update, so you shouldn't get the pwm/update beat frequency artifacts of slower PWM chips.

There is no multiplexing - each of the Npixels*3 PWM channels is on for 0/256 to 254/256 duty cycle. It's supported by FastLED, but the protocol is simple enough to be easily supported without that library if one does't need all the extra functions that FastLED provides.

However if one wants to generate patterns that change continuously, there could be bandwidth and/or latency issue. The RPi has the power to generate the patterns I want (including hardware floating point), but cannot handle the precise timing. So I would need to use buffering on the Teensy side, which would do the direct APA control. So the RPi tries to keep a few refresh frames ahead of the Teensy (um, with "frame" in this case being one update of a linear row of pixels, not a 2D image), falling back when Linux steals the processor and catching up when it can (using the Raspeberry Pi 2 with 4 cores should help reduce the interuptions).

I was hoping that APA102 strip could be driven by the Teensy using DMA, to reduce processor demand - even allowing the Teensy to spend a lot of CPU time on the interface to the RPI if need be. Obviously the processor can't focus too strongly at the same time on both driving individual bytes out of the SPI port and receiving bytes from the RPi - one or both of those needs to have hardware support.

It sounds like the best option for high speed communication between the RPi and the Teensy is probably USB pseudo-serial. I knew the Teensy's were quite fast in that way, I'm not as sure about the RPi.

Thanks again for the tips, and I welcome more input.