Software Serial (USB) parity bit

Status
Not open for further replies.
Sorry, I have positively no idea.

I am glad that an RS232 standard is clear to you. The issue is that is an RS232 standard not necessarily a standard CDC_ACM standard..

I assume you read the information in the link that Paul put in message #20? Which more or less says that most windows and linux USB Serial drivers support 8 bit, but mentions things like, but some chip sets support it, but you need their driver to use it...

So if you think about the USB stuff at the highest level, it is simply sending packets of data with some usb header stuff and N bytes of data. For example if you look at RAWHID,
You send (or receive) packets of 64 (8 bit) bytes of data.

Now suppose you wish to send 9 bit data elements over this how might you do this? I could come up with many different ways.

I might reserve the first byte in the packet to say how many data bytes are in the packet... That is you don't always get a full packet of data before you wish to send it, so you may want to know how many...

a) send 2 bytes per element and waste 7 bits. So instead of 63 elements of data I have 31...
Easy to implement but wastes bandwidth

b) maybe I actually encode all of the data in 9 bit chunks and have to do bunch of shifting and the like to create/extract packet, but you can get maybe 56 elements into packet.

c) Maybe you decide that changing the High bit does not happen very often. So maybe either you have special packets, where since you have max of 63 or 64 bytes, if you have a length field you only need six bits for size, so maybe you encode the top two bits on the size for additional information. Like maybe if high bit is set, then all data bytes in this packet have their logical 9th bit set, else they are 0...

d)...

So again how is it they do it?

Can a Teensy do it? Again do what? Note: the Teensy can emulate a joystick, mouse, keyboard, midi... So it is likely able to do this, whatever it is...

But again not much else I can suggest without something tangible to look at. Like which USB to serial adapter did it work with? Which drivers? Then maybe one could do searches on that library and again see if maybe there is a linux driver that supports it and one maybe can see how they do it? Or maybe can intercept the packets and see what they do...
 
I must admit I had no past experience with (raw) USB communications but I've just read that CDC/ACM classes define some sort of "standard" serial communication. After all, I don't need a "fancy" 9-bit communication but a plain & simple "8P1" one.

I can only imagine that the USB communication layer (high speed, 64 bit packets and so on) is used for data transport only.

And here is where the Teensy come into play, gathering the useful data from the USB frame packages and moving it into some (virtual or hardware) UART registers, like it was coming from a "true" hardware serial connection. Seems to me that's all about the "USB-to-serial" magic, isn't it?

On the PC side, there are another virtual UART registers that store data coming from the USB connection as it came from a "real" serial line. After all, the RS-232 serial frame is just a hardware layer between the two pair of UART registers (one at each end of the transmission line).

The operating system (PC) or the MCU firmware are just processing the UART registers data and they don't care about the way data arrived at the registers location (by high-speed USB connection or by an old 9-wire COM port).

And if it's happening like that, what's the problem with the USB speed, USB packet frame and so on?

PS: If I'm plain wrong, could someone bring some light on this matter?
 
Is it possible to send that 11-bit data packets (described above) over the virtual serial port (CDC/ACM) using Teensy 3.2?

Why don't you do the work to answer this, as I outlined in msg #24.

Since this PC software and its communication protocol is proprietary and confidential, nobody here can directly answer your question. The best we can do is guide you to preforming tests and experiments to discover the answer.

Personally, I'm frustrated that you ask this *again* after we put so much effort into help you to be able to discover the answer. Please, do the work. I know you can not share more info about this software, but the least you could do is perform those tests and tell us (and others who may later find this thread) about the results, like whether the set line coding control transfers are happening as it runs, and what numbers are actually being sent in the byte for parity setting.


And since you are again talking about 11 bits, I'll briefly mention there is no need to transmit the start bit (always 0) and stop bit (always 1) over USB. You keep asking if CDC can transport 11 bits, and the clear answer that you can not seem to hear is the data channel is always 8 bits and a separate control transfer is used for settings. Whether or not that can actually be used with your software is not an answer anyone without the software could ever give. You must work to discover the answer. Maybe you can even write a followup here?


