RichardFerraro
Well-known member
Is it possible to configure the Teensy 3.1 Serial1 port to perform hardware flow control ?
thanks,
Richard
thanks,
Richard
XBEE and Teensy3.1 hardware flow control
- Thread starter RichardFerraro
- Start date
- Status
KurtE
Senior Member+
I looked a little over the hardware spec and I believe the hardware can support flow control. But I am not dug deep enough to tell you which of the IO pins can be configured for RTS or CTS. Also I am pretty sure that the current code base has no support built-in for these. That is I do not see any code that when it receives new data and adds it to the queue, that it detects that the input queue is almost full and assert the appropriate signal.
I have manually used flow control with XBees on some other processors before and the Phoenix Hexapod code base has this built-in. I used it in both transparent mode and binary mode, but was needed for a very specific reason. Mostly when I needed to use a SoftwareSerial when I needed to do IO to another device(example SSC-32 servo controller). Example with Basic Micro(Bap28/Arc32), their software serial did not disable interrupts and receiving interrupts at the wrong time would corrupt the data, especially at higher speeds like 115200... On other processors like Arduino the SoftwareSerial would disable interrupts and ran a slower speeds(38400) and there were times when data from XBee could be lost as another byte would come in before the previous one was processed)... So again I handled this manually. I would simply wire up another IO line to the appropriate pin on the XBee, plus configure the XBee for flow control, and before I wanted to output the SSC-32, I would assert the condition to the XBee to stop transmitting, when I was done sending to the SSC-32, I would then release the condition on the XBee which would allow it to start sending me data again. Since the XBee has it's own buffering, I would not lose any data. Side note: when you signal the XBee, it may still send you up to two more characters, so my code base needed to handle that...
If this is the level of control you need it is pretty simple to setup.
Kurt
I have manually used flow control with XBees on some other processors before and the Phoenix Hexapod code base has this built-in. I used it in both transparent mode and binary mode, but was needed for a very specific reason. Mostly when I needed to use a SoftwareSerial when I needed to do IO to another device(example SSC-32 servo controller). Example with Basic Micro(Bap28/Arc32), their software serial did not disable interrupts and receiving interrupts at the wrong time would corrupt the data, especially at higher speeds like 115200... On other processors like Arduino the SoftwareSerial would disable interrupts and ran a slower speeds(38400) and there were times when data from XBee could be lost as another byte would come in before the previous one was processed)... So again I handled this manually. I would simply wire up another IO line to the appropriate pin on the XBee, plus configure the XBee for flow control, and before I wanted to output the SSC-32, I would assert the condition to the XBee to stop transmitting, when I was done sending to the SSC-32, I would then release the condition on the XBee which would allow it to start sending me data again. Since the XBee has it's own buffering, I would not lose any data. Side note: when you signal the XBee, it may still send you up to two more characters, so my code base needed to handle that...
If this is the level of control you need it is pretty simple to setup.
Kurt
RichardFerraro
Well-known member
I have an xBee on Serial1 and another on a com port of PC.
I am slugging through the encoder/decoder for both C (Teensy 3.1 code) and C# (my host code) for receiving and transmitting packets to/from the xBEE in API (escaped) mode. I think I am close. Programming with no waiting creates some complicated state machines.
digi has conflicting information on how to handle the ESC codes and (to my knowledge) no tool that works correctly for generating and transmitting API packets in escaped mode.
digi says use hardware flow control to eliminate the escaped mode.
Thus, I am interested in the hardware flow control for the Teensy 3.1 - xBee, but will finish the encoder/decoder first.
thanks,
Richard
I am slugging through the encoder/decoder for both C (Teensy 3.1 code) and C# (my host code) for receiving and transmitting packets to/from the xBEE in API (escaped) mode. I think I am close. Programming with no waiting creates some complicated state machines.
digi has conflicting information on how to handle the ESC codes and (to my knowledge) no tool that works correctly for generating and transmitting API packets in escaped mode.
digi says use hardware flow control to eliminate the escaped mode.
Thus, I am interested in the hardware flow control for the Teensy 3.1 - xBee, but will finish the encoder/decoder first.
thanks,
Richard
- Status