PDA

View Full Version : Microchip SST26VF064B (64Mbit Serial Flash)



wjsmarine
- 11th April 2021, 08:28
Hi All,

I have some Microchip SST26VF064B (64Mbit Serial Flash) parts on order and, while I wait for their arrival, I'm wondering if any Forum users have experience using this family or similar with PBPro. A forum search did not yield any results.

It is a logging application and I want to move away from using SD cards and connectors.

Anyone?

Thanks and regards,
Bill

richard
- 11th April 2021, 10:48
my spi flash addin for the tft displays would probably handle those chips , it simply uses however many 64k blocks are needed, each as 16 x 4k pages to cover the expanse
pretty simple , has r232 serial i/o routines to load in data too.
personally i would use an esp32/8266 and spiffs or littleFS these days. why struggle with ancient underpowered tech

wjsmarine
- 12th April 2021, 04:36
Hi Richard,

Thanks for your input.

I took a look at your TFT addin and it is heavy going for me to understand what's happening as most is in assembly. I'll try the code when my parts arrive and may have to order some W25Q32BV parts if mine aren't successful.

I did a search for and read about your suggested file systems, interesting, but I want to keep using PICs. Call me old fashioned however I'm comfortable with PicBasic and find the code environment for Arduino, ESP32, etc,. cryptic and confusing. I'm sure that most of the forum users will agree with me and am surprised routines for Flash haven't attracted much comment or attention.

Thanks and regards,
Bill in Perth

richard
- 12th April 2021, 11:03
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
- 14th April 2021, 02:16
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
- 14th April 2021, 04:59
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