Now suppose you wish to send 9 bit data elements over this how might you do this? I could come up with many different ways.

My understanding so far is he isn't in control of the way the software works. I don't recall seeing any answer to the question which OS it uses, but my guess is we're talking about a closed source program running on (perhaps an old version of) Microsoft Windows.
 
The operating system (PC) or the MCU firmware are just processing the UART registers data and they don't care about the way data arrived at the registers location (by high-speed USB connection or by an old 9-wire COM port).

Earlier in msg #20 I asked you whether the host software is directly accessing hardware registers or using an API like WIN32.

Now you're saying the host software is accessing UART registers. But perhaps this is not a factual statement, but more like a rhetorical question? To say this, and then to also say "don't care about the way data arrived at the registers location (by high-speed USB connection or by an old 9-wire COM port)" makes absolutely not sense at all. The hardware registers for USB communication are completely different than the hardware registers for a UART, and even among UARTs, the registers vary quite a lot. That is why pretty much all hardware access on modern PCs is done through device drivers which are written for 1 device's specific hardware registers.

My overall impression of your question is that you're engaging in wishful thinking rather than considering the facts and reality of how things actually work. And clearly you are more comfortable with continuing to ask redundant questions on this forum rather than actually connect Teensy to your PC and write some simple programs to perform tests with the actual hardware.

Nobody can give you all the answers regarding how to make things work with a proprietary software and secret communication protocols they can't access. The best we can do is help you to discover the answers for yourself. Please, go forth and do this work. Tell us what you discovered. We can try to help, but ultimately you have to do the work. We can't do it for you.
 
@Paul: Sorry, I didn't mean to upset you. I'll try your suggestions and I may also try using a commercial USB-to-serial adapter to see the difference.

You're right, I have no access to that software running on the PC side (btw, I thought I already have mentioned that it's a Java app running on a Windows/Linux machine - it depends).

But I have access to the whole protocol datasheet and, as I have mentioned for a thousand of times(!), it just requires a "pure" RS-232 connection (8-bit data, 1-bit parity) - nothing more.

For testing purpose only, I have designed a small Java app to emulate the PC side app: I have connected a Teensy running a serial test sketch and I was able to read the parity bit (using a java serial library) but it was always "0" (perhaps the right behaviour for the default "none" parity).

The protocol itself (beside being proprietary and confidential) just defines some custom message formats (message ID byte, data bytes and CRC bytes) and the corresponding answer from the server, nothing fancy at all. But, then again, it just needs to read the parity bit to identify the message ID byte.

Okay, I'll take a break and I'll return later with some non-so-confidential results. ;)

Thank you once again for your time.
 
@someteen - again repeating that it is pure RS232 or the like does not help. As we have mentioned for the thousands of times...

All we can do is to give suggestions on how you might figure out how THEY do it...

If it works with a REAL rs232 port, Does your computer have one? If so have you tried using it with this software?

Example: tried to hook up an RS232 to TTL converter to it, and attach the TTL converter to a Hardware Serial port of a processor such as the T3.2? Configured that hardware Serial port to 9 bit data mode and tried to generate a message to send to the computer through it, and see if you get a response?

Again if the company of whom you have a confidential agreement with, can they provide you with a model number (better yet link to a product you can buy), that is a USB to Serial adapter that supports their protocol? If so again try hooking that adapter up to the T3.2, and see if you can send/receive data packets through the adapter?

If so you then have some place to start. Maybe that would be sufficient for your uses. If not, than you can maybe hook up something to watch the USB traffic while doing this. From then you can maybe deduce how they encode the wake bit...

Maybe they simply dropped the whole 9th bit, and assume each USB packet is a complete message or ...

But again ball is in your court.
 
[..] the data channel is always 8 bits and a separate control transfer is used for settings.

@PaulStoffregen:

Could you explain a little more on this subject (I found no online references yet)? I've read about those special call functions for setting/getting the communication settings (e.g. CDC_SET_LINE_CODING).

