Serial communication issue between nano and teensy 3.2: reading unexpected zeros

Projects Programming
1

Hi everyone,

The following programs do a non-stop communicaction between a nano and a teensy 3.2 chips.

The problem is that teensy reads unwanted zeros among expected received data from nano. And my question is how to remove/avoid them? Ther rest works ok -Nano receives always ok-.

I want to say in advance, that this code is tested and works usind two nanos in two differents boards, and I'm doing all tests with the same and only one power supply feeding the circuits. Teensy is using Serial1 rx/rx pins (0 and 1).

Let me explain what program do. Teensy starts sending and nano receiving. Steps:

  1. Teensy send a Serial1.write(7) and then waits for a incoming data
  2. Nano receives a 7 and print it in a lcd display
  3. When nano incoming buffer becomes empty again, send three numbers via Serial.write() -8, 2 and 47- and then waits for a incoming data again
  4. Teensy receives "some data", show it via serial monitor -don't have lcd display for them, and when its incoming buffer is empty again the program goes to point 1

The problem is in Step 4, teensy reads unwanted zeros. Let me explain to us all differents cases I tested:

  1. With code as I sent to you, this is what serial monitor shows: Two non-wanted zeros always come before the data we are expecting for

****** 0 0 8 2 47 ****** 0 0 8 2 47 and in bucle

  1. Based in initial code, If I put a Serial1.flush() after sending data in teensy -not in nano-, same result as point 1
     Serial1.write(7);
     Serial.flush();
     delay(2);

  1. Based in initial codes, If I put a Serial.flush() after sending data in nano -not in teensy-, same result as point 1

  2. Based in initial codes, If I put a Serial.flush() and Serial1.flush() in nano and teensy after sending data, same result as point 1

  3. Based in initial codes, If I change the delay(200); after Serial1.read(); in teensy to delay(10);, still same two zeros received

****** 0 0 8 2 47 ****** 0 0 8 2 47 in bucle

  1. Based in code changes from point 5, If I add some Sreial.write() i nano part:
      Serial.write(8);
      Serial.write(2);
      Serial.write(47);
      Serial.write(0);
      Serial.write(255);
      Serial.write(6);
      Serial.write(0);
      Serial.write(98);

Then the result is only one unwanted zero at the begining of each pack:

****** 0 8 2 47 0 255 6 0 98 ****** 0 8 2 47 0 255 6 0 98 ****** in bucle

  1. Based in code changes in point 6, if I change current delay(10); after Serial1.read() in teensy, for a delay(2);, then serial monitor show that all data received in teensy is a lonely unwanted 0, and only one for each pack:

****** 0 ****** 0 ****** 0 in bucle

  1. Based in code changes in point 7, if I put a Serial1.flush() and Serial.flush() as did in points 3 and 4, seems that Serial colapses at third pack of data sended from nano:

****** 0 ****** 0 ****** 0 and no more data showed

  1. Based in point 7, if I change baud rate from 38400 to 115200 in both chips with Serial1. begin(115200); and Serial.begin(115200) -with delay(2) after reading in teensy-, same result as point 7 is showed in serial monitor

****** 0 ****** 0 ****** 0 in bucle

  1. Based in point 9, if I change delay(2) to delay(10); again after reading in teensy, same result as point 6 but including two initial unwanted zeros as in point 5, instead of only one

So my question again: how to remove these zeros that we don't expect and in addition they don't show up neither with the same amount nor order? I'm sure that if I do more test probably they show up in the middle or at the end of each data submit, not only at the begining

Very thankful to every one.. I'm really stuck on this

SerialCom_NanoPart.ino (2.74 KB)

SerialCom_Teensy32Part.ino (2.17 KB)

2

not sure, but at 9600 bps, it takes 1 msec to send on char

why do you have a 200 msec delay after reading?

            data = Serial1.read();
            delay(200);
3

gcjr:
not sure, but at 9600 bps, it takes 1 msec to send on char

