Connecting multiple Teensy with spi?

Status
Not open for further replies.
W

WMXZ

Well-known member
I wanted to connect three T3.1 with SPI. The dataflow is only one-directional.

T1 -> T2 -> T3 ->(T1)

So every Teensy sends data to his right neighbor and receives at the same time data from its left neighbor.
One if the Teensy is master and the other two are slaves.

As I'm a little bit confused with MOSI MISO I use the Dout/Din notation and thought that the following connections should work:
T1.Dout -> T2.Din
T2.Dout -> T3.Din
T3.Dout -> T1.Din

There is some other post, where got the impression that the fact that Teensy is master or slave, does not change the output/input functionality of the Dout/Din ports.

So question is, is my interpretation and topology correct?
 
If your data flow needs are not enormous, I would consider i2c instead. The reason is that bill porter has developed the excellent easy transfer library that someone else amended to include a i2c data transfer module.

As long as your data grams can be predefined in a struct or the amount of data that needs to be transmitted is ridiculous, this is the way to go.

For longer distances than i2c allows, consider RS485, half duplex. Pauls x-MIT pin enable feature makes communicating this way extremely simple.
 
Constantin said:
If your data flow needs are not enormous, I would consider i2c instead. The reason is that bill porter has developed the excellent easy transfer library that someone else amended to include a i2c data transfer module.

As long as your data grams can be predefined in a struct or the amount of data that needs to be transmitted is ridiculous, this is the way to go.

For longer distances than i2c allows, consider RS485, half duplex. Pauls x-MIT pin enable feature makes communicating this way extremely simple.
Click to expand...

Yes, I was considering alternatives, but unfortunately, the datarate is as high as it could get (my final application asks for a 6.4 MB/s transfer rate, or a SPI clockrate of 12.5 MHz resulting in about 50% SPI dutycycle). The 3 teensys are all within body contact, very likely on the same motherboard. So distance is not an issue.

So I have to stick with SPI, also as SPI1 is not operational.
 
FWIW, I would use a star topology, not a daisy chain.

Put all Teensy's on one SPI bus with the Master MOSI going to the MISO on the slaves. Then use a dedicated CS line with a 4.7k pullup resistor for each slave to send the data as needed. That way, the slaves don't have to process all the data all the time and only pay attention when they should be. i.e. I'd consider a interrupt-driven communication.

I'm not familiar with the connection requirements or the setup for a Teensy SPI slave configuration but someone got it to work so I would start there...
 
Constantin said:
FWIW, I would use a star topology, not a daisy chain.

Put all Teensy's on one SPI bus with the Master MOSI going to the MISO on the slaves. Then use a dedicated CS line with a 4.7k pullup resistor for each slave to send the data as needed. That way, the slaves don't have to process all the data all the time and only pay attention when they should be. i.e. I'd consider a interrupt-driven communication.

I'm not familiar with the connection requirements or the setup for a Teensy SPI slave configuration but someone got it to work so I would start there...
Click to expand...

Thanks for the link, I will see how it was done there.
 
Mind the wiring distance limitations.

I'd be concerned about a star topology with SPI where each T3 toggles between slave and master and there's contention, collisions, etc.
Too complex.
 
stevech said:
Mind the wiring distance limitations.

I'd be concerned about a star topology with SPI where each T3 toggles between slave and master and there's contention, collisions, etc.
Too complex.
Click to expand...

While I was only concerned about the DIN/DOUT issue, which I may simply try out, it may be interesting to explain the project a little bit more:

I have three teensy that acquire each 2 ADC channels (in total 6 channels, data rate up to 200 kHz) and perform a spectral analysis.
As I'm interested in cross-spectra, I have to transfer data/spectra from T1 to T2, from T2 to T3 and from T3 to T1, all in parallel. Fortunately other transfers are not required. Using a 4th Teensy to collect spectra is not an option due to max speed of Teensy in slave mode. This, would have been the preferred mode, but seems not feasible due to achievable transfer speed. There are a total of 12 independent cross-spectra and with the indicated data transfer scheme, each teensy will do 4 cross-spectra. So everything could turns out nicely.

