Hey community,
I’m writing firmware updates for our mbed os- based embedded application. To store the downloaded file, I’m using the LittleFileSystem mounted on a FlashIAPBlockDevice. The problem comes with order of access to the file. If I write into the file chunks of 1024 Bytes in-order it uses up 80KB with a 100KB BlockDevice. If the order of access is randomized, a write access returns no more space at almost 60% space utilization. Sample application code demonstrating this is given below:
int main ()
{
FlashIAPBlockDevice internalBD ((uint32_t)0x85000, 100 * 1024);
LittleFileSystem fileSystem ("fs", &internalBD, 1024, 1024, 1024, 512);
int q = 0;
q = fileSystem.mount (&internalBD);
if (q != 0) {
Log::d (LOG_TAG, "Mount failed, reformatting");
q = fileSystem.reformat (&internalBD);
}
File file;
int res = file.open (&fileSystem, "update.img", O_BINARY | O_CREAT | O_RDWR);
uint32_t ulOffset = 0;
uint32_t ulOffsetActual = 0;
char pacData[1024];
for (int i = 0; i < 1024; i++) {
pacData[i] = i;
}
int lResult;
uint32_t ulBlockSize = 1024;
uint32_t lowOffset = 0;
while (true) {
ulOffsetActual = ulOffset;
if ((ulOffset / 1024 > 20) && (0 == (ulOffset / 1024) % 10)) { // Change offset to 0 for every 10th chunk
ulOffsetActual = 0;
}
printf ("Block = %d\r\n", ulOffsetActual / 1024);
lResult = file.seek (ulOffsetActual, SEEK_SET);
if (0 <= lResult) {
lResult = file.write (pacData, ulBlockSize);
if (lResult < 0) {
printf ("ERROR - fwrite failed\r\n");
}
}
else {
Log::d ("ERROR - fseek failed\r\n");
}
ulOffset += 1024;
}
return 0;
}
It seems like a very curious problem and so far I couldn’t find an explanation in the doc or otherwise online. Would be nice to have some input/ discussion on this!
Best regards,
Saad