I sometimes use a recording device (logs pressure and temperature) which uses a CF card. When you press the button to stop recording, it writes the file. The message "writing" pops up on the LCD display, but there is enough delay that most anyone who moves fast can easily have pushed the card eject lever just before the message comes up.
Maybe a REALLY bright LED? They can't push the button if they're bush shielding their eyes from a blazing 1W LED...
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Yup. And CF cards are (or can be) very fast! Imagine writing
*lots* of data to the card (GB's) -- how patient will you be then? :<
CF sockets are also "user-powered" for their motive force. Imagine if, instead, it was like a tray for optical media... the machine sees the button press as a *request* and then handles it WHEN IT IS CONVENIENT to do so.
But that only works *once*. Thereafter, the holes in their retinas prevent them from seeing the BUSY light :-/
So make sure the user is still busy doing something else! Be creative...
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Hold button to write! Warning, releasing button before LED stops flashing may corrupt data!
How about one of those capacitive proximity sensors that are used in monitor controls to set off a moderately loud urgent-sounding beeper if the user gets a finger near the destruct button? Not sure they are fast enough, but it might work.
The idea to put the OS in charge of ejecting the SD card makes perfect sense from a UI point of view. This is what Apple did with floppy disks and CD drives for the same reasons. However, the fly in the ointment is that adding power eject to an SD card socket would quadruple the price and double the size of the socket, which is probably why it hasn't been done.
It predates that. Historically, the OS was involved in unmounting all media. Whether it could interfere (mechanically) or not. E.g., spinning down a disk pack, unloading a tape, etc.
The problem with media cards is that there is little "notice" given to the OS that this event is about to happen. I.e., if you take a tape transport offline, the transport is still electrically communicating with the "computer" so it knows what is happening. Yank a media card and the card is *gone*. Unceremoniously.
I think a bigger reason is that media cards tend to be written/accessed intermittently. I.e., you take a photo and the image is written to the card. You erase a photo and the file system is updated to reflect its deletion. You copy an application onto a card. You delete an application from a card. You update a "database" (generic sense of the word) stored on a card. etc.
These are all small, sporadic operations. On the order of seconds of activity with seconds/minutes/hours *between* operations.
Imagine XIP from a card and you have an entirely different usage profile!
I sent off some sketches and a crude mockup to the IE to see if he can make the scheme I came up with "less obvious". Then, I'll see if the ME can make a suitable mechanism *fit* the space I've set aside for it!
Then there is the NEED thing. I can guarantee you "it wasn't done" because it is simply a stupid idea.
One ejects LARGE media elements. Miniature or small elements are always handled by hand, and many end up under a cover (cameras) or door.
You want a protection? Put a door on it WITH a switch, and write the driver such that opening the door sets off a "drive release" event. Add a couple LEDs or a bi-color LED, and you can show status as well. Far easier and cheaper and more reliable than trying to make a lock/release/eject mechanism.
Total set-up error. Your boot loader is where you curtail such behavior, and set up time-outs so you can select. Most also auto-boot the last selection made in the previous boot.
Even old "slow" machines boot immediately if set-up properly. If the loader passes the boot sector location (which it does), the machine boots. Period.
Shutting down a Windows machine involves a series of "save state" operations.
They *could* perform them on an "as we go" manner, but that would be a performance hit, and doing it AFTER you tell it you no longer need it (the PC) tells the OS, any clean up times are insignificant as you are no longer using the machine.
Actually having looked at the issue, it turn out that many services have to be shut down in an orderly fashion (especially in a networked environment) or they are very slow (attempting error recovery) to start = up again. Likewise parts of the hardware are like that now as well, network and disk stuff for example.
The same sorts of issues apply to *similar* devices. I.e., you can't hope the user can be "kept preoccupied" while you finish tidying up the house... (and disk drives are usually more optimized than memory cards in that respect)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.