Storage

Introduction

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

Hd-sizes

3.5" vs 2.5" vs 1.8" vs CompactFlash MicroDrive

Hard disk

  • 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
Nor

Typical NOR flash chip

Flash memory (NOR)

  • Fast, easily accessed in software
  • Expensive per MB


Nand

Typical NAND flash chip

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


Sd-flash
Typical SD card

SD

  • Removable
  • Compatible with a variety of other devices (assuming FAT filesystem is used)
  • Easily purchased from almost any computer supplier


Usb_flash
USB Flash

USB

  • 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


Network

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

Filesystem options

YAFFS2
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.
EXT2
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.
FAT
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 Experience

Pipi-flash
Stackable NAND flash from DDS XM-100

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.

 

rs1

rs_2

rs_3

rs_4