Cross-posting from the 8052.com forum http://www.8052.com/forum/index.phtml A while back (http://www.8052.com/forum/read.phtml?id=23083), I asked about how to get a PC to read the 9th bit in Mode 2/3: Multiprocessor Serial bus format. I need to be able to detect the state of the 9th bit for each received byte. Mahmood Elnasser suggested the cport library: http://www2.arnes.si/~sopecrni/downloads/CPort263.zip I've downloaded this, and it doesn't look like it'll do the job :-( (It looks like it'll have the same problem as AsyncPro) The OnRxChar Event could return any number of characters, but the LastErrors Method - as its name suggests - only tells me what the last error was; ie, I can't tell which of the received bytes had the 9th bit set (Parity error). Any help would be greatly appreciated. I'm currently looking around at direct IO drivers for Windows (yes, I know it'd be a doddle in MS-DOS).
Are you saying you can't look at the 9th bit in your receive ISR?
on the 8051 (Triscend E5, actually) it's trivial. I want to make a Win32 PC-based monitor/tester, so I need to be able to see (or, at least, deduce) the 9th bit on a Windows PC
If you are trying to read the 9th bit on a PC, I think you are going to be out of luck. The PC uses a 16450 or 16550 UART. Here are the specs for it:
16450 & 16550 UART Features: Hardware and software register compatible with all standard 16450 UARTs Implements all standard serial interface protocols 5, 6, 7 or 8 bits per character Odd, Even or no parity detection and generation 1, 1.5 or 2 stop bit detection and generation Internal baud rate generator and separate receiver clock input Modem control functions False start bit detection and recovery Prioritized transmit, receive, line status and modem control interrupts Line break detection and generation Internal loop back diagnostic functionality Independent 16 word transmit and receive FIFOs (16550 Only)
If you are trying to read the 9th bit on a PC, I think you are going to be out of luck. The PC uses a 16450 or 16550 UART. Here are the specs for it:<br> <br>
Why does it do that!? I did a 'Preview', then pressed the Browser's 'Back' to edit some more, and all my text had gone! And then it seems to have copied your post as my reply! I think you need to implement a proper 'Edit' button on your reply form, rather than rely on the Browser to go 'Back' properly (which it quite often doesn't)
Anyway, back to the subject: Actually doing it in the UART is easy: just set it to 8 data bits plus Parity, and the UART sees the 9th bit as a Parity bit. Thence one can easily deduce the value of bit-9. There's plenty of 'C' code on the internet showing how to hack into the UART registers to do this. The problem is how to do it from 32-bit Windows! :-( The trouble is that the Win32 API, and things like AsyncPro, don't let you read individual bytes from the UART and check the status for each byte: they just give you a few bytes and say "there was a parity error somewhere in this lot" - which is obviously no good at all! :-(
Look at http://www.wcscnet.com. They deal with the 9'th bit.
Why does it do that!? Andrew et al. I think this problem is fixed now. Jon
Thanks Jon Their COMM-DRV.VxD page does indeed mention "With one call the first byte is sent with 9 bits while the others are transmitted normally." http://www.wcscnet.com/CdrvVBro.htm But this is not quite what I want: I need all bytes transmitted with 9 bits, and b9 is set for "special" bytes and clear for "normal" bytes: From the bus Master, b9 set indicates an address byte (at the start of a message); From a Slave, b9 set marks the last byte of a response. Have you actually used any of their products? What was your opinion?
I had to support some multiport UARTS several years ago (before the 9 bit support was added). I used the LIB product. It worked flawlessly, and was well documented. With a little work, I am thinking you might be able to translate the 9'th bit as address to a 9'th bit as end of packet indicator. Definitely worth a Email to ask them.
Yes, they say it has a "StoreAll" mode in which data & status are queued together It certainly looks worth a try!
In fact do not know the details much, but maybe a component with source code is fine for you since you can change the source to meet your needs. I'm using the ComPort component in BCB from Dejan Crnila, and it includes the full source code. -- ComPort Library ver. 2.60 for Delphi 3, 4, 5 and C++ Builder 3, 4, 5 written by Dejan Crnila,1998-2000 email:dejancrn@yahoo.com --
"I'm using the ComPort component in BCB from Dejan Crnila," Yes, that's the one I mentioned above. As I said, from the description in the Help file, in sounds like it's no good. "it includes the full source code." Yes, the source code is included, but it's not documented! :-( A quick look at CPort.pas shows that it relies upon the Win32 API - using CreateFile, etc Therefore it is doomed - the problems mentioned are inherent in the Win32 API. :-(
With multiprocessor serial bus configuration of 8052, I understand that one-to-many communication is possible (like a tree).
Master <--+------> Slave 1 | +------> Slave 2 : : +------> Slave N
"It is impossible to make a many-to-many communication with this mechanism" (my emphasis) Yes, that's right, because there is no way to stop multiple devices writing to the bus at the same time & corrupting each other's data; By have 1 Master and many slaves, the Master ensures that only 1 slave may transmit at a time, and collisions are avoided.