Microchip SST26VF064B (64Mbit Serial Flash)

[richard]

it is heavy going for me to understand what's happening as ̶ ̶m̶o̶s̶t̶ ̶i̶s̶ ̶i̶n̶ ̶a̶s̶s̶e̶m̶b̶l̶y̶ a tiny little bit of assembly code is sprinkled in for speed
99% of the asm is for usercmd not really code per se.

i can't see any way to make a flash FS that's any less complex or resource hungry than a fat16 or fat32 sd card system , hardly worth the effort
for such a tiny storage space. my system was for storing images with a 8.3 file name and their width, height, size in 64k blocks
the files can span up to two blocks at least [can't remember].
i spent a week trying to come up with a FS that could allocate the 4k sectors in such a way that files could grow and/or be erased. i was hoping
to develop a fat that handled a list of free blocks and a linked list of allocated blocks for each file that did not wear out that region of flash.
the task was simply beyond me. i did come up with this rather manual scheme, it did the job at the time.

[wjsmarine]

Hi Richard,

I take your point however in my logging application I don't need a file system.

Presently data is being streamed via 4G and the planned logger will be there only to safeguard against Telstra comms failures - not frequent but has occurred leaving 'holes' in data that compromises the modelling. After such an event a second modem port will allow a remote connection to interrogate the logger, search for the time/date wanted and download the missing information.

I plan on using the Flash as a lump of memory with each 15byte record [GPS time/date stamped+data] being written contiguously. The only housekeeping necessary will be to stay within the bounds of the device's page/block and address limits. I'm using a large Flash size to maximize time before overwriting of cells becomes necessary and expect to get near 1 year of 1 minute records before this happens.

Any further thoughts or comments you may have are welcome.

Cheers,
Bill

[richard]

which is what I did. its a way to break up the flash data space
enabling reading, writing and erasing of data in a pic sized way
yet deal with large data structures normally beyond a pic's scope.

search for the time/date wanted and download the missing information.

just looking at that requirement makes me think a sudo file structure
would be an enormous advantage ,
think of flash structure , 125 64k blocks , each block has 16 4k pages .

each page could hold 256 16 byte records depending on how many records per day/week whatever will fit in a block. eg. a new block[file] every fortnight
a new page every day sort of thing makes life easy
{its what i use , a record ever 6 mins) [if your storage is timed accurately the timestamp is redundant]
you can do a bit of wear levelling by offsetting the day page and have a simple ring structure