why do you have a 200 msec delay after reading?

            data = Serial1.read();

delay(200);

Just to see that this delay does not seem to be the problem. With small delay does not work, so I started slowing down communication (200) and then -as you can see in tests performed- reducing delay to 2 msec.

4

Hi,

seems to me, you only have trouble, when reading data from the teensy?

Did you check the data stream from the teensy on an Osci?

Maybe, there is a mild timing missmatch?

Or the teensy sends two stop bits?

Just a thought.

BR

5

Just to see that this delay does not seem to be the problem. With small delay does not work, so I started slowing down communication (200) and then -as you can see in tests performed- reducing delay to 2 msec.

i can possibly see a need to throttle transmission but can't see any reason why delaying reading would help. delays are inevitable when there's nothing available.

one reason asynchronous communication is only at most 11 bits is to accommodate +/- 2% clock differences (i.e. 4%) between tx and rx. this seems to have worked reliably for decades

6

Have a look at the examples in Serial Input Basics - simple reliable non-blocking ways to receive data. There is also a parse example to illustrate how to extract numbers from the received text.

The technique in the 3rd example will be the most reliable. It is what I use for Arduino to Arduino and Arduino to PC communication.

You can send data in a compatible format with code like this (or the equivalent in any other programming language)

Serial.print('<'); // start marker
Serial.print(value1);
Serial.print(','); // comma separator
Serial.print(value2);
Serial.println('>'); // end marker

Another option would be to use I2C and the Wire library (assuming the Teensy supports it).

...R

7

Klausi1967:
Hi,

seems to me, you only have trouble, when reading data from the teensy?

Did you check the data stream from the teensy on an Osci?

Maybe, there is a mild timing missmatch?

Or the teensy sends two stop bits?

Just a thought.

BR

Hi,

Indeed, unexpected zeros appears only when reading form teensy. The rest runs ok

Unfortunately I don't have an Osci

I don't think this is a teensy stop bits matter, because someteims two zeros appears, sometimes only one

8

gcjr:
i can possibly see a need to throttle transmission but can't see any reason why delaying reading would help. delays are inevitable when there's nothing available.

one reason asynchronous communication is only at most 11 bits is to accommodate +/- 2% clock differences (i.e. 4%) between tx and rx. this seems to have worked reliably for decades

I already throttle the transmission up to delay(1), but serial monitor shows same zeros issue

So as I think you say, maybe more or less delay does not make the zeros issue appears

9

Robin2:
Have a look at the examples in Serial Input Basics - simple reliable non-blocking ways to receive data. There is also a parse example to illustrate how to extract numbers from the received text.

The technique in the 3rd example will be the most reliable. It is what I use for Arduino to Arduino and Arduino to PC communication.

You can send data in a compatible format with code like this (or the equivalent in any other programming language)

Serial.print('<'); // start marker

Serial.print(value1);
Serial.print(','); // comma separator
Serial.print(value2);
Serial.println('>'); // end marker





Another option would be to use I2C and the Wire library (assuming the Teensy supports it).

...R

Hi Robin2,

Thanks for the link, this is very interesting

By the moment I only read the "3rd example". In a "full mode" code, I already have an initial two characters an an end character to recognize when any wanted instruction starts, to run my applications.

And this should avoid the zeros is these cases, right? But, what if zeros start to apperar in a middle of a given instruction? For example, if we send and what we receive is 0, and the receiving part does not know at first that the text must be "hello"

The main goal as far as possible for me, is find a solution that make zeros dissappear, the same way as serial is running between two nanos in my case

10

Bonetky:
And this should avoid the zeros is these cases, right? But, what if zeros start to apperar in a middle of a given instruction? For example, if we send and what we receive is 0, and the receiving part does not know at first that the text must be "hello"

The main goal as far as possible for me, is find a solution that make zeros dissappear, the same way as serial is running between two nanos in my case

I don't have a Teensy and I don't know what is causing the zeros. I am suggesting that you try the code in my example to see if it solves the problem.

...R