Totally understand the timezone differences with delays...
Yep if you look at the K20P64M172SF1RM.pdf (assuming I typed the name correctly), but this is the reference manual for the T3.2 which you can get from the PJRC website...
At section 47.4.5.2 It talks about 9 bit configuration.
Likewise the T4 reference Manual in section 48.3.5.1 (Data Modes under Aditional LPUART functions). ...
Which has a paragraph:
The 9-bit data mode is typically used with parity to allow eight bits of data plus the parity
in the ninth bit, or it is used with address-mark wakeup so the ninth data bit can serve as
the wakeup bit.
As you mention, most of the documents do not describe Mark/Space Parity, as what does that mean? It typically implies something like either the bit is either always a 1 or always a 0 (not much of a parity bit?)....
But internal to the SerialX code there is setup to handle 9 bit data, as we both mentioned. Once you turn it on, you send words instead of bytes to the UART and it updates the 9th bit appropriately. But again that implies everything you send to it is Words, not bytes. So things like: Serial1.print("This is text"); will only output low order 8 bits for each one, but I believe it will setup to store those as words in queue....
Yes the Sketch mentioned, only monitors that the Baud rate changed, not that parity/word length option changed on the USB side, which probably valid for maybe 95+% of the usages that I have seen, that work using 8N1. It could easily be extended to turn on modes like 7E1 or 7O1.
The one I would more likely change for some slow devices to to monitor the number of stop bits, to allow changing the hardware uart to something like 8N2...
What I think Paul was saying and what I sort of mentioned that maybe Paul could answer, was the USB standard USB_CDC standard have any defined way to say transfer 9 bit mode. His answer was more or less NO, with the caveat that you as an application developer are free to develop you own way to do so.
But Again I don't know your setup, or exactly what it is you are trying to do... Things like, is there some specific software package you are running on a PC, that is outputting this, stuff, that you are trying to emulate and get between it and a device?
If so you may need to know what the device does to handle it. If you are developing your own, then you are free to do it any which way that works for you.
Again I don't know your data flow or desired stuff. If mainly you are trying to capture a data from input sensor, so send back to PC, then simply setup the UART to receive the data, then choose any which format of data that you wish for and then send it to the PC... i.e. no requirement for special packing with 9 bits...
Likewise if the PC is generating a request that goes through Teensy, to device, on the PC choose a convenient way to send the data to the Teensy, who can then convert that request into the format the device needs...