2020-06-28 11:35 PM
2020-06-28 11:59 PM
Typically not used due to block sizes and relative slowness of erase/write.
Going to have own task of developing DISKIO layer to interface with the QSPI BSP you've created for your board.
2020-06-29 12:03 AM
Thanks Clive 1 for prompt response,
are there any other cons of using FATfs over QSPI flash, I know it will be slower but because it will be standardized so client want to use it.
on Block sizes do you mean to say, each file will consumed 64Kb block even though the file size is small?
2020-06-29 12:12 AM
What is the minimum erase block size for the device chosen, check data sheet.
People normally use eMMC for chip equivalents to SD cards, for block, wear and defect management.
2020-06-29 12:15 AM
minimum erase is possible for 4kb subsector
2020-06-29 12:20 AM
So tell FATFS that, and code your DISKIO layer to read / write with those size blocks.
Test for function and robustness outside FATFS.
2020-06-29 12:25 AM
ok...thanks for your inputs.
and I'll need to write to this flash in normal running as well as just before power goes off. so there will be mechanism to detect low power and before it completely shuts, needs to write some information may be 20-30 bytes into flash. do you think it will be doable using FATfs.
I was thinking to create a empty file when unit is powered up, save this file handle, whenever there is low power detection use this handle and write data to this file. I know this can be easily done w/o FATfs when all memory locations are pre-defined. but just checking if this can be achieved using FATfs.
2020-06-29 12:45 AM
Not sure holding a handle here helps the situation as the critical path is writing file content and file system structures.
NVRAM/BKPRAM probably a better solution for small byte arrays and chasing a collapsing supply.
A pre-erased block of flash would be simpler than involving file system.
Jouralling file system less likely to self immolate.
2020-06-29 12:50 AM
ok...thanks for your suggestions.