Interesting; I see what this method does for you. I still think there is a
fairly high chance of getting a false positive with a 1 byte crc but that might
not be a huge issue.
Anyway, thanks for this!
Will
> On Jul 31, 2018, at 12:47 AM, Laczen JMS wrote:
>
> Hi Marko and Will,
>
> I have
Hi Marko and Will,
I have experienced the same problem while developing nvs for zephyr. I
always got stuck when I would except that there would be changes to
flash by an "external" factor. As soon as this could happen there is a
problem with the meaning of the crc. The crc fails this means:
a.
I guess you could also use some error correction/detection coding scheme as
well if you wanted to try and actually recover data that had errors in it (but
that seems a bit much). Another thing I have seen done is that just the header
has FEC on it. This way, you can almost always get the proper
Hi,
> On Jul 30, 2018, at 1:47 PM, Laczen JMS wrote:
>
> Hi Marko and Will,
>
> I have been studying fcb and I think you can leave it at 8 bit as it
> was. The crc can only be interpreted as a check that
> the closing was done properly. As soon as the crc check fails this
> only means that the
I realize I am a bit late with these comments but better late than never I
guess. Well, maybe some or all of these comments should never be made :-) This
could be a horrible idea but why not just make it backward incompatible? (for
#2). Maybe have a syscfg for folks that want to use the old
> On Jul 26, 2018, at 3:10 PM, marko kiiskila wrote:
>
> Hi,
>
> there’s few issues with FCB which I need to fix.
>
> 1) Compressing flash sector in the middle of write.
> Currently the cycle of operation is expected to be the following:
> fcb_append() -> get offset to write data to
>
