USBHost_t36 Mouse.ino example "baud rate" question

Status
Not open for further replies.

W5UXH

Member
This is just a curiosity but I would like to have some understanding of what is going on.

I am just getting started with the Teensy 3.6 and very pleased with the Mouse.ino example. It works well and I have used it with a terminal emulator (ZOC) on MacOS to record the keycodes for every key press. I had to comment out the "wait for Arduino Serial Monitor" since I am not using that tool and realized that was why nothing seemed to work at first.

I have one dumb question and assume the answer is some basic piece of information that I am missing. I have read on PJRC the following:
Serial.begin( )
Initialize the Serial object. The baud rate is ignored and communication always occurs at full USB speed.

I do not find Serial.begin used anywhere in the sketch, which is part of my confusion, but the main thing is: how does the terminal emulator know to ignore the baud rate that I configure it for? I suppose it must somehow detect that rather than a FTDI type of interface it is the full USB speed interface? Pretty handy in any case.

I tested it on Ubuntu with PuTTY to make sure PuTTY is also "happy" at any configured baud rate.

I will appreciate any information to help me understand this.

Thanks,

Chuck
 
Unlike other Arduinos, Teensy uses a real USB connection. SImpler Arduinos have a chip that communicates via serial with the cpu (It translates USB to serial and therefore uses the baudrate-setting) - The teensy does not need this - it has usb-hardware inbuilt and does not need a baudrate (and indeed ignores it completely). Communication happens with USB Speed and ways faster than with the extra chip. The baudrate setting is just for Arduino compability.

Of course, the Teensy serial UARTS use the baudrate.
 
how does the terminal emulator know to ignore the baud rate that I configure it for? I suppose it must somehow detect that rather than a FTDI type of interface it is the full USB speed interface?

Ordinary terminal emulator software on your PC doesn't know, but the device driver on your PC does. The difference between real serial and USB virtual serial happens in the device driver.

With USB virtual serial, the driver takes whatever data you write and just sends it as-is over the USB cable to the USB device. If your terminal emulator changes the baud rate or handshake signals (DTR, RTS), the driver packages up those changes into messages (or "control transfers" in USB lingo) and sends them over USB to the device side. Whatever's USB device is on the end of the cable is responsible for actually doing something with those messages. Real USB-serial chips control pins. Teensy puts those bits into memory, so you can read them if you like. Teensy also puts the baud rate the PC requested into memory and you can read it with Serial.baud(), which normally you don't need, but it very handy if you want to actually program Teensy to work as a USB-serial converter (File > Examples > Teensy > USB_Serial > USBtoSerial).

The driver assumes hardware on the device side will take the incoming data from your PC and actually send it at the configured baud rate. USB has very reliable flow control built into its protocol (called "bulk transfer" in USB speak). This flow control is completely separate from the virtual RTS & CTS signals, which are emulated by sending USB messages when those hardware signals change. The USB flow control is baked into the low levels of the USB protocol and applies to all USB devices, not just USB serial. This flow control is the essential ingredient that makes all the USB serial work between fast software and slow hardware. Your PC could send much faster than the configured baud rate, and tries to do so, but the flow control ultimately paces the data so the small buffer on the device side doesn't overflow.

Likewise on the device side sending data to your PC (called "host" in USB lingo), flow control is used at the USB protocol level which manages when data packets (called "tokens" and "transfers" in USB) are actually sent. So it's possible for Teensy to send very fast. You'd think a multi-GHz multi-core CPU with gigabytes of RAM wouldn't be the limiting factor, but sometimes it can be, especially when the receiving software is redrawing a GUI. Even in those cases, the overall speed is usually so much faster than ordinary serial.

Nothing on either USB side actually enforces or even bothers to check the data rate corresponds to the configured serial baud rate. The actual data rate is all determined by the USB bulk transfer protocol's flow control, so you get the actual hardware speed, or speed limit imposed by your software, or all the available USB bandwidth, whichever of those 3 is slowest. When the hardware speed is just software on a pretty fast microcontroller like Teensy, and the software on your PC side doesn't suck, often you tend to get speed limited only by the USB bandwidth.
 
Thanks Paul (and Frank), exactly what I was looking for. Still mostly over my head but understandable enough to take care of my curiosity.
 
Status
Not open for further replies.
Back
Top