Once we accept that a NAND-based device can meet our goals for capacity, cost and ease of use, it is worth considering whether managed NAND is better than a discrete NAND device. Many embedded processors provide a dedicated NAND interface, and a discrete NAND device could be used on this bus. At first sight, this seems like a simple solution that would allow us to implement the PC-type architecture we have have described above. The major issue, which many designers have faced when adopting this approach, is that the NAND controller supporting this interface is designed to support a specific set of NAND technologies. NAND-flash memory is a developing technology for which the NAND manufacturers are in a race driven by the constant demand for higher capacities and lower costs. This means new geometries and technologies are introduced at a rapid pace which can leave the processor’s NAND controller stranded on the start line.
Surface-mount SSD on the memory bus (PIO mode)
In contrast, a managed NAND device like a surface-mount SSD has the controller and NAND integrated into a single package with a standard interface. This ensures that the embedded system designer can take advantage of the higher capacities and lower costs, but not be caught up in the complexities of implementing the new technologies at a systems level. Another alternative could be something like a low-capacity embedded MultiMediaCard (eMMC) NANDrive with boot capability. This is also a more cost-effective solution compared to the significantly more expensive high-density NOR, but it would require the processor to support an SD/eMMC interface, which many ARM-based processors do today.
Making a PC-style architecture work in an embedded system requires an embedded surface-mount SSD with the ability to connect to a variety of buses, because most embedded systems will not necessarily have a native IDE/ATA interface available. The key to making it feasible to use a surface-mount SSD on the memory bus is the simplicity of the parallel ATA (PATA) interface. The PATA interface closely resembles a traditional RAM-type memory bus with address, data and control signals. The interface uses three pins for the address of the ATA task-file registers and two chip-select (CS) pins for register set selection. Details of the register functions (command and address information, status and error reporting, etc.) are fully described in the ATA specification. There is a further minimum of 8 bits for the data bus (this can be set to 16 if required) and four additional control lines for Read and Write control, Interrupt Request and Reset. This means that the minimum implementation requires only 17 pins if an 8-bit data bus is used. (see figure 2).
Click image to enlarge.
Figure 2: The similarity of the PATA interface to a traditional RAM-type memory bus simplifies implementation.
Operating system considerations
Operating system driver considerations will depend on whether the host OS already has support for the IDE/ATA protocol on the memory bus. For an OS like Linux, it will be a case of modifying the IDE/ATA control register address and Interrupt mapping to treat the surface-mount SSD as a system peripheral.
For operating systems where the support is not intrinsic, a similar process needs to be created for the specific OS. The basic principles are outlined below:
Specific header files will need to be included that handle the modified global variables for the drivers (MCU_sys.h). Consider the NANDrive managed NAND flash memory device as an example. ATA register definitions would be included in the ata.h header as well as NANDrive specific definitions and variables, which would be included in NANDrive.h. Examples of MCU_sys.h, ata.h and NANDrive.h are available from Greenliant Systems.
Specific implementation of the NANDrive registers and data area would be handled by the NANDrive.c file, which should be modified depending on the type of MPU/MCU that is employed.
The example NANDrive generic driver provides the following functions to the system software:
inti_NANDrive(): Function is used to initialize task file register addresses and read NANDrive parameter information.
reset_NANDrive(): Function is used to let NANDrive perform software the reset operation
check_error(): Function returns the error code which is defined in NANDrive.h
check_status(): Function returns the status which is defined in NANDrive.h
read_n_sectors(): Function is used to read up to 64 sectors data out from NANDrive
write_n_sectors(): Function is used to write up to 64 sectors data into NANDrive
tmr_chk_timeout(): Function is used to check if function is returned in time
The sample NANDrive driver offers two ways to access data residing in the surface-mount SSD data sectors:
Data polling mode: After the host issues an ATA command, the MCU/MPU keeps polling the status register to decide when to start a data transfer.
Interrupt mode: MCU/MPU can return to some other operation after issuing an ATA command to the drive. An interrupt to the MCU/MPU will be triggered when the device is ready for data transfer. Using this mode can allow the MCU to save time with other operations.
The code snippet below shows an example of using the NANDrive.c driver:
Click image to enlarge.
The advent of managed NAND devices in a small form factor, BGA package allows embedded systems designers to adopt a PC-style architecture when designing new systems. The approach allows them to capitalize on surface-mount SSD advantages like easy integration and expanded functionality to develop prompt and cost effective designs. With no additional IDE control hardware required, a PATA-compliant managed NAND flash memory device can easily be connected to a microcontroller on the memory bus. Compared to expensive high-density NOR, surface-mount SSDs offer a compelling choice for code and data storage in embedded systems.
About the author
Ralph Thomson is director of field applications engineering at Greenliant Systems, manufacturer of NANDrive embedded solid state drives, NAND flash memory controllers and other high-reliability solid state storage products. He has more than 25 years of experience in applications engineering and product management working with all aspects of electronics, from OEM/ODM design to product definition and chipset support. He holds a BSc with Honors in physics with microelectronics from the University of Wales, Swansea.