Lpc2000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Walsh wrote:
> Bertrik Sikken wrote:

>>And have you tried the WRITE_MULTIPLE_BLOCK command?
>>- From what I've read in some of the sandisk documents,
>>their flash products internally use blocks much larger
>>than a single 512-byte sector, so using the WRITE_MULTIPLE_BLOCK
>>command may help to write more efficiently (faster, smoothly) and
>>probably also reduce wear of the flash medium.
> 
> The program is not structure for Multiple Sector operations.  However, 
> using Multiple Sectors is problematic at best.  To effectively write 
> data in chunks larger than 512bytes, you would have to configure the 
> BLOCK_SIZE (CMD51) so that both reads and writes would use the larger 
> block.  This becomes a huge problem of now that you have to deblock down 
> to a smaller size to utilize 512byte sectors within the RDCF2.
> 
> Doing Multiple Writes of a BLOCK_SIZE of 512bytes gains you nothing.  
> Each BLOCK_SIZE of data is treated by the SD/MMC as a unit which must be 
> programmed, regardless of the physical blocking on the device.

I have no data on what CMD51 does, but as far as I know, the block
size cannot really be modified. Reading a block smaller than 512
bytes is possible, but writing only allows 512-byte blocks.

According to the documents I have, the WRITE_MULTIPLE_BLOCK can
actually improve performance. For example, it says:
"If speed is critical in a design, Multiblock mode is the faster
and recommended mode.  The more blocks that can be written in
Multiblock mode the better the performance of the design."
and also
"In order to re-write a single 512 byte block, all other blocks
belonging to the same Erase Block will be simultaneously erased
and need to be rewritten."

On the other hand, I understand that it's not quite a natural
match to use multiple blocks with FAT.

> 
> Why not take the RDCF2 code and try some of this out?

Yes, I did. I modified your code to use SPI0 instead of SPI1 + some
other modifications to make it run on my hardware (a LPC2148 quickstart
board + prototype board from embedded artists). Reading seemed to work
fine, but I couldn't get writing to work yet.

I also hope to get some real-world numbers for single vs.
multiple block writes this weekend.

>>I'm looking into this for my hobby project, a digital bat
>>detector. It records ultrasonic bat audio at around 250 kS/s
>>and writes it directly onto a flash disk. This recording can
>>then be slowed by 16 times to make it audible to humans or be
>>read in on a PC for frequency analysis.
>>Since the data is coming in at a steady rate and there's not a lot
>>of RAM to buffer incoming samples, I think I have to be careful
>>to avoid delays when writing to the flash.
>> 
>>
> 
> So, treat the MMC device as a block mapped device rather than a file 
> structured device.  You won't have a filesystem on it, but you'll have 
> your data.   You can use dd to extract your data.  If you are are under 
> cygwin the dd command should be there.  Under windows itself you would 
> have to write some software to do what un*x gives you for free.

Indeed, doing it that way is probably the best way to initially get
something working. Eventually I really like to use a file system.
I'm thinking of a kind of hybrid solution, where I let an existing
FAT driver (yours, or perhaps the embedded-file-system-library)
create a relatively large file for me. Then, when actually starting
the recording, my program simply rewrites the data portion of the
file. For that, I only need a way to make sure that the file is
contiguous and a hook to find out the first sector.

All the best,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDiJXCETD6mlrWxPURAl0iAJ92UTktAhVgY1RV/Jkt477tRIyHQgCgjYJC
9i9ZI7AqNB8rpls70pjdLjk=
=m2ps
-----END PGP SIGNATURE-----