When designing an embedded system, non-volatile storage is almost always required. Different designs required different capacities of storage, ranging from small single-function devices, with little configuration, which could manage with only 8MB, to large storage systems (such as the Bluewater DDS XM-100, ), which may require multiple gigabytes.
Embedded Storage Options
- Allows for huge amounts of storage to be easily provided, and is very cheap per GB (< US$1 / GB)
- Physically fairly large, so may restrict the form factor of the final device. Some manufacturers do make very small hard disks, however cost & availability may limit their usage
- Has a moving spindle, meaning that it is not suitable for devices that are going to be exposed to vibration
- More restrictive in terms of environmental sensitivity, may not be suitable for harsh environmental situations (dust etc...)
- Requires an IDE (or similar) controller in the host processor
Flash memory (NOR)
- Fast, easily accessed in software
- Expensive per MB
Flash memory (NAND)
See NAND for more details.
- Comparatively cheap per MB (~US$10 / GB)
- Reasonable fast read/write speed
- Requires fairly intelligent flash management software to cope with bad blocks and wear leveling of the flash
- Compatible with a variety of other devices (assuming FAT filesystem is used)
- Easily purchased from almost any computer supplier
- Allows the choice of either Flash based USB dongles, or large external hard disks.
- Not suitable for internal storage for a unit, due to the physical size
- As with SD, it is easily compatible with a variety of devices, and easily purchased
Some units may not require their own storage, but may be able to access the storage of another device over some form of network (Ethernet, WIFI, GPRS, Bluetooth etc...)
- Keeps the unit design simple, as storage considerations are lessened
- Allows for easy upgrading of the storage without impacting the individual units
- Requires constant network connectivity
- See NAND for more details.
- This filesystem is only suitable for NAND flash, but does provide a comprehensive solution tailored towards the specific features of NAND (wear leveling & bad block management). This is Bluewater's recommended filesystem when using NAND flash.
- This is the standard Linux filesystem format, and is suitable for USB dongles, SD cards and Harddisks. It provides some level of robustness over filesystems like FAT, however it does require that devices be cleanly shut down.
- This is the most common filesystem found when using any kind of removable storage, such as SD, MMC & USB dongles. It is well supported, but suffers from a lack of robustness, and features. It is not suitable as the filesystem from which an embedded device boots from.
Network filesystem for development
When doing product development, it is often unsuitable to continually copy software from the development environment down to the embedded device. Instead of doing this, for development purposes it is generally preferred to have the embedded device automatically download all of it settings from the network, and then run using a network share as its root filesystem.
This has several advantages:
- The embedded device has access to all of the files on the network
- Changes in software can be instantly tested on the device with a reboot/download procedure
- Simplifies initial device bringup, as the device storage subsystem does not have to be completed before software testing can begin
Normally, in order to allow a unit to access an Ethernet network the embedded device must have Ethernet support itself, however using the RealView Development tools allows the emulation of an Ethernet device, using the inbuilt JTAG port available on every ARM-based CPU. This allows for all of the advantages of using network based development, without the expensive of putting an Ethernet controller onto the device. See RVI Virtual Ethernet for more details.
Bluewater has developed a variety of devices involving NAND flash storage, and it is generally our recommended form of internal storage. The Bluewater DDS XM-100 unit allows for up to 48GB of NAND flash, which can be expanded/reduced using a stackable flash design.
In general, for the simplest and surest design, we would recommend the following storage setup:
- A small NOR flash device, used solely to house the bootloader and its configuration information. This would typically be around 512kB in size.
- A large NAND device running the YAFFS filesystem for the bulk of the storage. This could be split into two areas to separate the application code from the user data, or these could be combined. Depending on the application this could range from 16MB to >4GB.
However, for unit cost reasons it is often desirable to remove the NOR flash device, and instead boot directly from the NAND chip. Various ARM CPUs support this, and although it requires a little more initial development, and care during the product design/development, it can be made to work quite easily.