Troubles with RS485 between 2 teensy

Status
Not open for further replies.

IMI4tth3w

Member
Hello,

I will try and explain as simply as possible.

I am working on a project that has two teensy 3.5's connected using half duplex rs485.

Below are some scope shots of what is happening.

Yellow = Master Teensy TX (Pin 1)
Aqua = Master Teensy TX Enable (Pin 15)
Purple = Slave Teensy RX (Pin 0)
Blue = Slave Teensy TX Enable (Pin 15)

Screen1.jpg
screen2.jpg

You can see that for some reason the TX enable is not working correctly after the first "packet" is sent.

If i add some delay between the "Serial1.write()" functions that happen in my main program, this issue does not occur.

I have tried to re-create the issue in a much more simple version of the program.

Here is my simple program
Code:
#define RS485_TX_ENABLE_PIN 15
#define RS485_BAUD_RATE 6000000 // 6MHz baud rate

void sendSomeData(uint8_t theData);

void setup() {
  Serial.begin(9600);
  Serial1.transmitterEnable(RS485_TX_ENABLE_PIN);
  Serial1.begin(RS485_BAUD_RATE);
  Serial.println("Setup Complete");
}

void loop() {
  static elapsedMillis loopTime;
  if(loopTime >= 1000)
  {
    loopTime = 0;
    
    uint8_t count = 0;
    sendSomeData(count++);
    sendSomeData(count++);
    sendSomeData(count++);
    sendSomeData(count++);
  }
}

void sendSomeData(uint8_t theData)
{
  uint8_t someData[3] = {0x03, 0x01, theData};
    Serial1.write(someData, 3);
}

screen3.jpg

This simple code works as expected, and requires no delay between Serial1.write() functions.

One "fix" i've found is making a call to Serial1.flush() before i make a call to Serial1.write() in my main program. But it seems like any sort of delay i add will "fix" the TX Enable output and it will work as expected. But as we can see from the simple code i uploaded, this delay is not needed for proper functionality.

Any ideas what could be going on in my main program? Is some funky stuff going on with the ISR?





AND

Just to be thorough, i modified my simple code to more closely mimic what is happening in my main code. Works just fine.
Code:
#define RS485_TX_ENABLE_PIN 15
#define RS485_BAUD_RATE 6000000 // 6MHz baud rate

void sendSomeData(uint8_t theData);

void setup() {
  Serial.begin(9600);
  Serial1.transmitterEnable(RS485_TX_ENABLE_PIN);
  Serial1.begin(RS485_BAUD_RATE);
  Serial.println("Setup Complete");
}

void loop() {
  static elapsedMillis loopTime;
  if(loopTime >= 1000)
  {
    loopTime = 0;
    
    uint8_t count = 0;
    sendSomeData(count++);
    delayMicroseconds(4);
    sendSomeData(count++);
    delayMicroseconds(4);
    sendSomeData(count++);
    delayMicroseconds(4);
    sendSomeData(count++);
  }
}

void sendSomeData(uint8_t theData)
{
  uint8_t someData[3] = {0x03, 0x01, theData};
    Serial1.write(someData, 3);
}

screen4.jpg


The main code is much more complex, but certainly not doing anything funky with low level hardware registers.

Some of the other libraries i am using are:
spi4teensy3
WS2812Serial
circularBuffer
i2c_t3

So there might be some incompatibilities between some libraries. Thats the next thing i'm going to test. But i've been at this long enough to pick the brains of you fine people lol
 
Last edited:
Hi

I'm not sure if you ever got around to resolving this.

I myself also encountered problems with the timing of the TX Enable pin. There's a long thread here https://forum.pjrc.com/threads/5706...nsy-3-2-Serial-when-using-Transmit-Enable-pin

If you resolved the issue, please let me know as we're still struggling with this.

Best Regards

Hi pramilo,

I have not gone into near the research as you have in dealing with this matter.

So far my solution as been to use a "Serial1.flush()" function in addition to a "delayMicroseconds(100)" before using "Serial1.write()".

Sadly this is really more of a hack fix, but I've had zero instances of issues after adding this to my code after millions of successful writes.

Honestly wish i could go to the stm32, but there's just not time for porting all the code i am using as well as re-writing the libraries i am using. Maybe sometime in the future.
 
Status
Not open for further replies.
Back
Top