PIC24和mla在SD上写入速度很慢

我不知道MC是否改变了MLA处理SD卡操作的方式，但是几年后，当我为我的PIC24FJ256GB206板实现SD卡接口时，我意识到它比我想要的慢很多。而且，在寻找解决方案的过程中，我发现了一个讨论速度问题和R的线程。慢速性能的简化。基本上，无论实际数据有多大，MLA总是执行单个扇区循环，因此它不利用SD卡接口本身提供的更大块中顺序数据写入的高得多的速度。但是开源库FatFs没有此限制。也是一个更瘦的系统（不像McCIP系统那样使用闪光灯），所以我切换到FATFs，从那时起它就一直运行良好。



      以下为原文

    I don't know if MC has changed the way MLA handles the SDcard operations, but a few years back when I implemented the SDcard interface for my PIC24FJ256GB206 board I realized that it was a lot slower than I wanted.
And looking for solutions I found a thread here that discussed the speed issues and reasons for the slow performance. Basically the MLA always does a single sector cycle no matter how big the actual data are so it does not take advantage of the much higher speeds for sequential data writes in larger blocks which the SDcard interface itself offers.
But the open-source library FatFs does not have this limitation and is also a leaner system (does not use as much flash as the Microcip system does).
So I switched to FatFs and it has worked fine ever since.
 

PIC24是否有正式发布FATF？



      以下为原文

    Is there an official release of FatFs for PIC24?

FATFS在PIC32通用FATFS文件系统模块上实现，在这个页面上你会找到一个链接，可以链接到各种平台。这是一个ZIPFILE。这些链接应该让你开始。如果你在这个MC论坛上搜索FATFS，你可能会发现最近讨论的低级接口必须为每个具体的硬件实现提供给FATFS。



      以下为原文

    FatFs Implementation for PIC32
Generic FatFs file system module
On this page you will find a link to examples for various platforms. It is a zipfile.
These links should get you started.
Also if you search this MC forum for FatFs you will probably find recent discussions talking about the low-level interface that must be provided to FatFs for each specific hardware implementation.
 

测试FatFs。我在这里找到：FATFPIC24PIC24FJ128GB204与FoCC 32兆赫，SPI时钟频率8兆赫，FAT32 4GB，优化1。结果：109kb/Si保证它是慢的时钟速度。什么是错误的？



      以下为原文

    Test with FatFs.
    if (f_mount(&FatFs, "", 1) == FR_OK) { /* Mount SD */

        if (f_open(&Fil, "hello.txt", FA_OPEN_ALWAYS | FA_READ | FA_WRITE) == FR_OK) { /* Open or create a file */

            if ((Fil.fsize != 0) && (f_lseek(&Fil, Fil.fsize) != FR_OK)) goto endSD; /* Jump to the end of the file */

            
            T1CONbits.TON=1;
            
            f_write(&Fil, (const void *) 0x108e, 6000, &bw); /* Write data to the file */
            f_write(&Fil, (const void *) 0x108e, 6000, &bw);
            f_write(&Fil, (const void *) 0x108e, 6000, &bw);
            f_write(&Fil, (const void *) 0x108e, 6000, &bw);
            f_write(&Fil, (const void *) 0x108e, 6000, &bw);
            f_write(&Fil, (const void *) 0x108e, 6000, &bw);
            f_write(&Fil, (const void *) 0x108e, 6000, &bw);
            f_write(&Fil, (const void *) 0x108e, 6000, &bw);
            f_write(&Fil, (const void *) 0x108e, 6000, &bw);
            f_write(&Fil, (const void *) 0x108e, 6000, &bw);
            f_write(&Fil, (const void *) 0x108e, 6000, &bw);
            f_write(&Fil, (const void *) 0x108e, 6000, &bw);

            T1CONbits.TON=0;
            Nop();
            Nop();
            
            endSD: f_close(&Fil); /* Close the file */
        }
    }
I find it here:
FatFs PIC24
PIC24FJ128GB204 with Fosc 32MHz, SPI clock frequency 8 MHz, FAT32 4GB, optimization 1.
Results:
109KB/s
I beleve that it's to slow for the clock speed.
What it's wrong?
 

你希望它能达到什么样的速度？



      以下为原文

    What speed do you expect it to work at?

至少500 kb/s



      以下为原文

    At least 500KB/s

