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 format in the code? I would even consider making all entries have a two-byte CRC (regardless of length of data written). I presume the resume that it was one-byte was to save flash space? Heck, maybe even allow the syscfg to specify a 32-bit CRC (for those with lots of flash and/or really do not want a false positive to occur).
Will > On Jul 26, 2018, at 5:10 AM, marko kiiskila <ma...@runtime.io> 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 > flash_area_write() -> write data > fcb_append_finish() -> writes CRC etc > > This is not too great if the location returned by fcb_append() gets rotated > to be > scratch area before fcb_append_finish() is called. Which is quite possible > if you’re using FCB to store logs, and data comes from different tasks. > > 2) CRC is 1 byte only. It’s ok for short config entries, but for longer things > (log entries) is not good enough. > > To fix 1 I was going to add linkage to fcb_entry such that FCB can track > of incomplete writes, and add a write routine which should be used when > doing the write. > > Issue 2 is a little bit more cumbersome. I want to be able to at least > allow backwards compatibility, where code figures out from data in > the flash which CRC format is there. But then be able to switch to > 16 bit CRC format as new flash areas are written. Or keep using > the old format, because you want to do downgrade to old SW version > if necessary. > > So that’s what I’m currently thinking of trying to achieve. Let me know > if you guys have other things to take into consideration here.
