The Issue
I'm trying to dump binary data to a file every 36ms. Most of the time the SPI phase of the data dump is about 14ms of the 36ms. Sometimes it takes longer. There are a few times where the SPI phase is taking as long as 199ms. Once the FS_Write() operation takes longer than 36ms, there is a potential loss of data.
I placed a framing pulse around the FS_Write(). Using the framing pulse we can see the FS_Write() is a blocking function. Is there an non-blocking FS_Write() function?
Is it possible that the caching is causing this issue?
I noticed in the release notes that the caching API calls to control cache characteristics were removed in V3.14. Therefore I cannot seethe cache API calls mentioned in the “UM02001_emFile_V322c.pdf”.
The goal here is to find a way to store the binary data to the SD card a a constant rate without loss of data. If this is a caching reclamation issue, is there a way to minimize caching effects?
Len
I'm trying to dump binary data to a file every 36ms. Most of the time the SPI phase of the data dump is about 14ms of the 36ms. Sometimes it takes longer. There are a few times where the SPI phase is taking as long as 199ms. Once the FS_Write() operation takes longer than 36ms, there is a potential loss of data.
I placed a framing pulse around the FS_Write(). Using the framing pulse we can see the FS_Write() is a blocking function. Is there an non-blocking FS_Write() function?
Is it possible that the caching is causing this issue?
I noticed in the release notes that the caching API calls to control cache characteristics were removed in V3.14. Therefore I cannot seethe cache API calls mentioned in the “UM02001_emFile_V322c.pdf”.
The goal here is to find a way to store the binary data to the SD card a a constant rate without loss of data. If this is a caching reclamation issue, is there a way to minimize caching effects?
Len