teensy 3.2 serialEvent3 read have bug

Hi
the following code use to detect endline receive only works with using '\r' test end line and not works with '\n'...
Notice it work perfectly with same function used on serial1 and serial2 with '\n' on the same teensy and same time... (test with same conf gtk_terminal under UnbuntuMate 18.04LTS)
I have pass many hours to found it!

Code:
void serialEvent3() {
  //Serial3.println("deb ev3.") ;
  while (Serial3.available()) {
    //Serial3.println("recup char ev3.");
    // récupérer le prochain octet (byte ou char) et l'enlever
    char inChar3 = Serial3.read();
    inputString3 += inChar3;
    //Serial3.println(inChar3) ;
    // caractère de fin pour notre chaine
    if (inChar3 == '\r') {  //doesn't workswith '/n'
      
      stringComplete3 = true;
      //Serial3.print("fin de recup.");//
      //Serial3.println(inputString3);
      //Serial.println("fin ev") ;
    }; 
    };
  };//serialEvent3()

What's happens ?
Laurent.
 
Last edited by a moderator:
Sorry I am not sure what might be going on here.

I don't know that terminal program so don't know if you configure it for what line ending chraracter(s) are sent.

Serial1 and Serial2 have a larger hardware FIFO buffer than the other Serial ports. So requires more interrupts to processes , so is it possible it missed the data?

Again I have no ideas what might be happening here, as none of the underlying SerialX code cares at al about if a character is \r or \n...

I get the impression you said it worked before? When? Which version of Teensyduino? Which version are you running now?
 
The same code basically runs all the UARTS with some classy CPP code. Not sure why it would act differently?

A complete sketch showing the issue would allow somebody to confirm and look into it. It would also answer things like baud rate tested. Also if interrupts are active or buffer could overflow given the amount of data transferred.

Note is that Serial3 on T_3.2 does not have a large FIFO for transfer - Serial3 takes an interrupt for each complete byte. Also the default buffer size on Serial3 is likely smaller 40 bytes than perhaps 64?

Would seem for some reason the '\n' is not transmitting or ending up being received?

Set up #define names for UART1 and UART2 and have them send and receive a test string and then physically cross connect those ports to connect as needed.

if Serial3 to Serial 2 ( or #1 ) worked to receive running the same transmission code where Serial2 ( or #1 ) to Serial3 did not that would be something to look at.
 
Back
Top