Sharing Flash Between Your Application and Data
|Top Previous Next|
Discussed in this section: fd.availableflashspace.
The flash memory used by the fd. object consists of 264-byte sectors. It is customary to use 256 bytes of each sector to store actual data, and reserve the rest for "service" data (checksum, etc.).
Depending on what device you are using, the fd. object may be storing its data in one of the two ways (locations):
There are two ways in which you can store the data using the fd. object:
Both the direct sector access and the file based access can be used at the same time — your flash disk can occupy only a portion of the data area, and the rest of the space can be used for direct sector access.
The fd. object refers to physical sectors of the data area in reverse (refer to the drawing below, which shows memory allocation on the shared flash IC). While the firmware and application are loaded into the flash memory starting from the physical sector 0, the allocation for the data area starts from the topmost physical sector. For convenience, related methods and properties of the .fd object refer to this topmost physical sector as the (logical) sector 0, the sector before the topmost sector — as 1, and so on.
This approach was chosen to minimize the influence of the changing size of your Tibbo BASIC/C application on the data you keep in the flash memory. Typically, the size of your application keeps changing as you develop and debug it. At the same time, you often need to keep certain data in the data area permanently, and don't want to recreate this data every time you upload a new iteration of your application. If the beginning of the data area was right after the end of the firmware/application area, any change in the application size would move the boundary of the data area, corrupt your data, and force you to recreate the data again. If, on the other hand, your data area starts from the top of the flash IC and continues downwards, then the chance of the data area corruption will be a lot smaller.
Naturally, the above applies to devices with shared flash memory. Devices with dedicated flash memory store firmware/application and fd. object's data in separate ICs, so there is no chance of corrupting the data area by loading a larger firmware/application.