Hi,
I think (b) is more commonly failure of flash over time, and writes
and/or erases that fail. Some times bits will be “stuck” on
flashes, especially inexpensive ones in high volume consumer products
that have no correction for this. The probability that this will
happen
across a population of millions of devices is probably pretty high,
and
the bugs are hard to find.
The failure were bits will be stuck is both (b) and (c). There is no
reason
why the stuck bits would not appear in the len data.
Yup, my concern is making sure that invalid data is not passed up to the
higher layer, which I think would be the case with FCB now. I think in
production, over a population of devices, this will manifest itself as
random crashes.
I guess by magic you mean some kind of recognizable start record, this
would certainly limit the data you can store in fcb.
Maybe we can team up to create a fcb2, taking some ideas from fcb and
some of nvs and create a basis that is easily extended to different
kind of
records to be stored in flash.
Definitely, I think this would be great.
I am thinking about:
a. using a allocation entry table at the end of a sector
b. define the allocation entry as:
type + len + offset + ate crc (1 byte) + data crc (2 bytes)
where: type can be used to determine what is inside the data:
0: record without specific meaning (fcb today)
1: record contains data id (16 bit) followed by data
2: record contains data name (string finished by \0) followed
by data
c. nvs and possibly other storage solutions are added on top of fcb2.
d. write in such a way that streaming is allowed
I agree. I think interleaving the various types is also important (as
you reference above), as I think it would be good to share flash storage
areas with one big FCB that could be used for config/other elements.
Sterling
