This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Knowning your way in a file system

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?

Parents
  • 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>

Reply
  • 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>

Children