Teensy Hardware Flow Control RTS/CTS

I've given 1.26 beta 2 a try, but it failed to compile my sketch..

That is probably as I also upgraded form arduino 1.6.5 to 1.6.6 ,
that will teach us to do two changes at once.

I should get time tonight to try the new serial , I have a test app already for the old serial.
Any pointers on the rts / cts, how do I define and what pins do I need to use on teensy 3.2 ?
 
Ok, that looks like my code, but with removed macro , i'll setup my test-scenario again and do some tests.
I'll the teensy-lc too.

Frank.
 
Yup, you implemented it pretty much the way I'd imagined. I followed your patch as I redid the additions, which really helped save time! :) But I did change it to high/low watermark approach. Apart from some syntax changes, like not using the macro for the size calculation and comparison, it's pretty much the same.
 
my reason for the macro was, that i used the same code several times and i had to change only one line for tests :)
your version is better readable, for sure.
 
Should I leave this RTS/CTS stuff in Serial1 for the final 1.26 release?

Anyone have any final thoughts? I want to make the release later today!
 
PaulStoffregen said:
Should I leave this RTS/CTS stuff in Serial1 for the final 1.26 release?

Anyone have any final thoughts? I want to make the release later today!
Click to expand...

For me, it's ok.
But i would like to hear "final thoughts", too..

As long as the interface stays the same, you can change it anytime.
 
The RTS/CTS code made it into the final 1.26 release, but only for Serial1.

I'm looking for feedback.... should I replicate it to Serial2 and Serial3, or are there issues to be resolved first?
 
PaulStoffregen said:
The RTS/CTS code made it into the final 1.26 release, but only for Serial1.

I'm looking for feedback.... should I replicate it to Serial2 and Serial3, or are there issues to be resolved first?
Click to expand...

just what I needed for some Iridium hardware !
Currently I am using Serial , and Serial2 in that application, I can only guess that Serial == Serial1 ?
Anyway - it's a great feature , and I'd like to see the option for all ports.
Thank you
 
On Teensy, "Serial" is always the USB virtual serial connection to your PC.

Serial1, Serial2 and Serial3 are the hardware serial ports.

Currently only Serial1 has the latest RTS/CTS flow control code. As you can see from this thread, it probably works. I don't know if the lack of feedback means very few people have tried it, or if it works well and "no news is good news".
 
Paul
can you post link to the doc on the new pins please,
in particular, how to specify which pins are rts and cts
thanks
 
I started on a project that requires hardware flow control (for Iridium modem)

Anyway: the mavlink library https://github.com/diydrones/ardupilot/tree/master/libraries/GCS_MAVLink/include/mavlink/v1.0
sends data like:
MAVLINK_HELPER void _mavlink_resend_uart(mavlink_channel_t chan, const mavlink_message_t *msg); (from protocol.h in the library)
_mavlink_send_uart(chan, (const char *)ck, 2);

my question is, will that call even work with hardware flow control ?

And I am stuck at this issue: https://github.com/AndKe/Mav2Iridium/issues/1 - this illustrates better what I am trying to do, and describes the result..
 
I've updated the web page with RTS & CTS documentation.

http://www.pjrc.com/teensy/td_uart.html

Please remember we *still* don't have flow control on Serial2 & Serial3, due to lack of feedback. I really hope a few more people will eventually report success (or issues) with using it on Serial1.

For your Mavlink project, in theory this should work. All you have to do is call Serial1.attachRTS() and Serial1.attachCTS() after that code has as started using the serial port. Assuming your Mavlink device has proper RTS and/or CTS signals, it ought to work.
 
