FAT32 write speed

[electroman2000]

I have tested the SPI speed for sending one byte, using the egister of PIC and so function of mikroC is not involved in my code.
I only initializated the SPI with mikroC function, but previousy I verified that the initialization is correct.

I register the initial time, final time and a number of overflow trought interrupt, so I can register the time for sending a byte to SD trought SPI.
I set the divisor=4. So 80 Mhz/4 = 20 Mhz = 20 Mbps. For sending 1 bit, it takes 1/20=0.05 us = 50 ns. So for 1 byte it takes 400 ns.
I set the TIMER with divisor=1, so the period of timer1 is 1/80= 12,5 ns. The final counter is 68, so the total time taken for transfering is 850 ns. This is twice the theoretical time .

Yes, indeed. That are the same time values I measured earlier: See http://www.mikroe.com/forum/viewtopic.p ... 4&start=21 (the third oscillogram). As you can see, the time to generate 8 clock pulses is 400 ns, while the total byte time is 800 ns approximately.

p.s. You use an SPI speed of 20 Mhz now. Does the SDMMC tests you did earlier with 10 Mhz (SPI clock divisor eight) now work with 20 Mhz (SPI clock divisor 4)?

no, it still not works. If I set SPI clock divisor 4, simply nothing is write on SDMMC. I think this is the final proof that the problem is inside FAT32_Init() function, that can't support the higher speed.

[filip]

Hi,

I will try FAT32 using your configuration and see if I can help you.

Regards,
Filip.

[electroman2000]

Hi filip,
thank you. If you need any information about my code, of course you can ask.
Also I can add that, from a discussion with other expert users on internet, the problem may be the unsupported multi sector write mode.

[Dany]

Hi, here in my test environment the clock divisor of 4 (SPI clock of 20 Mhz) works without any problem... I use a 4GB micro SDHC card from brand "Integral".

The testcode is (on Mini-32):

MCC_Test.zip

(1.63 KiB) Downloaded 446 times

[electroman2000]

Hi, here in my test environment the clock divisor of 4 (SPI clock of 20 Mhz) works without any problem... I use a 4GB micro SDHC card from brand "Integral".

The testcode is (on Mini-32):

MCC_Test.zip

did you print the time that you have obtained?

Finally I think I have to implement multi sector write and fatFS file system. A pity that mikroC doesn't support these.

[Dany]

did you print the time that you have obtained?

The time usually needed was 566ms to write 100 Kbyte. This means a speed of 176 Kbyte/second at 20 Mhz SPI clock. As you can see it is far from the double speed at 10 Mhz...
I say usually because sometimes it is larger (upto 25%). I gues more retries? The larger time needed is there sometimes to with an SPI clock of 10 Mhz, but less pronounced...

Finally I think I have to implement multi sector write and fatFS file system. A pity that mikroC doesn't support these.

This will be a lot of work...
The mmc routines do provide multi sector read/write, so you can already do some speed tests to see how much the benefit is.
Fat32 itself indeed only uses single sector read/writes as far as I know. (not sure).

[electroman2000]

The time usually needed was 566ms to write 100 Kbyte. This means a speed of 176 Kbyte/second at 20 Mhz SPI clock. As you can see it is far from the double speed at 10 Mhz...
I say usually because sometimes it is larger (upto 25%). I gues more retries? The larger time needed is there sometimes to with an SPI clock of 10 Mhz, but less pronounced...

yes, this is in agree with our previous considerations.

This will be a lot of work...
The mmc routines do provide multi sector read/write, so you can already do some speed tests to see how much the benefit is.
Fat32 itself indeed only uses single sector read/writes as far as I know. (not sure).

yes, it is a lot of work if I do it from the beginning. But I found a cool library that implement fatFS and it is indipendent from the platform used. This is the link: http://elm-chan.org/fsw/ff/00index_e.html
At the bottom of the page there is last version of the library, updated less than one month ago.
I just have to understand how adapt it to work with PIC32. The examples provided include an example for PIC24, I looked it for figure out how to adapt the library for PIC32 but I still don't undersand how to do.

[electroman2000]

I'm trying to adapt fatFS and integrate it with my mikoC code. I think this is not much difficult, but I'm having troubles.
I downloaded the examples from previous link. The example are updated with the latest version of fatFS. I extract the PIC24 examples, and modifid the pic24.h. It is not much work, only few part of code marked as "platform dependent").
in my folder there are ff.c, ff.h, diskio.h, integer.h, ffconf.h. I haven't modify none of theme. I have rename pic24.c in diskioPIC32.c, and modify it whit platform dependent function. Then, I create a project and a main file, include only ff.c and ff.h, and use the functions disk_initialize() and f_open(). During the compilation, I needed to delete windows.h because my compiler doesn't have it. But still the compile didn't work, in this section of ff.h:

