On Wed, 1 Oct 2008 15:45:14 +1000, "PhilW" <p...@microcoin.com> wrote:

>
>"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?

Yup, totally. Interesting thread ;-)

I wouldn't do this as a byte-wise buffer device, but rather as a higher
level gateway. Implement the MDB state machine in the microprocessor to
behave as the communications gateway, peripheral, or bus master as
required/desired. The side facing the PC could run at a higher baud (or
even over a different medium) and would not necessarily use the MDB
message structure.

Personally, on the side facing the PC I'd try very hard to push
everything into a plain-text format. Easy to monitor and log, simple to
debug, and it can be digested by lots of analysis tools without a
separate binary -> ASCII translator pass.

-- 
Rich Webb     Norfolk, VA

"Rich Webb" <b...@mapson.nozirev.ten> wrote in message 
news:n...@4ax.com...
> On Wed, 1 Oct 2008 15:45:14 +1000, "PhilW" <p...@microcoin.com> wrote:
>
>>
>>"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?
>
> Yup, totally. Interesting thread ;-)
>
> I wouldn't do this as a byte-wise buffer device, but rather as a higher
> level gateway. Implement the MDB state machine in the microprocessor to
> behave as the communications gateway, peripheral, or bus master as
> required/desired. The side facing the PC could run at a higher baud (or
> even over a different medium) and would not necessarily use the MDB
> message structure.
>
> Personally, on the side facing the PC I'd try very hard to push
> everything into a plain-text format. Easy to monitor and log, simple to
> debug, and it can be digested by lots of analysis tools without a
> separate binary -> ASCII translator pass.
>
> -- 
> Rich Webb     Norfolk, VA



Yes I agree with you that would be the better way to go. However, it is 
stepping away from the MDB protocol concept. It also adds a lot of work and 
maintainance.

PhilW

But.. have you considered using the Executive Protocol ?
Of course, it depends on the function you have to implement, anyway it
is less difficult,
even if it isn't possible to connect directly the PC seria port with
the vending machine.

Talking about mdb I've found only the PC2MDB product, but I haven't
used it.
Let us know if you try it..