5 Dec
2010
5 Dec
'10
5:22 a.m.
On 12/4/2010 2:31 PM, Chuck Guzis wrote:
On 4 Dec 2010 at 19:33, Tony Duell wrote:
That's a very good
point. I was rather naively thinking of a vintage
system that is used only very occasionally. That notion may be valid in
some instances, but obviously not always. If you are going to be doing
much writing to the flash, I think you would need to do flash wear
leveling in the bridge device. If you are running an OS which (like
some I could mention) seem to access the disk drive fairly frequently
for no apparent reason (reading? writing? I'm never sure) then you
should probably not consider using a flash drive at all unless you have
enough RAM to make most of the writing unseen by the flash. Then of
course you must be sure the write from RAM to flash occurs when power is
about to be lost. This is starting to sound pretty complicated. I'm
sure most of the new SSD's take all of that into account. Maybe what is
really needed is a SCSI to SATA bridge. :-)
Later,
Charlie C.
--and to
As far as I know, there is nothing in the SCSI
spec that specifies a
minimum data rate or a maximum seek time. Soyou could even read 1 byte
out of an SD card and then send it over the SCSI interfce, and then do
the net byte, and so on. It would probably be better to buffer a
'sector' in RAM on the microcontroller, and then transfer the buffer
to the SCSI interface.
There's an excellent argument for heavily cache-ing SD card accesses
when using it as a hard disk--to minimize repeated writes to a block
(usually 16K) of SDRAM to extend longevity of the medium defer much slower writes as much as possible for
performance reasons.
If reading speed was an issue, one could employ the faster 4-bit
access to SD rather than the simpler and much slower SPI mode that's
usually used for slow embedded applications.
--Chuck