Using Teensy 4.0's Serial, SerialUSB1 and SerialUSB2 [closed]

Question

I see that Teensy is capable of triple USB serial, Although I am not sure what that means. I assume that I can transmit data over one serial while using the other serials for control/command messaging?

1. How does this show up on windows, it still looks like one COM port
2. How do I see messages from SerialUSB1 and SerialUSB2? The print statements from both seems to go into void. Whereas the ones from Serial shows up on the serial monitor (From Arduino IDE)
3. Is there a good documentation that i could follow to understand parallel serial usage.
4. What are the designed use cases for all the new modes available on Teensy 4.0

Answer 1

In dual/triple serial mode the Teensy implements a composite USB device consisting of 3 CDC-ACM (virtual Serial) devices. In Windows they will show as 3 different serial ports with dedicated COM Port numbers.

TyCommnander (Alternative uploader) handles these modes nicely and opens a dedicated serial monitor for each of the ports. (it is generally much more useful as the stock uploader)

As for your question about the use cases: The multiple serial modes are especially useful if you have a PC application which communicates with your Teensy over the main serial port. I.e. it sends commands, receives results etc over this port. If you now want/need some debugging/logging information it is really convenient to use the second port for that and monitor debug messages on a standard terminal (or tyCommander). You can do something like that:

Stream& control = Serial;
Stream& debug = SerialUSB1;
//...
void someFunction()
{
  control.println(someData);                       // send data to the PC over the main communication channel
  debug.printf("%d sent some data\n", millis());   // send some debug info on the debug channel
  //....
}

You find more information and example code in the Teensy user WIKI: https://github.com/TeensyUser/doc/wiki/Serial

Answer 2

that far i can see the Teensy board comes in various flavors. you thus might refer to a microcontroller board with an ARM M4 processor core built in and a bunch of peripherals also in the same housing, including a few serial ports (seen up to 6 such units in one data sheet). further there is some USB functionality on board for interfacing with a PC.

there might be a little misunderstanding on your side - lets point it out:

your PC is a computer. your Teensy board is a computer. The PC acts as a USB host. The Teensy board acts as a USB device (at least that would be the normal case) and for this it reports as being sort of a (often freely selectable) device type. common device types are HID devices for mice, keyboard and more, printers, cameras, networking adapters and many more. its software defined what the Teensy board offers on the USB port - thus get the right firmware and you can have a bunch of options what the PC thinks the board is. - i assume it can behave like those many (FTDI or Prolific provided chips for a) USB-to-serial converter. but those device don't have much of a processor inside. your chip is different! data received from the USB port will end up in the memory space of the embedded processor device. its up to the embedded processor to do something useful with those data. its up to you teaching those processor what to do (unless there is a stock program that already does it).

you can most probably pretend to be a single (but i assume: not multiple!) serial port on USB and then let the embedded processor hand over data in both directions between USB and one (or more, broadcast) of the real serial ports. or the processor can just read/understand the data and do something else... for example evaluating a transmission/encapsulation protocol. this can do things like having a port prefix in the data stream for sending e.g. the next 1 to 50 bytes to a certain port. - in fact that's a question of payload and helps working around if your device will be only able to realize one (=1) USB serial port. your PC application will then no longer be standard as it speaks a special protocol. thus no standard program on the PC will be able to just use those set of embedded serial ports on the far end of the chain in a fashion that a normal USB serial port would look like. ...unless you are realizing a virtual serial port and a driver code that tunnels the data. that's more advanced and will allow you much freedom but also it will require you to spent more efforts on coding such a solution.