Constantin
Well-known member
So I discovered the undocumented Teensy 2 feature that automatically enables/disables the DE pin on a RS485 transceiver for transmissions simply by declaring the pin in question when the Serial.begin is called. This feature is brilliant for RS485 communications because it allows a program to fill the serial buffer with a payload, ship it off in background and focus on something else in the meantime. Once the background task has finished, the DE pin is automatically pulled LOW (!!!) and the serial buffer can await the next transmission/receive.
Unfortunately, this feature does not seem to be enabled on the Teensy 3 - when I tried using it, there was no reaction by the DE pin. Paul, if this is on your Teensy 3 wish list, awesome, if not, I totally understand. I'm likely in the total minority re: the auto-on-off DE feature but DMX/Modbus folk would likely be very happy too if RS485 could be as easy as Serial in terms of implementation.
In the meantime, it appears that I have two options to control the RS485 DE pin without losing data - after initiating a transmission by pulling the DE HIGH and squirting serial data into the DI pin on the RS485 transceiver,
I would prefer a non-blocking approach simply because I'd like to keep the CPU busy with other tasks, if possible. But I wonder what the best method is… Perhaps Nick Gammons first stab at the problem where if one can calculate the size of the transmission, one can basically pre-calculate how long it will take, then pull the DE low when the elapsed time has passed? I'll have to see if the structs created by EasyTransfer allow a sizeof calculation to be used on them.
Another question I have is around serial speeds and why folk standardized on the speeds that they have for MCU-MCU communications. Simply multiplying yesterdays modem speeds is counterintuitive when the results are not even clock divisors for MCU's out there. The Atmel 328P spec sheet claims 0% error for 1Mbit/s communications with a 16MHz MCU clock (see page 195) presumably because 1Mbit/s is clean 16:1 clock ratio. I've also used 1Mbit/s between Teensy 3's over RS485 without issues so far. Is there an inherent reason not to use a serial speed that results in zero error if there is no intent to have a Arduino IDE monitor session running?
The only issues I can foresee is the recipient MCU 'missing' the signals due to speed and lack of buffer while busy with something else. I understand HardwareSerial.cpp can be modified to allow up to 255 bytes of buffer, which should be more than any message I intend my units to send to each other. Given how much RAM the Teensy 3.1 has, why not make use of the entire allowed buffer(s)?
Unfortunately, this feature does not seem to be enabled on the Teensy 3 - when I tried using it, there was no reaction by the DE pin. Paul, if this is on your Teensy 3 wish list, awesome, if not, I totally understand. I'm likely in the total minority re: the auto-on-off DE feature but DMX/Modbus folk would likely be very happy too if RS485 could be as easy as Serial in terms of implementation.
In the meantime, it appears that I have two options to control the RS485 DE pin without losing data - after initiating a transmission by pulling the DE HIGH and squirting serial data into the DI pin on the RS485 transceiver,
- Using Serial.flush() in a blocking fashion or
- (in a non-blocking fashion) periodically polling Serial.available() after initiating a transmission to see when the transmission is done
I would prefer a non-blocking approach simply because I'd like to keep the CPU busy with other tasks, if possible. But I wonder what the best method is… Perhaps Nick Gammons first stab at the problem where if one can calculate the size of the transmission, one can basically pre-calculate how long it will take, then pull the DE low when the elapsed time has passed? I'll have to see if the structs created by EasyTransfer allow a sizeof calculation to be used on them.
Another question I have is around serial speeds and why folk standardized on the speeds that they have for MCU-MCU communications. Simply multiplying yesterdays modem speeds is counterintuitive when the results are not even clock divisors for MCU's out there. The Atmel 328P spec sheet claims 0% error for 1Mbit/s communications with a 16MHz MCU clock (see page 195) presumably because 1Mbit/s is clean 16:1 clock ratio. I've also used 1Mbit/s between Teensy 3's over RS485 without issues so far. Is there an inherent reason not to use a serial speed that results in zero error if there is no intent to have a Arduino IDE monitor session running?
The only issues I can foresee is the recipient MCU 'missing' the signals due to speed and lack of buffer while busy with something else. I understand HardwareSerial.cpp can be modified to allow up to 255 bytes of buffer, which should be more than any message I intend my units to send to each other. Given how much RAM the Teensy 3.1 has, why not make use of the entire allowed buffer(s)?
Last edited: