Send data of 2 teensy 3.2 to 1 teens3.5 with sd card

Status
Not open for further replies.

pluesss

Member
Hi,

For a project we want to connect two Teensy 3.2 to a Teensy 3.5. Both 3.2 are collecting data of ~200 sensors(matrix) with a frequency around 10Hz. These data should be sent to the 3.5, which should save it on an SD card.
I already tried something with SCL/SDA pins, where the 3.5 is the master and the 3.2 are slaves. Following this example: https://www.arduino.cc/en/Tutorial/MasterReader , I first request data from 3.2#1 after I request data from 3.2#2.
This works more or less, but I have a timing problem. Sometimes I receive the same data twice, sometimes I miss one sample(propably depending on when the 3.2 has prepared the new data). Is there a better way to do what I need? Could I do the reading faster? Reading multiple times the same would be useless but easy to discard.

Thank you and best regards.
 
Analog sensor? 2 bytes per sample? 8,000 bytes/second? May need a byte to ID each sensor as well? 12,000 bytes/sec? Much less if a packed array of digital data.

Try connecting Serial 1 of each T_3.2 to Serial 1 and 2 of T_3.5 and read the data - may need to increase the serial Rx buffer on T_3.5 to not lose data during SD card writes.

Perhaps have the T_3.2 hold data until request byte sent to buffer data between SD writes? Could read from both at the same time as the data arrives. Then write to SD and repeat.

If UART wires {Rx, Tx, GND} are short - using baud rate of 2,000,000 - that allows 200,000 bytes per second from each T_3.2
 
Thank you for your answer, and sorry if I gave to little information!

Yes, we have 200 resistive analog sensors. We switch through the columns and rows and read each sensor. We would like to use the 13bits of the Teensy, therefore it would be 2 bytes per sensor --> 2*200*10 -> 4000byte/second per Teensy 3.2. Your 8000bytes is correct, we don't need to ID every sensor. \r\n or something else would be enough.

So RX/TX Serial would be faster than the SDA/SCL? Or is the protocol easier because of the buffering and the extra "datachannel" for every T-3.2?
Is the buffering done automatically? How could I increase the buffersize if it's too small?

I will try that, thank you!
 
send the data from one Teesny to the other and then to the next one using serial ports - you should not loose data this way

so T1 transmits to T2
T2 sends the data from one Serial port to the next along with its own data
T3 recieves all data


Code:
          // Serial passthrough
            // read from port 3, send to port 1:
           if (Serial3.available()) {
               int inByte = Serial3.read();
               Serial.write(inByte);
           }
 
Should be faster - not sure what i2c rate is in use but 2 Mbaud would cover it, both can transmit in parallel and no addressing overhead to select one device while the other waits.

In : T:\arduino_1.8.10\hardware\teensy\avr\cores\teensy3\serial1.c
>> #define SERIAL1_RX_BUFFER_SIZE 64 // number of incoming bytes to buffer

and the same in : T:\arduino_1.8.10\hardware\teensy\avr\cores\teensy3\serial2.c

it seems that can be made reasonably large. But having the T_3.2's buffer and wait until prompted - as they do now - would prevent them sending when the SD card took 1 second to write for some reason - you could send a 'GO' to each and buffer them until they say 'DONE'. Then prep the data for SD write in nice even blocks of 512 bytes - hopefully get done in a couple hundred ms or less and repeat.
 
Thank you both for your answer.

I will try defragster's solution first, as this seems to be more efficient to me. I would be afraid that Gadget999 solution takes too much time on T2, with readinge the data and than sending twice as much. But if I fail, I will try this as well :)
 
Suggestion: If you are going down using two serial ports, suggest using Serial1 and Serial2 over using Serial3/4/5... As the first two hardware ports have larger hardware buffers built in, so they can handle a few more characters coming in if the ISRs are disabled or delayed.

Again I don't know what you have tried or not tried here. As I have not seen any code or ...

But if you are trying to use I2C are you using the Wire library? If so have you tried the i2c_t3 library (https://github.com/nox771/i2c_t3)
Note: I don't use I2C that often so don't know all of the pitfalls and the like...

But if I am looking at his tables and you run T3.2 an 96mhz you can set the speed up to about 2.4M

And again I have not tried it, but with this library, you can I believe setup the Transfers from two different I2C ports to use DMA and as such you can have them going on concurrently with other things. Could potentially have them automatically triggered by timers, or could maybe have another IO pin connected between the boards, and for example when T1 wishes to send data, it could toggle an IO pin, and have the T3.5 have an interrupt handler which starts up the transfer...

Again lots of possibilities.

Good luck.
 
Hi all,

It took me a bit longer, but finally I could try the suggested solution.

It seems to work well with the Serial1 port and increased buffer size.
I still have a bit of a timing problem (probably if T1 is sending new data, when T2 is still reading.) But I think I can solve that by improving my reading "process". If not, I probably try to connect additional digital pins to indicate if a complete dataset is ready to be read.

But I know have another problem sending my data:
I use:
Code:
Serial1.write(sentChars,200);

where sentChars is: uint8_t sentChars[200];

However, if my sensor values are "0" it seems not to print these values correctly, and on the other Teensy I only get the values which are not "0". How can i send the zero values?

Thank you very much for your help.
 
There should be no problem sending 0 in the array. Maybe post your receiving code and I am sure one of the senior Members might be able to spot something.
As a simple test serial.available() returns the number of bytes available, so you can check that you are receiving the 200 bytes.
 
Status
Not open for further replies.
Back
Top