On Sat, Dec 29, 2007 at 12:34:13AM -0500, [EMAIL PROTECTED] wrote: > Gary Baluha wrote: > > On Dec 27, 2007 10:41 PM, Douglas A. Tutty <[EMAIL PROTECTED]> wrote: > >> You could have a "Please wait" light to be lit during the reboot. > > This is precisely why I asked this question, to make sure this doesn't > happen. While having a self-cleaning mess beats having a persistent > mess, I'd rather just avoid the mess. :) >
With standard COTS hardware and a admittedly bug-containing OS (yes, everyone agrees that even OpenBSD contains bugs), you cannot guarantee that something won't happen to either cause a spontaneous reboot or to make the device stop working causing any heartbeat monitor to force a reboot. > Getting an off-the-shelf MP3 player to play one sound file is not too > difficult. Ah, heck, a tape loop would work fine, too. > > Getting it to play one of a pile of different sound files, not trivial. > I didn't read your description of the issue to mean playing different sounds. With this spec, some sort of logic would make sense. > As it is, 1/3 of the storage device (I'm not gonna use the 'f' word here, > as people apparently keyed off it and have been answering questions I didn't > ask, so just pretend it is a little, slow disk) is a DOS FAT partition, so > someone (anyone!) could remove the storage device, plug it into their > Windows computer, and add, remove, replace, or re-order the message files. > (I've also set it up that if someone plugs a USB storage device in at boot, > it uses that for sound files rather than the "on-board" files.) I wouldn't want to risk the root filesystem by having the device its on be plugged into a random user's windows box. It would make more sense to use your CF card for the root device and provide a USB port under a flap or something for people to mount replacement sound files. It would be nice if it could be ro mounted-on-insert and used with the next coin and unmounted-on-removal to revert to the built-in tunes. Save the reboot. > About the only compromise I took that I really didn't like was not using > the parallel port for the input on the thing. I wasn't having much luck > doing that when the idea of using a mouse as an input device was suggested > to me by the artist I'm working with. My first thought was, "that's crazy", > but then I realized I could simply hack wsmoused to execute a program > whenever the mouse is clicked, and ta-da, we got ourselves a solution. I > don't think I spent more than a couple hours doing that before I had > a demonstrator program running. When I got the opportunity to get the > iPaq desktops, I grabbed one, flipped it over, saw PS/2, parallel and > serial ports, figured "That's it!", and grabbed twenty of the things. > You can see where I'm going: I kid you not, the one I grabbed was the ONLY > one with PS/2, parallel and serial, the rest were all "legacy free". > Suddenly, the mouse-as-input-device didn't seem anywhere near so stupid. :) What was the problem having the coin detector trigger the "printer ready" line on a parport or one of the status lines on a serial port? Would seem to be less hacking. Personally, I would avoid hacking the base system (e.g. wsmoused) and instead have my program over top of base. Python has both a parallel and a serial module to allow accessing those ports. > If something goes wrong in the field, the people near the machine will be > much more likely to be able to put a monitor and keyboard on it than they > will be able to put a serial terminal. I wasn't suggesting a serial terminal for use by the user. I was suggesting a phone jack that the user plugs in then you or another service tech dials in to the unit from the comfort of your office. Summary: I still suggest a heartbeat monitor and a modem. Good luck, Doug.
