Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: Troubles with RS485 between 2 teensy

Hybrid View

  1. #1
    Junior Member
    Join Date
    Feb 2019
    Posts
    6

    Troubles with RS485 between 2 teensy

    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)

    Click image for larger version. 

Name:	Screen1.jpg 
Views:	12 
Size:	141.0 KB 
ID:	16675
    Click image for larger version. 

Name:	screen2.jpg 
Views:	9 
Size:	147.1 KB 
ID:	16676

    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);
    }
    Click image for larger version. 

Name:	screen3.jpg 
Views:	5 
Size:	143.8 KB 
ID:	16677

    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);
    }
    Click image for larger version. 

Name:	screen4.jpg 
Views:	6 
Size:	149.3 KB 
ID:	16678


    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 by IMI4tth3w; 05-22-2019 at 10:12 PM.

  2. #2
    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/57067...mit-Enable-pin

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

    Best Regards

  3. #3
    Junior Member
    Join Date
    Feb 2019
    Posts
    6
    Quote Originally Posted by pramilo View Post
    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/57067...mit-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.

  4. #4
    Glad to know it's resolved.

    I made a post on the forum explaining how to get the TxEnable pin to be managed by hardware (by the processor).

    This seems to have resolved a LOT of the problems.

    See here https://forum.pjrc.com/threads/57588...484#post215484

    One advantage of that approach is that you don't need to wait on Serialx.flush().

    Best Regards

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •