Hi all
I'm currently working on a project using Teensy 3.2 where we have two high speed UART lines set up as One wire half duplex lines.
The setup is similar to RS485 where you need RX, TX and the direction pin. In this case we're working at TTL level so it's the same electrical design minus the RS485 signal shifter.
To the point:
From reading the processor datasheet I can see that a good choice to use as a direction pin is the RTS signal. This is a fairly common implementation and I can see the Teensy processor supports it.
At this point note we're looking at high speed communications (up to 4.5 Mbps) using one wire so our aim is to have a mechanism that shifts the Transmit Enable on and off as quickly as possible and keeps it enabled, for as little time as possible.
This is where I'm getting confused:
- I can see an early Git commit where Teensyduino seems to be using the native RTS implementation in the chip. This commit is here https://github.com/PaulStoffregen/cores/commit/c2f550d3780cba3c49cfc34bab724b268a11b7a6
The downside to doing this si that the RTS pin is basically fixed by the processor so you need to respect it.
The upside is that it seems the processor handles assertion and de-assertion of the RTS line once you configure it to this in the xxx_MODEM register.
- However on the current commit for serial1.c for example, https://github.com/PaulStoffregen/cores/blob/master/teensy3/serial1.c the code of the above commit is commented out and it seems that RTS assertion and de-assertion is being bit banged.
The upside is of course the flexibility in assigning the RTS pin to any digital pin.
The downside is more overhead which is something we're desperately trying to cut down to make sure our timings are right to get all characters and not lose bytes.
My questions are:
1) Why was there a change from using the native RTS mechanism to what seems like a bit banged approach?
At first glance the native approach looks simpler, cleaner and likely more efficient with less overhead, right?
2) Has anyone used the native RTS mechanism? If so, does the processor reliably assert and de assert the lines?
(I know the answer can be biased by the actual hardware design and the time it takes to react to the pin changes, but let's all assume the hardware responds with appropriate speed)
[EDIT] after looking into this a little better, I can see RTS is implemented as a flow control signal in teensyduino (in both variants: either native or bit banged).
I can also see RS485 is handled by the transmitEnable(pin) and that this has now been ported to all serials.
My question persists: the processor has the TXRTSE bit that can make RTS act like a Transmit Enable pin so is there a particular advantage for having it bit banged?
[/EDIT]
Thank you
Pedro
I'm currently working on a project using Teensy 3.2 where we have two high speed UART lines set up as One wire half duplex lines.
The setup is similar to RS485 where you need RX, TX and the direction pin. In this case we're working at TTL level so it's the same electrical design minus the RS485 signal shifter.
To the point:
From reading the processor datasheet I can see that a good choice to use as a direction pin is the RTS signal. This is a fairly common implementation and I can see the Teensy processor supports it.
At this point note we're looking at high speed communications (up to 4.5 Mbps) using one wire so our aim is to have a mechanism that shifts the Transmit Enable on and off as quickly as possible and keeps it enabled, for as little time as possible.
This is where I'm getting confused:
- I can see an early Git commit where Teensyduino seems to be using the native RTS implementation in the chip. This commit is here https://github.com/PaulStoffregen/cores/commit/c2f550d3780cba3c49cfc34bab724b268a11b7a6
The downside to doing this si that the RTS pin is basically fixed by the processor so you need to respect it.
The upside is that it seems the processor handles assertion and de-assertion of the RTS line once you configure it to this in the xxx_MODEM register.
- However on the current commit for serial1.c for example, https://github.com/PaulStoffregen/cores/blob/master/teensy3/serial1.c the code of the above commit is commented out and it seems that RTS assertion and de-assertion is being bit banged.
The upside is of course the flexibility in assigning the RTS pin to any digital pin.
The downside is more overhead which is something we're desperately trying to cut down to make sure our timings are right to get all characters and not lose bytes.
My questions are:
1) Why was there a change from using the native RTS mechanism to what seems like a bit banged approach?
At first glance the native approach looks simpler, cleaner and likely more efficient with less overhead, right?
2) Has anyone used the native RTS mechanism? If so, does the processor reliably assert and de assert the lines?
(I know the answer can be biased by the actual hardware design and the time it takes to react to the pin changes, but let's all assume the hardware responds with appropriate speed)
[EDIT] after looking into this a little better, I can see RTS is implemented as a flow control signal in teensyduino (in both variants: either native or bit banged).
I can also see RS485 is handled by the transmitEnable(pin) and that this has now been ported to all serials.
My question persists: the processor has the TXRTSE bit that can make RTS act like a Transmit Enable pin so is there a particular advantage for having it bit banged?
[/EDIT]
Thank you
Pedro
Last edited: