Serial1.available() seems to fail when first byte is NULL

Status
Not open for further replies.
teensy to teensy, teensy to PC, teensy to scales. all work good. i use the teensy RS232 in many applications, never have any problem what so ever.

And all the codes posted here works rs232 to rs232 between 2 teensy. (after correcting sloppy code faults)

Also as described in my post 72. teensy to teensy with a rs485 converter each works, as long as i have:
delay(5);
digitalWrite(SSerialTxControl, RS485Transmit); (teemsy nr2 code)

break condition maby come from incorrect pullups on the max485 board.
 
Last edited:
teensy to teensy, teensy to PC, teensy to scales. all work good. i use the teensy RS232 in many applications, never have any problem what so ever.
Sounds like something for Paul! I have not used these chips so I would only be guessing.
But looking at the datasheet, I notice that it appears like for typical hookups you need termination resistors at both ends. Example circuit shown on page 13. I also looked at the schematic of the Arbotix Pro which has setup for RS485 to handle Robotis RS485 servos like MX-64r (not the ttl versions like AX-12). In this circuit they are using a MAX3443, but they do show a 120 ohm resistor between the A and B pins.

My guess is you probably already have this, but I did not see it in your diagrams.

Again will bow out as others have much more experience in the electrical side of things.

Good Luck
 
do the teensy UART handle break condition?
Every UART I've seen does. But the driver software may just treat it as yet another kind of receiver error. Whereas serial protocols such as LIN intentionally use breaks. (A UART "break" is taking the serial data line to a spacing state for the duration of the start, data, and stop bits).

https://en.wikipedia.org/wiki/Local_Interconnect_Network

The "break" condition dates back to teletype days. The machine detected this mechanically and took special action, such as "here comes a new message"; it caused the machine to "reset" in case it was left in a certain state like upper case mode, etc.

Most UARTs also have an optionally enabled "inter-frame timeout" or idle time-out. This option causes a UART status bit to be set (and interrupt or cessation of DMA). Purpose of this is to simplify software detecting end of message data for variable length messages, or one at a time characters, etc. Very handy, but it requires the sender to, at high baud rates, not be tardy if a message data block is sent in more than one driver call.
 
Last edited:
Yes, the UART in the Teensy handles break, it has idle detection, receive leading edge detection, and works well with the DMA controller. There are several subtle "gotchas" to watch out for, but once managed, the Kinetis UART/DMA combination is pretty good. In my experience there's some pretty heavy lifting to get past these subtle issues, but once understood and coded well, it does work.

The big issue to watch out for: The UART_S1 register bits (both error and status bits) are cleared by reading first the UART_S1 register then reading the UART_D (data) register. Trouble is performing the D-register read when there's nothing in the FIFO puts the FIFO in an undefined state. There are workarounds but it starts getting subtle in a hurry.

My day job these days involves running the UART/DMA combination flat-out with minimal CPU intervention. It has not been easy, and I've been writing *very* detailed design docs. :)

We have had to move to the FRDM-K64F to get its clock speed and the Ethernet block. I have been wishing for an announcement by Paul of impending release of a Teensy version featuring one of these wonderful chips, due to his attention to detail and well-tempered formfactor choices.
 
Have been quite a while, I finaly managed to get it to work i believe. Recieved a new 232 to 485 converter.
This one does not need the directional flow controll. handles it by "itself" so basicly any uC integrated to the chip/board can use it as it was a normal 232 uart.

Just to try i took on of the old codes i think been used/posted here and gave mucho unstable wierd results. Code is part mine and part friendly forum members sugestions.
It works as soon as i hooked it all up and uploaded the sketch.
ofc. some of the code is not doing anything, but i left it in anyhow.

Code:
#define SSerialTxControl 12   //RS485 Direction control
#define RS485Transmit    HIGH
#define RS485Receive     LOW

#define Pin13LED         13

String senixX = "";


void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  Serial1.begin(115200);
  
  Serial.println("BOOTING!");

  pinMode(Pin13LED, OUTPUT);   
  pinMode(SSerialTxControl, OUTPUT);
  
  //Serial1.transmitterEnable(12);

  digitalWrite(SSerialTxControl, RS485Receive);
  delay(10);
}

void loop() {
  // put your main code here, to run repeatedly:
  qSenix();
  delay(2000);

}

void qSenix() {
  senixX = "";
  byte data[] {0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01};
  unsigned long maxserialdly=50;  // the time we need to wait
  delay(5);  // !!!!!!!!!!!!!!!!!!!!!!!!!!
  digitalWrite(SSerialTxControl, RS485Transmit);  // Enable RS485 Transmit
  //Serial1.flush();
  byte message2[] = {0x02, 0x03, 0x02, 0x08, 0x00, 0x01, 0x04, 0x43};
  Serial1.write(message2, sizeof(message2));

  delay(5);
  digitalWrite(SSerialTxControl, RS485Receive);  // Disable RS485 Transmit
  unsigned long previousMillis=millis(); // millis() returns an unsigned long.
  //delay(15);   // Small delay to make sure all data sent from senix sensor have been sent before trying to read all. at 115200baud this way more then enough time.
 
  int i = 0;
  while((i < 8) && ((unsigned long)(millis() - previousMillis) < maxserialdly) ) {
    int  inChar = Serial1.read();
    if (inChar != -1) {
      data[i] = inChar;
      i++;
    }
  }
  Serial.println("Start:");
  Serial.println(i, DEC);   // See how many bytes we actually read
  Serial.println((int)(millis() - previousMillis), DEC); // how long it took.
  Serial.println(data[0], BYTE);
  Serial.println(data[1], BYTE);
  Serial.println(data[2], BYTE);
  Serial.println(data[3], BYTE);
  Serial.println(data[4], BYTE);
  Serial.println(data[5], BYTE);
  Serial.println(data[6], BYTE);
  Serial.println(data[7], BYTE);
  Serial.println("STOP");

}

it should output
7bytes (the sensor returns 7 bytes) exept my diagnostic texts
Start: diagnostic printout OK
7 Number of bytes recieved OK
50 milliseconds passed OK
stx OK
etx OK
stx OK
! OK
af OK
as OK
fb OK
soh OK
STOP diagnostic printout OK


the data is all low "numbers" so the terminal program translate them to there ascii thingy.
 
Status
Not open for further replies.
Back
Top