Re: Embedding OpenBSD
On 12/31/07 3:51 AM, Douglas A. Tutty wrote: On Mon, Dec 31, 2007 at 01:00:24AM +0100, chefren wrote: On 12/29/07 5:27 PM, Douglas A. Tutty wrote: Summary: I still suggest a heartbeat monitor and a modem. A heartbeat monitor makes the system seriously more complicated and thus less reliable. .. How does that help if the computer just crashes or freezes instead of just spontaneously rebooting? Sure, there's the version 0.0.1 Human to push a power button. The basic point is: Hardware should work reliably, if it isn't you have a broken system. Software idem. For the situation the hearbeat monitor works, it just proves the system is broken and it will reset the system again and again, clueless. Presumably, one can get solid reliable RS-232C heartbeat monitors that can trigger a power-cycle. If not, they're not that difficult to make assuming that you can source some reliable parts. I presume that's not the case. RS-232 is less and less available etc. And look at the workings of your heartbeat monitor: I bet it needs a loop in the software that pings it. With software failures: Big chance that loop still works and thus the heartbeat monitor isn't triggered while the system as a whole can be considered broken. Your heartbeat monitor also needs a way to power-cycle the whole system. Relays? How is/are these powered? Don't forget for all the cables and connectors needed. I thought this was about about reliability!!! KISS is the usefull acronym here. +++chefren
Re: Embedding OpenBSD
On 2007/12/31 15:07, chefren wrote: And look at the workings of your heartbeat monitor: I bet it needs a loop in the software that pings it. With software failures: Big chance that loop still works and thus the heartbeat monitor isn't triggered while the system as a whole can be considered broken. Even so, it still allows recovery from some serious problems without touching the machine. There are quite a few situations where this could be very useful, though it might not be worth the extra expense and complexity of adding an external device, watchdog timers aren't too uncommon in PC hardware these days. Your heartbeat monitor also needs a way to power-cycle the whole system. Relays? How is/are these powered? Don't forget for all the cables and connectors needed. In the case of the hardware Nick mentioned, there should be a watchdog timer in the I/O controller hub (82801AA ICH); adding support for this might be as simple as adding the device ID to /sys/dev/pci/ichwdt.c then test by setting sysctl kern.watchdog.auto=0 and kern.watchdog.period=30 and wait 30 seconds for it to reboot. See watchdog(4) and watchdogd(8) (man -k watchdog gives a list of device drivers supporting watchdog timers). The main docs for driving the ICH* watchdog timers are here: http://download.intel.com/design/chipsets/applnots/29227301.pdf (also see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ichwd/ which supports 82801AA).
Re: Embedding OpenBSD
On 15:37:46 Dec 31, Stuart Henderson wrote: Even so, it still allows recovery from some serious problems without touching the machine. There are quite a few situations where this could be very useful, though it might not be worth the extra expense and complexity of adding an external device, watchdog timers aren't too uncommon in PC hardware these days. Correct me if I am wrong but I believe it was this that saved the Mars lander from total disaster a few years ago. I heard it was due to the brilliant idea of some Indian professor. I don't remember much about it now. In the case of the hardware Nick mentioned, there should be a watchdog timer in the I/O controller hub (82801AA ICH); adding support for this might be as simple as adding the device ID to /sys/dev/pci/ichwdt.c then test by setting sysctl kern.watchdog.auto=0 and kern.watchdog.period=30 and wait 30 seconds for it to reboot. See watchdog(4) and watchdogd(8) (man -k watchdog gives a list of device drivers supporting watchdog timers). Watchdog is a great idea. And for embedded/real time systems it might be inevitable and even life saving. But since I lack experience my ideas could be wrong. The main docs for driving the ICH* watchdog timers are here: http://download.intel.com/design/chipsets/applnots/29227301.pdf (also see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ichwd/ which supports 82801AA). Wow! Great! I believe Intel gives very good documentation for everything except wireless chipsets. ;) Theo should have more to say on this. ha ha Many thanks Stuart. -Girish
Re: Embedding OpenBSD
On Mon, Dec 31, 2007 at 03:37:46PM +, Stuart Henderson wrote: On 2007/12/31 15:07, chefren wrote: And look at the workings of your heartbeat monitor: I bet it needs a loop in the software that pings it. With software failures: Big chance that loop still works and thus the heartbeat monitor isn't triggered while the system as a whole can be considered broken. Put it somewhere in the main software loop. Hook up a second trigger off the money-detector. The computer decides what tune to play and plays it. The heartbeat monitor can detect the money and listen for any sound out of the speaker. Even so, it still allows recovery from some serious problems without touching the machine. There are quite a few situations where this could be very useful, though it might not be worth the extra expense and complexity of adding an external device, watchdog timers aren't too uncommon in PC hardware these days. Your heartbeat monitor also needs a way to power-cycle the whole system. Relays? How is/are these powered? Don't forget for all the cables and connectors needed. Last time I needed such a timer was about 20 years ago. Used a mil-spec 556 TTL dual-timer IC and appropriate caps, resistor, and relay. Fit it inside a small box with a 110V recepticle and a power cord, and connected with a serial cord. Powered it right off the serial port. Doug.
Re: Embedding OpenBSD
Girish Venkatachalam wrote: Correct me if I am wrong but I believe it was this that saved the Mars lander from total disaster a few years ago. I heard it was due to the brilliant idea of some Indian professor. I don't remember much about it now. It's somewhat more difficult to access the hardware on the Mars lander, let alone replace parts.
Re: Embedding OpenBSD
On 13:37:28 Dec 31, Steve Shockley wrote: Girish Venkatachalam wrote: Correct me if I am wrong but I believe it was this that saved the Mars lander from total disaster a few years ago. I heard it was due to the brilliant idea of some Indian professor. I don't remember much about it now. It's somewhat more difficult to access the hardware on the Mars lander, let alone replace parts. Read this and 'CTRF-F' for watchdog. http://research.microsoft.com/~mbj/Mars_Pathfinder/Mars_Pathfinder.html If I remember right this made a lot of headlines few years ago. This is not on topic but other threads don't look any good anyway.;) -Girish
Re: Embedding OpenBSD
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. There are commercial MP3 modules which are designed to do exactly what you are looking for, one example: http://www.hobbyengineering.com/H2168.html By itself, the uMP3 Playback Module has 8 inputs, pulling any of the 8 inputs low plays back the associated MP3 file from a FAT filesystem on an SD card. Replace the card to replace the files. Getting it to play one of a pile of different sound files, not trivial. With some help from a PIC (e.g. Basic STAMP), this could be made to play random sounds for each coin. While the uMP3 hardware has changed slightly over the past couple of years, the electrical and logical interface has remained stable, as has the price, at around US$100/ea, with substantial discounts for larger quantities. Kevin
Re: Embedding OpenBSD
On 12/29/07 5:27 PM, Douglas A. Tutty wrote: Summary: I still suggest a heartbeat monitor and a modem. A heartbeat monitor makes the system seriously more complicated and thus less reliable. If the proposed system boots from a non writable medium (yes there are flash devices with a write-protect switch, CD-rom is also OK although dust collection on the laser detector is an issue) and works in memory, diskless!, unintended log events will be written to memory (that might overflow but who cares for this application) and the system always boots the same after power up. +++chefren
Re: Embedding OpenBSD
On Mon, Dec 31, 2007 at 01:00:24AM +0100, chefren wrote: On 12/29/07 5:27 PM, Douglas A. Tutty wrote: Summary: I still suggest a heartbeat monitor and a modem. A heartbeat monitor makes the system seriously more complicated and thus less reliable. If the proposed system boots from a non writable medium (yes there are flash devices with a write-protect switch, CD-rom is also OK although dust collection on the laser detector is an issue) and works in memory, diskless!, unintended log events will be written to memory (that might overflow but who cares for this application) and the system always boots the same after power up. How does that help if the computer just crashes or freezes instead of just spontaneously rebooting? Sure, there's the version 0.0.1 Human to push a power button. Presumably, one can get solid reliable RS-232C heartbeat monitors that can trigger a power-cycle. If not, they're not that difficult to make assuming that you can source some reliable parts. I totally agree with the non-writable medium issue. Doug.
Re: Embedding OpenBSD
Steve Shockley wrote: [EMAIL PROTECTED] wrote: On the other hand, the stash of Compaq iPaqs I came across recently have built-in sound, a very capable built-in speaker, nearly silent in operation and are easy for Joe Average to understand. We've got enough we could even ship out a spare with the system for spare parts. Is that one of the handheld Windows Mobile devices, or one of the thin client things they used to sell? Apparently, Compaq likes to (surprise) reuse product names. http://www.cl.cam.ac.uk/~pb22/iPAQ/10638_na.html It's a full i386 computer, though free of expansion slots or 5.25 drive bays. It has provisions for a laptop-style CDROM drive (only two of the 20 machines had that), no floppy, unless you got one for the CDROM bay. i810 chipset. Celeron 500MHz, though apparently other things can go in them. Other than the bottom, not a flat surface on them, which makes them very difficult to handle, store, stack or relocate. In fact, while they are small and light enough that I should be able to carry probably four or five at a time, the awkward shape pretty well limits it to two at a time, as there is just nothing to hold onto (and even picking the two up is a challenge). However, the form is not at all bad for our project. HW-wise, it's very solid OpenBSD-compatible stuff, and seems to work well. It's got classic annoying Compaq quirks (it wants a keyboard), but they are able to be worked around. Interesting test (even more off-topic than the rest, but...) With JUST the flash drive, idle OpenBSD power draw was about 21W. With added HD, idle OpenBSD power draw was about 26W With bc soaking all available processor time, power was up to 44W. (and you thought those distributed computing projects were free...) (my Wattmeter reads only to the nearest 1W, so all those figures are +/-1W on top of whatever the accuracy of the thing is.) (the hard disk is installed on this thing so I can start imaging and making additional flash cards on my dev system, not for production.) Nick. OpenBSD 4.2-current (GENERIC) #607: Tue Dec 18 18:36:52 MST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Celeron (GenuineIntel 686-class, 128KB L2 cache) 499 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real mem = 132739072 (126MB) avail mem = 120451072 (114MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 02/05/99, BIOS32 rev. 0 @ 0xeca00, SMBIOS rev. 2.3 @ 0xfbfff (36 entries) bios0: vendor Compaq version 686J5 v2.05 date 07/07/2000 bios0: Compaq iPaq acpi0 at bios0: rev 0 acpi0: tables DSDT FACP SSDT SSDT SSDT DBGP SSDT acpi0: wakeup devices HUB_(S4) USB0(S1) PCI0(S4) SBTN(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (HUB_) acpibtn0 at acpi0: SBTN bios0: ROM list: 0xc/0x8000 0xc8000/0x1800 0xe/0x1! cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82810E rev 0x03 agp0 at pchb0: aperture at 0x4400, size 0x400 vga1 at pci0 dev 1 function 0 Intel 82810E Graphics rev 0x03 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb0 at pci0 dev 30 function 0 Intel 82801AA Hub-to-PCI rev 0x02 pci1 at ppb0 bus 1 fxp0 at pci1 dev 1 function 0 Intel 8255x rev 0x08, i82559: irq 5, address 00:d0:b7:c7:f7:de inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4 ichpcib0 at pci0 dev 31 function 0 Intel 82801AA LPC rev 0x02 pciide0 at pci0 dev 31 function 1 Intel 82801AA IDE rev 0x02: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: CF 1GB wd0: 1-sector PIO, LBA, 967MB, 1980720 sectors wd1 at pciide0 channel 0 drive 1: ST38411A wd1: 16-sector PIO, LBA, 8063MB, 16514064 sectors wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 4 pciide0: channel 1 disabled (no drives) uhci0 at pci0 dev 31 function 2 Intel 82801AA USB rev 0x02: irq 5 auich0 at pci0 dev 31 function 5 Intel 82801AA AC97 rev 0x02: irq 10, ICH AC97 ac97: codec id 0x41445348 (Analog Devices AD1881A) ac97: codec features headphone, Analog Devices Phat Stereo audio0 at auich0 isa0 at ichpcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1 biomask f9fd netmask f9fd ttymask fbff mtrr: Pentium Pro MTRR support uhub1 at uhub0 port 2 Texas Instruments TUSB2046 hub rev 1.10/1.25 addr 2 uhidev0 at uhub1 port 3 configuration 1 interface 0 Sun Microsystems Type 6 Keyboard rev 1.10/2.00 addr 3 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 modifier keys, 6 key codes,
Re: Embedding OpenBSD
Nick Holland wrote: Apparently, Compaq likes to (surprise) reuse product names. http://www.cl.cam.ac.uk/~pb22/iPAQ/10638_na.html I think that's what I was thinking of, at least the case looks like it. I think at one point they marketed these as a thin client type of device. Interesting test (even more off-topic than the rest, but...) With JUST the flash drive, idle OpenBSD power draw was about 21W. With added HD, idle OpenBSD power draw was about 26W With bc soaking all available processor time, power was up to 44W. (and you thought those distributed computing projects were free...) (my Wattmeter reads only to the nearest 1W, so all those figures are +/-1W on top of whatever the accuracy of the thing is.) How's that compare to a Mac 68k? I'm surprised you didn't go with one of those... although I suppose a SCSI flash adapter is hard to find.
Re: Embedding OpenBSD
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.
Re: Embedding OpenBSD
[EMAIL PROTECTED] wrote: On the other hand, the stash of Compaq iPaqs I came across recently have built-in sound, a very capable built-in speaker, nearly silent in operation and are easy for Joe Average to understand. We've got enough we could even ship out a spare with the system for spare parts. Is that one of the handheld Windows Mobile devices, or one of the thin client things they used to sell?
Re: Embedding OpenBSD
This is a neat idea, but personally I think it'll be hard to make the device 0 maintenance, problems can always occur... If you're set on using OpenBSD in this project, remove everything from the base system that isn't needed... and try running the unit non-stop for 48/hours... just to be sure it's not going to die days after you leave the country. If this all seems horribly complex, use one of Doug's suggestions. (Consider a modem, or a net card... so remote maintenance is possible..)
Re: Embedding OpenBSD
* Unix Fan [EMAIL PROTECTED] [2007-12-28 17:44]: remove everything from the base system that isn't needed... yeah THAT is certainly going to help... deleting binaries saves the world! -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: Embedding OpenBSD
What in the world??? Do you drive a car? if the answer is yes you have an unconnected embedded device. Need more examples? On Fri, Dec 28, 2007 at 08:34:24AM -0800, Unix Fan wrote: This is a neat idea, but personally I think it'll be hard to make the device 0 maintenance, problems can always occur... If you're set on using OpenBSD in this project, remove everything from the base system that isn't needed... and try running the unit non-stop for 48/hours... just to be sure it's not going to die days after you leave the country. If this all seems horribly complex, use one of Doug's suggestions. (Consider a modem, or a net card... so remote maintenance is possible..)
Re: Embedding OpenBSD
On Fri, Dec 28, 2007 at 08:34:24AM -0800, Unix Fan wrote: (Consider a modem, or a net card... so remote maintenance is possible..) The problem with a net card is that then the end-user would have to set up a dhcp server or some how have the card set up correctly. With a modem, its pretty standard. Either have the device's cron try to access the modem to call home (and if a phone line is connected, it will succeed) to set up a ppp link, or just set up the modem to allow you to dial-in and get a login prompt. Then the end-user just has to supply a phone line to the unit and you with a phone number. Doug.
Re: Embedding OpenBSD
In article [EMAIL PROTECTED], Nick Holland wrote: What have I forgotten? Is there anything else I can do to avoid slapping my forehead and saying, D'oh! Forgot to ... before I ship it out fully detached? The good news is I'm pretty sure there is at least one OpenBSD developer near-by, but that's just all the more reason to make sure I don't screw it up, I'll never live it down. :) Unless you have a need to keep state, I'd not bother in any way to write to the flash. I'd have a bsd.rd on there that get's loaded on boot. No fsck necessary, completely in ram, etc. -Toby. -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
Re: Embedding OpenBSD
On Dec 27, 2007 10:41 PM, Douglas A. Tutty [EMAIL PROTECTED] wrote: I'd wire in a hardware-type heartbeat detector that will power-cycle the computer if it stops working. I'd have a door over the money slot powered by the computer so that it only accepts money when its working. You could have a Please wait light to be lit during the reboot. Or, you could just rewire an MP3 player to play a tune when it is powered on, then just hook the money-detector to the power switch. Money turns it on, a timer just longer than the tune turns it off. No computer needed (just a 556-dual-555 timer IC and some spare parts). I second the idea of something as simple as an MP3 player connected to a money detector, if that's all it will be doing. Seems a little over-kill to get a whole computer, even if it is something as simple as a Soekris ( http://www.soekris.com/, which by the way, is a very nice device). However, if you do decide you still want an embedded OBSD device, it certainly is doable. I have a Soekris net4801 that I am using as my firewall/router, and it is working like an appliance. I'm using a 1GB CF card; it's mounted RW, but for the most part it is really only writing data to an mfs mount point. In this case, it's obviously connected to a network, and I have a monitoring tool running to report back on disk space usage, but it could easily do without this. I have a cron job that periodically checks to make sure the mfs mount points don't fill up, and cleans them out as appropriately. I have also highly tuned the log rotation to further ensure mount points don't get filled out. Should a problem arise, since the CF card is effectively read-only, a reboot is as simple and unplugging the device and then plugging it back in. Unless there is a hardware fault, it will come back up on its own. For further protection, you should mount the CF read-only so no mount points there can accidentally fill up.
Re: Embedding OpenBSD
On Fri, Dec 28, 2007 at 11:13:18AM -0600, Marco Peereboom wrote: Do you drive a car? if the answer is yes you have an unconnected embedded device. Need more examples? Well, actually, my car doesn't include a digital computer. It has an ignition module that is analog but no sensors. Nice complicated carburrator instead of a nice simple fuel injector(s). Of course, the car is older than any of the mechanics that work on it. However, I spend under $200 per year on maintenance for the engine. I've seen the odometer go around twice since I bought it 5 years ago; it's probablly at the 500,000. So be carefull with generalities... :) Doug.
Re: Embedding OpenBSD
Use something like flashboot (www.mindrot.org/projects/flashboot) perfect for this kind of application, take a look at the package managment stuff J On Dec 28, 2007, at 10:18 AM, Tobias Weingartner wrote: In article [EMAIL PROTECTED], Nick Holland wrote: What have I forgotten? Is there anything else I can do to avoid slapping my forehead and saying, D'oh! Forgot to ... before I ship it out fully detached? The good news is I'm pretty sure there is at least one OpenBSD developer near-by, but that's just all the more reason to make sure I don't screw it up, I'll never live it down. :) Unless you have a need to keep state, I'd not bother in any way to write to the flash. I'd have a bsd.rd on there that get's loaded on boot. No fsck necessary, completely in ram, etc. -Toby. -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1! =b]salax
Re: Embedding OpenBSD
step 1. get a any old ipod on ebay step 2. put a single mp3 tune on it step 3. place it in a big box, with the play button located right under a coin sized slot openbsd is great, but it's not the hammer for all nails... /Pete On 28 Dec 2007, at 3:34 AM, Nick Holland wrote: I've got a little project I'm working on here. It involves stuffing a computer in a donation box with a money detector, so every time someone tosses money in the box, it plays an MP3 file. (no, you can't make a living at this. At least, *I* can't) The first two of these I did were many years ago, and we used a 486 running a simple DOS app. Well, computers that run DOS well are gone, and trying to bring up a new program to play sound files on any of the modern sound chips would be (not) fun...and annoying the next time the hardware all changes again. So, for this generation, I'm using OpenBSD, mpg321, and a 1G CF flash device attached to an CF- IDE interface. However, this is the first time I've ever done an OpenBSD system that wasn't going to be attached to some kind of network for (hopefully) years at a time. In fact, hopefully, it will NEVER be attached to a network. And, while I got a 1G CF device, I could imagine doing something stupid and having it slowly fill the CF media and six months from now getting a call saying, It died. Come fix it, and since it will be in another country and probably a ten hour drive away, I'd like to avoid that. :) Once this thing is deployed, I won't have access to it at all, so I'll have no ability to spot a potential problem or fix it. SO, to try to keep things quiet, I've disabled the daily, weekly, and monthly scripts, I've disabled sendmail in /etc/rc.conf.local. Before I ship it out, I'll move /var/log and /var/tmp to point to a mfs system, so hopefully, if something starts logging, a power cycle will dump everything. Only 60M is mounted RW, so it fsck's very quickly, and my app writes only to the MFS. What have I forgotten? Is there anything else I can do to avoid slapping my forehead and saying, D'oh! Forgot to ... before I ship it out fully detached? The good news is I'm pretty sure there is at least one OpenBSD developer near-by, but that's just all the more reason to make sure I don't screw it up, I'll never live it down. :) Nick.
Re: Embedding OpenBSD
On Fri, 28 Dec 2007, Marco Peereboom wrote: What in the world??? Do you drive a car? if the answer is yes you have an unconnected embedded device. Need more examples? Indeed! How many Soekris routers are there in 'production', operating with a config just as suggested? Lee
Re: Embedding OpenBSD
Marco Peereboom wrote: What in the world??? Do you drive a car? if the answer is yes you have an unconnected embedded device. Need more examples? No, I walk.. batteries not included.. Seriously, I was simply giving my opinion... unfortunately I walked under a bridge and got attacked by a troll.. Bad troll. -Nix Fan.
Re: Embedding OpenBSD
Well thank you for your valuable input captain obvious. On Fri, Dec 28, 2007 at 05:13:41PM -0800, Unix Fan wrote: Marco Peereboom wrote: What in the world??? Do you drive a car? if the answer is yes you have an unconnected embedded device. Need more examples? No, I walk.. batteries not included.. Seriously, I was simply giving my opinion... unfortunately I walked under a bridge and got attacked by a troll.. Bad troll. -Nix Fan.
Re: Embedding OpenBSD
Gary Baluha wrote: On Dec 27, 2007 10:41 PM, Douglas A. Tutty [EMAIL PROTECTED] wrote: I'd wire in a hardware-type heartbeat detector that will power-cycle the computer if it stops working. I'd have a door over the money slot powered by the computer so that it only accepts money when its working. uh, the point is to get their money. The fact that it does something in return is just a bonus. It might prompt them to say, Hey, did that just talk to me?? and they stick another coin in to find out. At that point, it says something different, and by now, the kids all want in on it. Soon enough, a dollar or two worth of coins has just gone down the toad's mouth. Failure mode should still to be accept the first coin, not reject it. Not desired, sure, but no worse than the cookie jar collection box. We've done a couple others of these things, the owners tell us they do considerably better than just the traditional can with slot cut in it donation box. 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. :) Or, you could just rewire an MP3 player to play a tune when it is powered on, then just hook the money-detector to the power switch. Money turns it on, a timer just longer than the tune turns it off. No computer needed (just a 556-dual-555 timer IC and some spare parts). I second the idea of something as simple as an MP3 player connected to a money detector, if that's all it will be doing. Seems a little over-kill to get a whole computer, 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. That idea was considered, but the reverse engineering of the things would be very difficult, both because they are mostly sealed blobs and anything developed on Model X would have to be repeated next year, when Model X is discontinued, and model Y is out. Further, while at my peak, I could solder a 16 pin IC with a 400W unregulated soldering gun in about five seconds (and make it work!) (for those not into soldering, that's way too big a soldering tool and way too fast), I'm a bit out of practice, and I'm not even sure I could see what I was soldering on with a modern MP3 player. They aren't designed for hacking. One would have to come up with a way to sequence the buttons on the thing to play one sound file, detect the end of the sound file, stop the play back, then resume the playback on the next sound file...ick. If it isn't obvious, the files WILL be of wildly differing lengths, some a couple seconds, some maybe close to a minute long. I have no idea why so many people assumed it would play back only ONE sound file..note the use of the plural files in my original posting. I actually considered doing something like the old DuKane filmstrip projectors did, embed a tone in the file, detect the tone, filter it out at the amp. Detect money? Press play. Hear tone? press Pause. That makes creating/editing/revising the sound files got a lot more complex, so it would no longer be owner-maintainable. 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 can assure those who thought I jumped to an OpenBSD-based computer as my first choice for the design are very wrong. A lot of brainstorming took place. Considerations included cost, parts availability, long term maintainability, development ease, field maintenance, etc. I'm pretty thorough and pretty creative in my designs, and quite aware of the When all you have is a hammer, all the world looks like a nail. Using a computer for this app sucks, but not as badly as the alternatives that I could think of. 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,
Re: Embedding OpenBSD
On Thu, Dec 27, 2007 at 09:34:37PM -0500, Nick Holland wrote: I've got a little project I'm working on here. It involves stuffing a computer in a donation box with a money detector, so every time someone tosses money in the box, it plays an MP3 file. However, this is the first time I've ever done an OpenBSD system that wasn't going to be attached to some kind of network for (hopefully) years at a time. In fact, hopefully, it will NEVER be attached to a network. And, while I got a 1G CF device, I could imagine doing something stupid and having it slowly fill the CF media and six months from now getting a call saying, It died. Come fix it, and since it will be in another country and probably a ten hour drive away, I'd like to avoid that. :) Once this thing is deployed, I won't have access to it at all, so I'll have no ability to spot a potential problem or fix it. What have I forgotten? Is there anything else I can do to avoid slapping my forehead and saying, D'oh! Forgot to ... before I ship it out fully detached? The good news is I'm pretty sure there is at least one OpenBSD developer near-by, but that's just all the more reason to make sure I don't screw it up, I'll never live it down. :) I'd wire in a hardware-type heartbeat detector that will power-cycle the computer if it stops working. I'd have a door over the money slot powered by the computer so that it only accepts money when its working. You could have a Please wait light to be lit during the reboot. Or, you could just rewire an MP3 player to play a tune when it is powered on, then just hook the money-detector to the power switch. Money turns it on, a timer just longer than the tune turns it off. No computer needed (just a 556-dual-555 timer IC and some spare parts). What about a built-in modem set up to allow a login. Then if something _does_ go wrong, you can ask the user to provide a phone line to the box and you with the phone number. With this, you can fix or even upgrade the box over the phone. Add a hardware cycle-counter; if the heartbeat causes a reboot and the cycle counter doesn't get reset, it lights a please call for service light. Doug.
Re: Embedding OpenBSD
Nick Holland wrote: I've got a little project I'm working on here. It involves stuffing a computer in a donation box with a money detector, so every time someone tosses money in the box, it plays an MP3 file. (no, you can't make a living at this. At least, *I* can't) The first two of these I did were many years ago, and we used a 486 running a simple DOS app. Well, computers that run DOS well are gone, and trying to bring up a new program to play sound files on any of the modern sound chips would be (not) fun...and annoying the next time the hardware all changes again. So, for this generation, I'm using OpenBSD, mpg321, and a 1G CF flash device attached to an CF- IDE interface. However, this is the first time I've ever done an OpenBSD system that wasn't going to be attached to some kind of network for (hopefully) years at a time. In fact, hopefully, it will NEVER be attached to a network. And, while I got a 1G CF device, I could imagine doing something stupid and having it slowly fill the CF media and six months from now getting a call saying, It died. Come fix it, and since it will be in another country and probably a ten hour drive away, I'd like to avoid that. :) Once this thing is deployed, I won't have access to it at all, so I'll have no ability to spot a potential problem or fix it. SO, to try to keep things quiet, I've disabled the daily, weekly, and monthly scripts, I've disabled sendmail in /etc/rc.conf.local. Before I ship it out, I'll move /var/log and /var/tmp to point to a mfs system, so hopefully, if something starts logging, a power cycle will dump everything. Only 60M is mounted RW, so it fsck's very quickly, and my app writes only to the MFS. What have I forgotten? Is there anything else I can do to avoid slapping my forehead and saying, D'oh! Forgot to ... before I ship it out fully detached? The good news is I'm pretty sure there is at least one OpenBSD developer near-by, but that's just all the more reason to make sure I don't screw it up, I'll never live it down. :) Nick. A noob-ish question/observation... since the mfs could eventually fill, why not point potential logs at /dev/null instead?
Re: Embedding OpenBSD
Nick Holland wrote: Only 60M is mounted RW, so it fsck's very quickly, and my app writes only to the MFS. Why mount any CF partition RW? And you should be able to test your system on a CD to prove it'll work without writing.
