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):

A tip note icon.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:

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.

A diagram illustrating the layout of shared flash memory.

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.

A tip note icon.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.