I need random access to write sectors of a file. I receive data in mostly sequential order, but I need to go back to patch some sectors when I receive them (ESPNOW). All access is sector-sized (1kB). Only 2 functions would be needed:
- spiffs_allocate(file, size) - sets the file-size and reserves the necessary amount of sectors
- spiffs_write_sector(file, sector, contents) - write a sector (once suffices)
Maybe these functions already exist?? spiffs_allocate() would be similar to ftruncate() under POSIX.
fopen, fread, fwrite would continue to work as normal.
Alternatively, I could give up on the wear levelling and the flexibility SPIFFS offers and use an OTA partition to receive and compose the file at known sector locations. Most files are in fact several types of firmwares.
I'm new to the spiffs internals, any help much appreciated!
PS note that using the C API would be possible, but cumbersome, slow, destructive to the flash, and energy inefficient to the point of not being viable.
Modifying SPIFFS to allow direct sector access
Re: Modifying SPIFFS to allow direct sector access
Thanks for eye-balling this. I know it was kind of a long shot (I have a deadline approaching). It is now an issue on github:
https://github.com/pellepl/spiffs/issues/226
I really think this capability (receive data without the micromanagement of linearizing the data stream) is essential for embedded in terms of power budget, throughput and durability of the flash. I estimate the difference in performance to be at least 5, maybe even 100x in my case, because multiple devices catch whatever fragments they can get from the air while another device is receiving the file and acknowledging it.
Thanks.
=== update ===
You can rewrite parts of the file with mode "w+" (first seek to the start of the section to be rewritten), as long as the start of the section already exists, or is the end of the file. Nevertheless inserts are even slower than regular file ops, and very irregular, so the net gain is not much.
https://github.com/pellepl/spiffs/issues/226
I really think this capability (receive data without the micromanagement of linearizing the data stream) is essential for embedded in terms of power budget, throughput and durability of the flash. I estimate the difference in performance to be at least 5, maybe even 100x in my case, because multiple devices catch whatever fragments they can get from the air while another device is receiving the file and acknowledging it.
Thanks.
=== update ===
You can rewrite parts of the file with mode "w+" (first seek to the start of the section to be rewritten), as long as the start of the section already exists, or is the end of the file. Nevertheless inserts are even slower than regular file ops, and very irregular, so the net gain is not much.
Who is online
Users browsing this forum: Bing [Bot] and 115 guests