@paul, you tested it, i'm continously using it (ok, the same INO evry time), others in this thread don't answer - which means it works (they'd complain, if not)
 
If I use an library that does something like this:
Code: 
static inline void comm_send_ch(mavlink_channel_t chan, uint8_t ch)
{
    if (chan == MAVLINK_COMM_0)
    {
        uart0_transmit(ch);
    }
    if (chan == MAVLINK_COMM_1)
    {
    	uart1_transmit(ch);
    }
}
 
#endif /* YOUR_MAVLINK_BRIDGE_HEADER_H */

...will it still use HW flow control or not ?
 
Not sure, Andre, you are not showing the rest of your code, the setup portion in particular.

However, assuming you have set the RTS and CTS pin as part of your Serial initialization in setup(), i.e. Serial1.begin(), Serial1.attachRts(pin), Serial1.attachCts(pin), etc. then I'd like to think so. One thing to keep in mind is that the choice of CTS pins on the 3.2 is currently restricted, i.e. per Paul "Serial1 supports pins pins 18 & 20. Serial2 supports pin 23. Serial3 supports pin 14.", see the UART page for more info. The LC currently offers no CTS pin function, which is the main reason I have had to redesign my power board to use the MK20 instead.

Last but not least, if you are considering using RTS/CTS with a device like the XBee, read the data sheet carefully. The XBee for some reason has reversed the labeling on the CTS/RTS pins. Normally, one connects RTS to CTS just as RX goes toe TX but Xbee doesn't follow that convention for RTS/CTS (though it does for RX/TX).
 
If your modem deasserts its RTS signal, telling the CTS pin on Teensy to stop transmitting, the code inside Serial1, Serial2, Serial3 will stop sending.

Teensy still has a transmit buffer, between 39 to 63 characters capacity. Your writes will keep going into the buffer. When that's full, Serial1.print() or Serial1.write() will wait for space in the buffer, which can't happen until the signal on Teensy's CTS pin says it's ok to transmit again.

If your program needs to do other stuff and can't accept Serial1.write() waiting, you should call Serial1.availableForWrite() to find out how much room is available in the transmit buffer. Then you can decide whether you want to write. If you write more than whatever that function says the buffer can take, your write will have to wait.

Hopefully this helps?
 
but will uart0_transmit(ch); be affected at all by the flow control , or will it just bang out the data regardless ?
- I just suspect that Serial1.write() and such are functions you have modified, while uart0_transmit(ch) is kind of lower-level thing - or am I wrong ?
 
So today I had to reinstall teensyduino so I figured I'll use the default serial1 that comes with 1.27. It did not work. I think using software to control RTS is not able to keep up. I renamed the serial1_doughboy.txt to serial1.c and recompiled, and the serial transfer worked perfectly.
The program is a webduino webserver using esp8266 at 4.6Mbit and serves files from SD card.

For anyone using Serial1 hardware handshake, if you are getting unexplained data transfer errors, you may want to try the version that uses true hardware handshake.

https://youtu.be/AcnuqPRWf3Y
 
How can I help...?

PaulStoffregen said:
I've updated the web page with RTS & CTS documentation.

http://www.pjrc.com/teensy/td_uart.html

Please remember we *still* don't have flow control on Serial2 & Serial3, due to lack of feedback. I really hope a few more people will eventually report success (or issues) with using it on Serial1.

For your Mavlink project, in theory this should work. All you have to do is call Serial1.attachRTS() and Serial1.attachCTS() after that code has as started using the serial port. Assuming your Mavlink device has proper RTS and/or CTS signals, it ought to work.
Click to expand...

Paul (and others): I believe I might actually need to use RTS/CTS on my current project, and I'd love to use that to help you test it! I've got Serial2 on a Teensy 3.6 connected to Serial1 on a Teensy 3.2. Ideally, the way these things will (eventually) be parked on their circuit board, it'd be wonderful to use Serial5 (pins numbered 33 and 34) on the Teensy3.6 because there are lots of pins I'm not using directly adjacent to them that I could assign to RTS/CTS duty. It'd be right next to the Teensy 3.2. For that matter, I could even go into Serial3 on the Teensy 3.6 and get shorter board traces. I've been skimming your thread here (and understanding *some* of it). From what I gather, actually *using* the flow control is nothing more than declaring the functions of the pins, connecting them, and then using them? Do you have an example I could look at or modify as a starting point?
 
ariesboy571 said:
Paul (and others): I believe I might actually need to use RTS/CTS on my current project, and I'd love to use that to help you test it! I've got Serial2 on a Teensy 3.6 connected to Serial1 on a Teensy 3.2. Ideally, the way these things will (eventually) be parked on their circuit board, it'd be wonderful to use Serial5 (pins numbered 33 and 34) on the Teensy3.6 because there are lots of pins I'm not using directly adjacent to them that I could assign to RTS/CTS duty. It'd be right next to the Teensy 3.2. For that matter, I could even go into Serial3 on the Teensy 3.6 and get shorter board traces. I've been skimming your thread here (and understanding *some* of it). From what I gather, actually *using* the flow control is nothing more than declaring the functions of the pins, connecting them, and then using them? Do you have an example I could look at or modify as a starting point?
Click to expand...

Oh, i've read of some people using RTS/CTS and did not hear any "it does not work" (besides doughboy) . I'm using it too, without problems and without transfer problems with more than 4 MBit. If you run into problems, please report!
Yes, just declare & connect.
 
Last edited:
You must log in or register to reply here.
Back
Top