这是一段时间以来，我做了这件事，但你必须计算以下：一个文件的写入将总是导致写入512个字节= 4096位的完整扇区的数量将通过SPI传输。此外，当使用顺序扇区写入（如FatFs在写入大于512字节的源数据时所做的），它将对数据所使用的扇区数量进行这样的操作，那么它也必须更新FAT表，因此它会被适当地重写。在SPI上需要的时钟周期的数目，并且通过SPI时钟速度除以，您将得到传输时间。这是你估计速度时所做的吗？几年前我做了一些测试，如果我记得正确的话，我们把数据放在8 KB的缓冲区中。这是数据的16个扇区，我们通过读取系统定时器（在FCY中运行）在呼叫前后进行计时。我记得它比MC解决方案好很多，但我不记得确切的数字。可能挖出来，但需要一些时间…



      以下为原文

    It's been a while since I did this but you have to figure the following:
A write of a file will always result in the write of a number of complete sectors of 512 bytes = 4096 bits to be transferred via SPI. Also when using sequential sector writes (as FatFs does when it writes source data that are larger than 512 bytes) it will do this for the number of sectors used by the data.
Then it will have to update the FAT table as well, so it gets rewritten as appropriate.
If you count all of this you will get a number for the clock cycles over SPI that are needed and by division by the SPI clock speed you will get the transfer time. Is this what you did when you estimated the speed?
 
I did a number of tests a few years back when we put data in buffers of 8 KB if I remember correctly. That is 16 sectors worth of data and we timed the complete cycle by reading a system timer (running at FCY) before and after the call. I remember that it was a lot better than the MC solution but I don't remember the exact figures. It might be possible to dig out, but will take some time...

在上面的程序中，时间的度量是用Time1完成的。程序执行N°12的写入，为6000字节。每个6000字节是MCU必须写入的512字节的12块，总共是12×12＝144块，为587.824BIT。因此，传输时间应该是理论上的587.824/8MHz＝73毫秒。相反，我测量的时间为666毫秒，几乎超过一个数量级。基本上，结果不会随着2级或3级的优化而改变。



      以下为原文

    In my program above the measure of time is done with the timer1.
The program executes N°12 writes of 6000bytes. Each 6000bytes are 12 blocks of 512 bytes that MCU must write.
The total is 12*12 = 144 blocks that are 589.824bits. So the transfer time should be theorically 589.824/8MHz = 73 milliseconds. Instead I measure a time of 666 ms, almost more than an order of magnitude.
Substantially the result does not change with the optimization at level 2 or 3.

GueSePE83，这里有两个元素可以满足您的预期性能。1。虽然您的简单CALCS是基于您想要的时钟数据，但实际上是与SD卡通信，并通过文件分配系统。也就是说，你必须通知卡/文件系统你想要什么和多少。这是额外的开销。此开销具有与它相关联的定时和消耗处理时间的复杂度级别。记住PIC24是16MHz的16MHz，相当于80年代的PC，但没有缓冲区的640K RAM。你刚才提到它是FAT32。这意味着你要求一个16位CPU执行32位算术。当然不是不可能的，但不是单一的机器循环。我自己的经验是FAT16是最有效的CALC，甚至超过FAT12。使用SPI的最低级别访问不能通过使用“通用例程”有效地操作。通过定制您的硬件，它将得到改善。但没有办法表现两倍/三倍的速度。也许会有30%的进步。可能是SPI不是一个连续的时钟流，并在其中暂停。PIC24有一个增强的外围设备，它允许CPU加载一个16字节的读/写缓冲器，用于连续操作，或者甚至在芯片具有它的情况下使用DMA。希望这有助于T Yorky。



      以下为原文

    giuseppe83, there are two elements to your expected performance here.
1. Although your simple calcs is based upon the clocked data you want, you are actually communicating with the SD card, and through a file allocation system. That is you have to inform the card/file system what you want and how much. This is an additional overhead. This overhead has a timing associated with it and a level of complexity that consumes processing time. Remember PIC24 is 16bit at 16MHz which equates to an 1980s PC, but without the 640K RAM for buffers. You did mention that it is FAT32. This means you are asking a 16 bit CPU to perform 32bit arithmetic. Certainly not impossible, but not a single machine cycle. My own experience is FAT16 is the most efficient calc, even over FAT12.
2. The lowest level access using the SPI may not operate efficiently by using a 'generic routine'. By customising to your hardware it will improve. BUT no way to the performance of twice/three times as fast. Maybe a 30% improvement. Chances are that the SPI is not a continuous clock stream and has pauses in it. The PIC24 has an enhanced peripheral which allows the CPU to load a 16 byte read/write buffer for continuous operation, or even use DMA if the chip has it.
Hope this assists.
T Yorky