File-based and Direct Sector Access Coexistence
|Top Previous Next|
Direct Sector Access explains that working with flash sectors is done through two RAM buffers numbered #0 and #1. Flash disk operation depends on these buffers as well.
Buffer #0 is used for processing housekeeping data and stores no valuable content that must be preserved past the end of a single disk-related method execution. That is, once the method such as the fd.setdata has executed, buffer #0 has no valuable data in it.
Buffer #1 is used to load and store the contents of the most recently loaded (and possibly changed) data sector. So, if fd.setdata was recently called, this buffer may still hold new data, and this data may not be saved to the flash memory yet. Corrupting this unsaved data would have unpleasant consequences for the file. To prevent this, the fd. object automatically dismounts the disk (sets fd.ready= 0- NO) if your application does fd.setbuffer or fd.getsector while the fd.buffernum= 1 and while this buffer was loaded with new and as yet unsaved sector data.
Fd.setsector method will cause disk dismounting if the destination was within the disk area (sectors 0 through fd.totalsize-1). Writing outside the disk area will not interfere with the flash disk operation.
The fd.getbuffer method does not cause any interference with the flash disk, so it can be used freely.
The fd.checksum will write to the RAM buffer (when in the "PL_FD_CSUM_MODE_CALCULATE" mode), but the checksum calculation method is the same as the one used by the disk itself, so setting this checksum will never be wrong.
Note, finally, that any file-related method will affect the value of the fd.buffernum. Never assume that you know what this property is set to. Always set it explicitly and each time before performing direct sector access.