On 10/28/2010 3:12 PM, Darren New wrote:

> Well, no. There's interrupts, sensors saying how many coins are there,
> to signal when it's out of coins or has been filled incorrectly, timing
> delays for releasing various coins, dealing with power going out and
> coming back on while the mechanism is operating, etc.

Surely a lot of that should be handled by the firmware. How does it 
communicate? RS232/RS485, TCP/IP, USB, CAN, etc?

What data does the device communicate back to the host? What does the 
host send to the device?

Obviously there must be some sort of protocol, and the device's firmware 
probably only communicates the bare minimum to work with the host. If 
you don't have the messages it expects and the messages it sends laid 
out for you, it could be a bit of a challenge. You'll probably miss a 
corner case somewhere. (For example, upon host init, the coin counter 
expects to be sent a certain set of data to initialize properly, or 
perhaps you missed the "coin stuck" message because you never saw it in 
your reverse engineering tests)

> Everything's trivial if you aren't the one writing the code.

Of course!

>> I guess the real question is "why are people manufacturing devices
>> that will only ever be used as part of an embedded system writing
>> drivers for it that won't work as part of an embedded system?"
>
> Except it *is* a driver working as part of an embedded system, obviously.
>

Also, less expensive to support only one embedded OS.

Of course, I wouldn't be surprised that even if the device communicated 
over a common, easily accessible protocol that it's opaque through a set 
of DLL's. I've seen a lot of devices like that when I was working on HMI 
code. Some of the basic sensors are really quite easy to deal with. We 
had a prox sensor whose communication protocol was to raise a single 
line (RTS, I think ...) on the RS232 port as an indicator that something 
was in proximity. Extremely simple to deal with.

-- 
~Mike

Post a reply to this message