Code: Select all

 
typedef struct {
BYTE fs_type; /* FAT sub-type (0:Not mounted) */

the console show me an error: " ';' expected but 'fs_type' found " and some other error such as redefined variable (WORD and DWORD).

I think I'm wrong in understanding of project structure

[electroman2000]

I attached my project file. It is a project that use fatFS, and inside the file diskioPIC32.c there are the platform dipendent section of code. I modified them based on my configuration of SPI and CS pins.
Now, if I try to compile, I obtain an error about windows.h and tchar.h, included in file integer.h. But in integer.h I see the ifdef, and I want compile the "embedded" section, not the windows section. If I try to delete the ifdef, I obtained the error that I have explained.
Also, in the integer.h I see this section:

Code: Select all

/* These types MUST be 16 bit */
typedef short			SHORT;
typedef unsigned short	WORD;
typedef unsigned short	WCHAR;

but short and unsigned short are 8 bit, so I have to modify it in int and unsigned int (that are 16 bit) right?

[Dany]

The mmc routines do provide multi sector read/write, so you can already do some speed tests to see how much the benefit is.

Did you already do this test? If it is negative (not fast enough) that adapting a Fat32 system to use multi sector read/write is useless...

I attached my project file. It is a project that use fatFS, and inside the file diskioPIC32.c there are the platform dipendent section of code. I modified them based on my configuration of SPI and CS pins.
Now, if I try to compile, I obtain an error about windows.h and tchar.h, included in file integer.h. But in integer.h I see the ifdef, and I want compile the "embedded" section, not the windows section. If I try to delete the ifdef, I obtained the error that I have explained.
Also, in the integer.h I see this section:
but short and unsigned short are 8 bit, so I have to modify it in int and unsigned int (that are 16 bit) right?

Unfortunately your project is in C, and I have only a very poor knowledge about it. I have no idea how the problems you indicate can be solved or what the asnswer is to your C type questions... I am a Pascal user...

[electroman2000]

The mmc routines do provide multi sector read/write, so you can already do some speed tests to see how much the benefit is.

Did you already do this test? If it is negative (not fast enough) that adapting a Fat32 system to use multi sector read/write is useless...

hum, I'm not sure that I have understand, but the FAT16 library of mikroC is only for PIC16/18, so I can't test it on PIC32

BTW I hope someone of the staff can help me, because I really think that the error in code is due to mikroC. This because I downloaded a tested code and made a few part of code that can't generate the error that I have.

[Dany]

The mmc routines do provide multi sector read/write, so you can already do some speed tests to see how much the benefit is.

Did you already do this test? If it is negative (not fast enough) that adapting a Fat32 system to use multi sector read/write is useless...

hum, I'm not sure that I have understand, but the FAT16 library of mikroC is only for PIC16/18, so I can't test it on PIC32

I see now that the routine "Mmc_Multi_Write_Sector" does not exist, only the routine "Mmc_Multi_Read_Sector" (in the PIC32 mmc library). I do not know why, perhaps it is not possible with SDmmc cards.
So, this is no solution to enhance the write speed...
Perhaps there is a possibility to develop faster "mmc_read_sector" and "mmc_write_sector" routines.

p.s. the Fat32 library is hardware independant. The user of this library has to provide 4 routines (used by the Fat32 library) that contain the HW (mass storage type) dependancy:

The following routines must be defined in all projects using FAT32 Library: Description:
function FAT32_Dev_Init () : int8; Initializes storage device.
function FAT32_Dev_Read_Sector (sc : dword; buf : ^byte) : int8; Reads contents of the sector s on the storage device into the buffer buf.
function FAT32_Dev_Write_Sector (sc : dword; buf : ^byte) : int8; Writes contents of the buffer buf on the sector s on the storage device.
function FAT32_Put_Char (ch : char) : int8; Writes single character on the output device, i.e. UART. Used by FAT32_Dir() for displaying contents of the current directory.

In these 4 routines the hardware routines are to be called e.g. "mmc_write_sector" in routine "FAT32_Dev_Write_Sector".

[electroman2000]

yes, multi_Write doesn't exist, only multi_read exist. This is one of the first things I checked.

For the routine, mikroC automatically calls subroutine, e.g. FAT32_Dev_Write is hust the incapsulation of the function MMC_Write_Sector; this can be viewed in the example of FAT32_Dev_Write, where is explained its declaration.
Also I done the time try with both FAT_32_Dev_Write and MMC_Write_Sector and there is no difference in bheavior and time elapsed for writing 512 byte.

[electroman2000]

Finally, with the help of an expert C user, I found that the problem is mikroC compiler, wich cannot handle certain kind of cast. I don't know why, but in the code there are some mathematicl operation with pointer etc that mikroC cannot handle. Modifing these part of code, mikroC can compile the fatFS library, but in the execution strange things happens. For example I ty to read from a file, and it works only in debug mode; this is probabily a SD initialization problem, because in normal mode is too fast, even I set the correct value for primary slow initialization. This thinks made me crazy because if I executed the code in debug mode and then in normal mode, the normal mode worked. After a lot of try I figured out that the normal mode worked only because the SD kept initialize from the debug mode; indeed if I shut down the board and then power on it, the normal mode does't work.

A question about fat32 library; it is possibile open file in fat32 mode (even if it was created as swap) and reduce filesize?

[Dany]

Any progress?