Slashdot Mirror

First, running an SSD on an "industrial device"
Second, using FAT
Third, "commercial journaling FS". What does that even mean?
If you are industrial, where is your UPS?

First, there was no choice, and there will be none even in future versions of that vendor's device as a component of the one we make. A spinning disk solution would be far too power intensive, and much too bulky as well.
Second, only FAT was supported by the vendor's firmware at that time (they made improvements later).
Third, here's one. And it's not ext3 and has nothing to do with NTFS.
Fourth, you're joking (for one thing, a 30-minute UPS would not fit in the space available, even if the rest of the device were omitted). Or you're just another stupid troll. Or you utterly fail to understand that industrial devices must survive unexpected power-outages intact, even if they have a UPS with huge batteries or an always-on MG-set. Remember, even a power cable can fail suddenly, or the MG-set can get an abrupt fuel line blockage, and so forth.

Great, now I have to invent a RAM-free computer...

Phew.... good job I use ROM-DOS then!!

1. You are assuming they are using MLC Flash (as opposed to SLC)

Hmm true. MLC is about twice as cheap in the most recent generation.

Presumably two bits per cell halves the die size. Actually it's more complex than that - the SLC cost / MLC cost varies with the generation.

Gb SLC cost/ MLC cost
16 2,1
8 2,6
4 1,4

But MLC has 1/10 the maximum erase cycles

http://www.datalight.com/products/download.php?type=public&resourceid=416

So it's not really suitable for a massive storage array. It would be great for an MP3 player though.

No one is going to stuff flash chips on a board like this and sell it for cost.

Yeah, I know - that's what I meant by 'That's the spot price on the chips too, a device with them in will be more expensive'

Canon Digital still cameras run dos, specifically datalight ROM-DOS. However, it is probably very boring to hack, since all the hardware access and UI is probably in the camera.exe, and all the dos does is boot. So you would have to reverse engineer the camera app to do any hacks. Even then, you will probably run out of RAM for anything more sophisticated.

However, most cameras will have somekind of network connectivity in future (The All devices will creep in features until they can read and send email law). It's a big chance that some vendors will end up using Linux as the base OS - The axis surveillance cams already do!. That would increase the hacking chances. How about running an tiny httpd gallery right of the camera or an ftp server :-P

Dos is not dead, it's just gone embedded. My camera ships with a version of DOS as an internal OS, but you wouldn't know it from use.

Hidden, Dos plots it's revenge.

As a regular EETimes reader, I have to agree with your post.

And... as a developer of and for embedded systems since 1986, I have a little insight on the issue. For the record, we use a proprietary OS in our (1) deeply embedded systems, ROM-DOS on some (2) lightweight PC platform embedded systems and Windows 2000+ on (3) MMI (Man Machine Interface) systems.

We have investigated using RTLinux in the first 2 cases and found the footprint/overhead to be far too great for item (1).

For item (2), we're not sure. The overhead and learning curve have kept us away for the time being, though we're interested in the capability advantage over ROM-DOS. Two very nice things about ROM-DOS: It can have a _very_ small footprint (as little as about 4K to 6K in ROM IIRC) and it's only $25 per runtime license (at least at our negotiated quantities).

For item 3 (yeah I know, it's not really an embedded system) we would love to use Linux (not necessarily RTLinux), but our customers demand Windows workability (desktop apps, Excel, Access, Oracle databases, etc).

So, in our outfit, we only use Linux (Red Hat) for a file server with Samba (to avoid a Windows Server license).

You can't boot from a USB device, can you?

I tend to carry a small collection of bootable media with me such as tomsrtbt on a floppy, LNX-BBC, White Glove, PLAC and a few others. (yes, even a DOS boot disk) They can be very helpful in cases such as upgrading a mobo for a Win98 machine, where the mobo can't see the CD-ROM until you install a driver... from a CD-ROM.

The procedure for making the EPROMS for the RTD PC-104 card is as follows:

1. Fire up the card with +5 and 12 volts
2. Create a freshly formatted floppy with the included Datalight DOS 5.0 on it. I know, it's sad but we had some DOS setup code for the card.
3. Drop loadlin and the kernal You DID build a baby size kernal for this with initrd right? on the floppy
4. Create a ramdisk on you development system to build the root image for your new card
5. umount the ramdisk
6. Set the ramdisk to zeros with:
   dd if=/dev/zero of=/dev/ram0 count=4096
7. Make a filesystem
   mke2fs -vm0 /dev/ram0 4096
8. Mount the ramdisk and copy your root filesystem in:
   mount -t ext2 /dev/ram0 /mnt
   cp -pxR /projects/snmp/root_fs/* /mnt
9. unmount it again and squish it down with:
   umount /mnt
   dd if=/dev/ram0 bs=1k count=4096 | gzip -v9 > /projects/snmp/eprom/root_fs.gz
10. Now, use sneaker net to move the floppy to the DOS machine running the RTD supplied EPROM image maker and tell it to make the entire floppy into an EPROM image .BIN file(s)
11. Burn the files into EPROM, plug 'em into the card, apply power and open a beer as you watch Linux boot on a 4 inch card