How's the host actually reading those parity bits? Do I have to instruct the host to read the remote LINE_CODING settings after each received byte? This way, the host could "merge" the parity bit to that particular received byte?

To further clean my explanation, I'll post a short example:

--

The device needs to send the message "B0-B1-B2" to the host:

-> the device set the parity bit to 3 // MARK, always "1"
-> the device send the first byte ("B0")

-> the host is receiving that byte ("B0")
-> the host is asking for the LINE_CODING // custom software routine
-> the host reads the device parity schema // "3", MARK parity, logical "1"

-> the device set the parity bit to 4 // SPACE, always "0"
-> the device send the next byte ("B1")

-> the host is receiving that byte ("B1")
-> the host is asking for the LINE_CODING
-> the host reads the device parity schema // "4", SPACE parity, logical "0"

-> the device let the parity unchanged;
-> the device send the next byte ("B2")

-> the host is receiving that byte ("B2")
-> the host is asking for the LINE_CODING
-> the host reads the device parity schema // unchanged: "4", SPACE parity, logical "0"

At this point, the host has the following associations:
byte "B0" > parity bit "1"
byte "B1" > parity bit "0"
byte "B2" > parity bit "0"
hence it could recreate the original message ("B0" being the message header (parity "1") and "B1-B2" the message body (parity "0")).

--

Is it the right procedure? That's how the parity bit is actually being "read"?
Thank you very much for your help.

@KurtE:

I kindly ask you the same question, thanks in advance for your time.
 
I don't have nearly the experience of Paul or KurtE, but I will say that it would be my best educated guess that GET_LINE_CODING is not called for every byte. That is, unless the USB driver on your host machine is doing this for whatever this product or device is. This theory can be tested, as was pointed out earlier.
 
Then what's the actual method of reading that parity bit? I can't manage to find any valuable online resources. Do you have any suggestions, please?
 
Why are you again asking for the process to read something on the host, when you have clearly said you're running software you don't control on the host?
 
I'm not the developer of the host app but I could tell my client to recommend some specific design procedures to the host app team.
In the mean time, I have designed a bare app (java) running on a similar host PC (linux 64) to test the comm protocol.
 
@someteen (@PaulSoffregen) -

As has been mentioned several times before, I have absolutely no idea how they or who might try to encode the 9 logical bits of data if it is begin sent back and forth over USB...

But at least you actually mentioned that you are using Linux (64 bit)... Again don't know if your host app, is using FTDI (/dev/ttyUSBn) or CDC (/dev/ttyACMn).. or ??? drivers. By default Teensy would go through ACM...

Again I am not a USB expert nor Linux expert and have already mentioned several different things I would try if it were me trying to get something working.

But it is my understanding, is that the HOST is in charge of setting up the Serial port settings (likewise over USB). That is I could be wrong, but I don't think the client hardware, go so and say, I am now running with Parity X for the next byte and after that I will run with Parity Y... But mainly it is the host that sets up the hardware with specific settings, and expects the client side to handle it... Obviously above this, the client and host software might have some logical protocol between them, where the client may send something, which the host software understands to mean please change your settings to Y, and then the host changes...

So again No idea what Linux might do... If I were hacking this, I would probably setup a simple app on Linux and see if I could figure anything out. I would probably setup to talk to a teensy, so probably would either default to /dev/ttyACM0 or allow me to pass in which hardware port to try...

I would look at settings for termios (http://man7.org/linux/man-pages/man3/termios.3.html).
And try playing with some of the parity settings.

Like: what happens if I try to to set CSIZE(CS8), turn on Parity (PARENB), Doe it allow me to set MARK/SPACE(CMSPAR), Try setting it both for MARK and SPACE controlled by PARODD...

Then try sending some data to the Teensy and dump the actual bytes received and see if that makes sense... But again I have no idea if these will work or not... Or will the driver error it out saying unsupported or just ignore it in the data... i.e. just puts it into the special packet...

Then again if it were me, and you had possibility to communicate with HOST team, than I would simply say forget this 9 bit communications, lets come up with simple standard 8 bit communications...
 
Status
Not open for further replies.
Back
Top