I am writing serial data from a teensy 4.1 and reading it from a windows machine using python and pyserial.
On the teensy side, I have initialized the serial port and am writing a data packet with a header and checksum:
All together I am sending 82 bytes of data in a 100hz loop. Serial baud rate is set to 2000000. On the "receive" side using pyserial, I am simply checking the length of the input buffer in a 100hz loop and clearing it:
I am experiencing two distinct serial buffer behaviors, depending on if I am using the usb Serial, i.e. Serial.write() vs. the teensy hardware serial, i.e. Serial1.write(), Serial2.write(), etc.
USB serial setup and behavior:
print(ser.in_waiting) --> 82 (sometimes 164 if my send/receive de-sync)
print(ser.read_all()) --> my packet
ser.reset_input_buffer()
Teensy hardware serial setup and behavior:
print(ser.in_waiting) --> 0
print(ser.read_all()) --> times out and doesn't read anything because nothing in buffer
ser.reset_input_buffer()
.
.
.
This repeats ~48 times
.
.
.
print(ser.in_waiting) --> 3968
print(ser.read_all()) --> a bunch of my packets
ser.reset_input_buffer()
.
.
.
It appears that the teensy hardware serial is buffering until the output buffer is full, then that is being sent all at once. This doesn't happen with the usb serial. The result on the receive side is not seeing any data in the input buffer for many loop iterations, then getting ~48 packets all at once. Using Serial1.flush() does not change this behavior. I am not using flow control.
Am I going crazy and horribly misunderstanding serial communication basics? Or is this a known behavior? How would I emulate the behavior of the usb serial buffer?
On the teensy side, I have initialized the serial port and am writing a data packet with a header and checksum:
Code:
unsigned char checksum = XORChecksum((uint8_t *) &telemPacket, telemPacketLength); // Create checksum
Serial.write(msg_header); // send packet header
Serial.write((uint8_t *) &telemPacket, telemPacketLength); // Packet
Serial.write((uint8_t *) &checksum, 1); // Send checksum
All together I am sending 82 bytes of data in a 100hz loop. Serial baud rate is set to 2000000. On the "receive" side using pyserial, I am simply checking the length of the input buffer in a 100hz loop and clearing it:
Code:
print(ser.in_waiting)
print(ser.read_all())
ser.reset_input_buffer()
I am experiencing two distinct serial buffer behaviors, depending on if I am using the usb Serial, i.e. Serial.write() vs. the teensy hardware serial, i.e. Serial1.write(), Serial2.write(), etc.
USB serial setup and behavior:
- microUSB from teensy to my windows machine running the pyserial script
- pyserial output looks like this:
print(ser.in_waiting) --> 82 (sometimes 164 if my send/receive de-sync)
print(ser.read_all()) --> my packet
ser.reset_input_buffer()
- this is behavior I would expect!
Teensy hardware serial setup and behavior:
- USB/TTL cable hooked up to teensy 4.1 TX1, RX1 from teensy to my windows machine running the pyserial script
- pyserial output looks like this:
print(ser.in_waiting) --> 0
print(ser.read_all()) --> times out and doesn't read anything because nothing in buffer
ser.reset_input_buffer()
.
.
.
This repeats ~48 times
.
.
.
print(ser.in_waiting) --> 3968
print(ser.read_all()) --> a bunch of my packets
ser.reset_input_buffer()
.
.
.
It appears that the teensy hardware serial is buffering until the output buffer is full, then that is being sent all at once. This doesn't happen with the usb serial. The result on the receive side is not seeing any data in the input buffer for many loop iterations, then getting ~48 packets all at once. Using Serial1.flush() does not change this behavior. I am not using flow control.
Am I going crazy and horribly misunderstanding serial communication basics? Or is this a known behavior? How would I emulate the behavior of the usb serial buffer?