Hello, My apologies for asking a question that is not strictly Keil related, but I know that there are people here with different backgrounds of experiences - maybe one of you can help me? I am using the Keil tool set so cut me some slack...
I need to build a system that has one simple property: depending on the requested folder by the host, the device must provide the contents of differnet peripherals. to be more exact: The device itself is a USB mass storage device, and I can already display the contents of an on-board SD card, and a piece of RAM dedicated to hold FAT12. that is not the problem. the real issue is that I must be able to tell accesses to specific folder apart, in order to provide the host with the appropriate data. I have a feeling that the host, asking the device data in blocks of 64 bytes each, knows more than the device. the host knows which folder you want to browse and interrogates the device's FAT (reading even more than it needs), in which it can search for the right entry and address the disk at the proper location (again, the host asking a certain sector could also mean that the required data starts at a certain offset from the beginning of the sector - but does the device know that?). since I am operating in the realm of the device only - can I achieve the same? or: how can I make sure that browsing into folder "SD" will yield the contents of the file system of the SD card, while "xram" the content of a file system in external RAM?
what I can do is have my file system in RAM, and associate codes with offsets of folders in the root. when an SCSI commands reads such code, it is a signal to redirect the data flow.
Hello Michael,
You want to provide different sets of data residing in different folders - right ?
So first thing is that you must get away from thinking "data-wise"
If you want to be an USB Mass storage, all you have in hand are always SECTORS. The organisation of them is beyond your control and always OS-dependant.
If you want to pretend to be a FAT12 disk, you need to set up the initial data sectors to hold valid data, eg the boot sector, die FAT and the directory entries. You can see that in the Keil sample.
So this is what you would need (just roughly to clarify)
Rootsector FAT Rootdirectory containing directory entries to point to your intended subdirectories
these subdirs need directory entries for your files and finally you need the "files"
so when you want the OS to access a file, it will read root, then subdirs and then access the file via read_sector. This is the point where your data need to be prepared and be sent to host
Maybe you should just think of say four files in root containing different data (if the naming incl paths is not fixed from somewhere for whatever reason)
this yould be a stage easier
Rootsector -> rootdir -> containing directory entries for FILE_A (FAT points to say sector 14 FILE_B -> Sec 15 FILE_C -> Sec 16
every read access to sec 16 then means, that s.o. wants to read the file C, then you have to prepare and send the data needed for that case
and be sure to mark drive as read only or reject any write issues
you can compile all the sectors into flash as constant, (provided that it will be only a R/O device, no renaming etc) and implement a mapping from sector to be read to sector to provide.
as an exception, you may keep all the directory sectors constand too, but copy them into ram prior to use and then update the timestamp of the files as appropriate.
You will need detailed knowledge of FAT. For example there are usually two copies of FAT, but only one is mandatory (according to MS). But some OS-drivers rely on the existence of two. So you can compile one constant FAT copy into flash and pretend to have two and map the read sector commands appropriately.
Check the Keil sample thoroughly and see eg en.wikipedia.org/.../File_Allocation_Table and the links there.
Btw the original Keil FAT was bogus causing a checkdisk to always complain about its structure:
Just imcluding my mail to Keil from Oct 2008 here, no idea whether they fixed it meanwhile (bet not ;(
===================================================== <bla bla>
I found mistakes in the Mass Storage Sample and the predefined disk data structures
first, least important, according to FAT-spec in BPB at offset 0x13 is the disk size in sectors. the constant code wires this hardly to 0x20, while there should be a relation to the define/constant MSC_BlockCount
2) why are there two cluster sectors ? one should be sufficient for 0x20 sectors (and in this case clusters too)
3) most important: the initial FAT is wrong as it looks like a FAT16 type (I guess) where it should be FAT12 instead
here's the first line of data of the FAT as it is defined in the constant data area's const unsigned char DiskImage[MSC_ImageSize]
original code: 0xF8,0xFF, 0xFF,0xFF,0x FF,0xFF, 0xFF,0x0F, 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
my code 0xF8,0xFF,0xFF,0xFF,0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
the original code causes checkdisk to complain, while it accepts mine ;))
<bla bla>
is that thread related to your problem ? http://www.keil.com/forum/docs/thread14441.asp why emulate two devices ?
it should be possible to have more than one partition on a single device. so just provide a proper partition sector and different partitions on it all on your (single) mass storage device.
maybe you first describe the task here in more detail ;)
cheers
Uli
Ulrich, thanks for your reply. I have solved the bad fat entries by formatting a mass storage device using windows format, placing the folders I need and dumping the RAM...! I will have to make hard links within FAT12 to certain data sources. currently I have a 1.44 MB RAM disk, and I will have to place some codes at the offset where the file "begins" according to FAT12. where a SCSI command to read that sector arrives, I will provide data from the appropriate source.
Ulrich, I will work with one drive only. I managed to get the LUN solution to work but it will incur a RAM cost/complexity cost that I cannot afford. thanks for your tip anyway.
Remember that all your files will need to have a fixed size, since Windows will cache the directory and FAT. So you may have your on-the-fly-generated data pad with a lot of spaces or empty lines in case the data you generate are in ASCII format. If it is in binary, then it is probably already fixed-size.
Another problem you will have is that Windows will assume that it can cache your files too, so you may have troubles if Windows is expected to read the same data multiple times and get updated data all the time.
automatic USB disconnect/reconnect might help, but then you'd be able to permanetly turn off the "new drive found" popup