After cross-spectra are estimated data are averaged and transmitted to host computer. For this, the three teensy will communicate over a rs485 serial bus.
 
200Ksps? aggregate or per ADC channel?

There are two hardware UARTs on a T3 so you could have an upstream UART to a neighbor Teensy 3 and a downstream UART to the other Teensy 3, e.g.,
T1 to T2, from T2 to T3 and from T3 to T1

If you ran those at 115200 baud or more, would that suffice?
Much simpler than SPI
 
stevech said:
200Ksps? aggregate or per ADC channel?

There are two hardware UARTs on a T3 so you could have an upstream UART to a neighbor Teensy 3 and a downstream UART to the other Teensy 3, e.g.,
T1 to T2, from T2 to T3 and from T3 to T1

If you ran those at 115200 baud or more, would that suffice?
Much simpler than SPI
Click to expand...

200 kHz per channel (ultra sonic volumetric beamformer), so bit-rate is 6.4 Mbit (2x 16bit channels @200 kHz)
I'm not sure how fast I could go (dma driven obviously) with serial line. I run teensy at 144 MHz, otherwise processing would be not possible.
I remember some MBit rates reported for serial xfer. Any idea?
 
Also, I am not convinced that the ADC can run that fast. 200kHz at 16 bits seems out of bounds. IIRC, the upper limit for in-bounds ADC operation was somewhere along the lines of 120kHz. Overlocking the CPU may allow you to sample faster, but not at 16 bits of resolution (even then ENOB under best of circumstances is likely 12-13 bits).
 
The USB port is probably the only communication on Teensy capable of sustaining this speed, and doing so with low enough overhead to give you a good chance of continuously acquiring the data while also streaming it to some other board.

If three Teensys are streaming continuously at 400 kbytes/sec, you'll probably need a Multi-TT USB 2.0 hub. Single-TT might not work, even if all 3 Teensys have the bandwidth, and whatever computer or board acts as a USB host to receive the data is fast enough.

The I2S port is might be able to stream data at 200 kHz, at a 100 kHz stereo stream....

I have not personally written code to acquire data at the speed, but the audio library does run the ADC at 8X averaging and gets 44.1 kHz output rate. So that's a good sign at least 352 kHz ought to be possible, when running in 16 bit mode. But this only works when the speed is 48 or 96 MHz. In 72 MHz mode, F_BUS is slower and it fails, which is also a pretty good sign you probably can't go a lot higher than 352 kHz.
 
Actually I'm designing a board that uses a 6 chan ADC (24-bit Cirrus CS4366), that runs up to 216 kHz/channel. It has 3 I2S (SAI) outputs suited for three teensys. So I'm not using onboard ADC, or audiocard.

The CPU speed is needed for processing and is my standard configuration. I mentioned it, because, as I recall, some serial lines are driven by F_CPU.

Concerning maths, well, I may be wrong, but my calculations give 2*16 bit = 32 bit at 200 kHz = 6400 kbit/s = 800 kByte/s minimum speed.

Using spi at 12.5 MHz (max in slave) I get therefore a dutycycle of about 50%. So I have some time to do processing with the transferred data.

So what I'm doing:
On each teensy:
acquire 256 pairs of samples (lasts 1.28 ms)

The standard process would be:
during this 1.28 ms calculate spectra of the acquired data, transfer spectra and process further the transferred, better received spectra.
Data processing is done with 256 point FFTs, with 50% overlap, effectively doubling the number of spectra.

It turned out that estimating spectra is faster than transferring spectra, that is, it is better to not transfer the spectra, but to follow the following scheme:
after acquisition, transfer acquired data to 2nd teensy (using dma), calculate in parallel spectra of acquired data , and after transfer/reception calculate spectra of received data from 3rd teensy and finalize calculations.

So if there is an alternative to the 12.5 MHz bit rate of spi , than I would be very interested to use it.

BTW, processing etc. is solid but I teensy to teensy transfer is not verified and I would not be surprised to encounter some roadblocks.

Edit: the offload from my teensy system is at much lower speed (10-50 kB/second)
 
Last edited:
Status
Not open for further replies.
Back
Top