|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |