Sharing Flash Between Your Application and Data
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):
- On devices with shared flash memory, the firmware, compiled Tibbo BASIC/C application, and the fd. object's data are stored on the same flash IC chip. All flash sectors that are not occupied by the firmware/application are available for storing your data. We will refer to this area as the data area of the flash IC. The size of the data area, in sectors, can be obtained through the fd.availableflashspace read-only property.
- On devices with dedicated flash memory, one flash IC is used for firmware and application storage, while a second flash IC is used for the fd. object's data storage. On such devices, the data area occupies the entire second flash IC and fd.availableflashspace always returns the number of sectors in this second flash IC. On certain devices, the second flash IC is not present onboard and must be connected externally.
To find out what flash memory arrangement your device has, refer to your device's platform specification (for example, EM1000's is here). You will find memory arrangement data under "Miscellaneous Information/Flash Memory Configuration."
There are two ways in which you can store data using the fd. object:
- The first way is to read and write flash sectors of the data area directly — a so-called direct sector access. This method is simple and allows you to "do whatever you please" with the data area you have.
- The second way is file-based — you create a full-blown flash disk that maintains a simple file system. This introduces a certain overhead, since the file system needs a number of sectors for its own internal "housekeeping." At the same time, using files may be infinitely more convenient and flexible, as many complex operations happen automatically, thus simplifying your application. In addition, disk transactions bulletproof your file operations.
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 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 (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 the firmware/application and the fd. object's data in separate ICs, so there is no chance of corrupting the data area by loading a larger firmware/application.
When debugging your application on devices with the shared flash memory, use only a portion of the data area and leave some part of this area unoccupied. This will create a gap of unused sectors between the data and the firmware/application areas of the flash. This way, your application will (mostly) be able to grow without corrupting the data area.