Embedded RealTime Systems Design Selecting memory Memory for

Embedded Real-Time Systems Design Selecting memory

Memory for embedded systems • Embedded systems have different memory requirements – System frequently don’t have hard disk • No ability to swap – They run unattended – May required unattended boot – Won’t do normal system logging – Power down reliability

Memory options Type Positive Negative ROM High Density Low cost Can’t write to High Density Low Cost Difficult to write to Easier to erase than EPROM High cost Low density Highest Speed Low density Volatile High Speed Low cost Volatile High Density High Speed Wears out! Read Only Memory EPROM Electrically Programmable ROM EEPROM Electrically Erasable PROM SRAM Static Random Access Memory DRAM Dynamic Random Access Memory FLASH

Why Flash? EPROM E 2 PROM Updateable Nonvolatile FLASH DRAM High Density ROM

Why Flash Memory? • Flash has characteristics of both ROM and RAM – It is non-volatile – Can be written to – Has high read access speeds – It is reliable

What is Flash memory? • Flash covers a wide range of different memory technologies and Architectures – DOC (Disc On Chip) system – also known as NAND flash – CFI (Common Flash Interface) – also known as NOR flash – JEDEC – an older standard, still used but becoming obsolete by CFI – Non-DOC Nand – Old non-CFI Flash

Flash memory • Flash memory, both nand nor, work differently from other memory devices • In many ways they operate as block devices such as disk drives. • The devices are started as a whole series of 1 (empty) • Writing just means resetting the 1 s to 0 s where necessary

Flash memory • Writing and erasure must be done in blocks – Blocks can vary in size – Nor flash can set individual bits in a block – Nand can have pages in a block to change • Whole blocks have to be erased before they can be written to • Blocks can be locked and unlocked

Common Flash Interface • CFI or the Common Flash Interface was developed by Intel and AMD • The parameters for the flash are stored on chip in a common protocol • Software can query the devices • A number of levels of compliance

Flash Memory Maps • As flash is block orientated it can be laid out in differing ways – Boot flash • With small (normally 8 k byte) boot blocks at either top or bottom • Then 64 k erase blocks – Flash memory • Arranged in erase blocks of 64 or 128 k

Flash limitations • Writing of data can only be done in blocks 9 or pages on Nand flash) • Erasing and re-writing is slow • For DOC Nand pages can only be written a limited number of times (10) before block must be erased and re-written • There is a overall limitation on the number of writes – around 100, 000 times

Flash file systems • Flash devices have to have separate file systems and devices • On Linux this is the MTD (Memory Technology Device) interface • The file systems need special characteristics • Some devices require a translation layer for a file system to run – FTL (Flash Translation Layer) or NFTL (Nand FTL)

JFFS & JFFS 2 • The Journaling Flash File System is a popular choice for flash – It maintains a log structure of the file system in Flash – Loads the file system in to ram a boot time – Does wear levelling – avoids problems of over -writing – Can’t do XIP (e. Xecute In Place) because of compression/decompression – Not for real-time – garbage collection

CRAMFS • CRAMFS (Compressed RAM File System) • Developed by Linux Torvalds • Compressed version of file system in flash run in ram • Can’t be written to – only remade off-line • Use tmpfs for volatile data