On Wed, 1 Oct 2008 09:42:46 +1000, "PhilW" <p...@microcoin.com> wrote:

>
>Ok, then you have no choice but to write low level code to fudge the 9bit 
>char by using the mark/space parity control.

Sorry for jumping in here so far down in the thread, but to throw out
another option for the OP: Add a microcontroller as the glue between the
embedded PC and the MDB device.

There are probably other chips but one family that I'm familiar with
that could handle this easily is the Atmel AVR ATmega. These natively
support 9-bit serial (in addition to the usual other formats) and, in
addition, can filter on the 9th bit set (MDB address mode). Almost like
they were made to support this protocol.

Pick one with dual UARTS and talk to it serially, or get one with a USB
peripheral and communicate with it that way. It would take a teeny bit
of work but may be cleaner, in the end, than trying to dance with the
parity bit.

-- 
Rich Webb     Norfolk, VA

"Rich Webb" <b...@mapson.nozirev.ten> wrote in message 
news:v...@4ax.com...
> On Wed, 1 Oct 2008 09:42:46 +1000, "PhilW" <p...@microcoin.com> wrote:
>
>>
>>Ok, then you have no choice but to write low level code to fudge the 9bit
>>char by using the mark/space parity control.
>
> Sorry for jumping in here so far down in the thread, but to throw out
> another option for the OP: Add a microcontroller as the glue between the
> embedded PC and the MDB device.
>
> There are probably other chips but one family that I'm familiar with
> that could handle this easily is the Atmel AVR ATmega. These natively
> support 9-bit serial (in addition to the usual other formats) and, in
> addition, can filter on the 9th bit set (MDB address mode). Almost like
> they were made to support this protocol.
>
> Pick one with dual UARTS and talk to it serially, or get one with a USB
> peripheral and communicate with it that way. It would take a teeny bit
> of work but may be cleaner, in the end, than trying to dance with the
> parity bit.
>
> -- 
> Rich Webb     Norfolk, VA


Hi Rich,

If you have look back through some of the posts I mentioned why your 
suggestion is not really a viable solution. It has to do with the msg 
response time. In Sect 3 it says that a device, or host, must respond to a 
msg within 5mS (5 char times).
Therefore if you place a translator in series you will probably blow that 
out of the water. By how much will depend on your implementation. If you 
simply receive the command into the translator, convert it and resend it to 
the device, your response time will be msg length(in chars @ 1mS each) * 2 + 
device response time at best. with a message up to 36 bytes in length will 
be 72mS + device response time. See what I mean.
A better way would be to receive the msg from the host and convert on the 
fly, retransmitting 1 char behind. At least you may be able to reduce it 
down to 2mS + device response time. That only gives you a 3mS response time 
window in the device to meet spec. On top of that, in both the above cases, 
you will need to implement how you are going to talk to the PC and keep the 
msgs in synch without an address/msg end byte (9th bit).

Am I making sense?

regards
PhilW