Computer Science

Share this article:

Computer Science

  • Join our comunity:

Thanks for the Memory

By: , Posted on: November 24, 2014

Embedded Software The Works new coverThe computer world is often accused of being mired in jargon and I think that is a fair criticism. In some ways it gets worse when an everyday word is “hijacked” to have a new meaning. A good example is “program”, which had several meanings before it was applied to software. Interestingly, in the UK we use the US spelling (“program”) to refer to software, but retain the English version (“programme”) for everything else.

Another re-purposed word is “memory”, which is interesting because it has acquired a number of meanings in a computing context. Historically, the term referred to the place that a program and data resided during execution – it still does have this meaning. But it was also used to refer to bulk storage like disk drives. Even today, when someone tells me how much memory their PC has, I have to make sure that they are not telling me about disk storage. For embedded systems, memory has always been a term with a number of meanings …

Memory is an important consideration in embedded systems. Most of the time, it is available in limited quantities and its configuration may be quite complex. An embedded developer is often very concerned about memory addresses and ensuring that code and data are located in the right places. Hence, a capable linker is an essential tool for embedded software development.

Traditionally, the code and constant data were placed in PROM (Programmable Read Only Memory). These devices would be programmed electrically and retain their data indefinitely. Most of them could be erased, ready for re-use, using an ultra-violet light source. Working data, that needed to be changed during program execution, was held in RAM (Random Access Memory). PROMs were cheap, sufficiently capacious and fast enough to allow code to be executed directly from them. RAM was faster, but more expensive, so was typically provided in small amounts.

Some systems would need other kinds of memory, in addition to PROM and RAM. A typical example would be non-volatile RAM (NVRAM) – memory that could be changed while the program was running, but retained data after the power was shut off. This presented some interesting programming challenges – maybe I will discuss that another day. NVRAM was commonly implemented using regular RAM provided with a backup power supply (“battery backed RAM”). Latterly, flash memory has become increasingly available as an option, but, though cheaper and simpler from a hardware perspective, it is less flexible from the software point of view.

Nowadays, a common system configuration is a combination of flash memory for program and constant data storage along with a large RAM area from where the code is executed. On start up, some “boot” code copies the instructions from flash to RAM and branches to it to initialize the application. Flash is a little slow, so executing code directly from it is undesirable. RAM is relatively cheap now and much faster.

This configuration works quite well, as flash may be fitted on board easily and programmed rapidly. During development, or even after deployment, new code versions can easily be loaded into flash. There are, however, two downsides: First, the code in RAM is potentially subject to corruption. Steps may be taken to prevent this, but they are a further complexity. PROMs were impossible to corrupt, which was reassuring. Second, the copying process from flash to RAM introduces link time complexity, which is quite readily overcome, and a start-up delay, which is more of an issue. This is increasingly the case as systems become more complex and the memory size grows.

In an ideal world, all the memory in an embedded system would be the same. It would be fast enough to be used for execution, re-writable on a byte by byte basis, as required, be write-protectable (in blocks) in a straightforward way and retain data through power cycles. There are technologies that hold out a promise of such a design – MRAM for example. But they do not seem to have reached mainstream yet.

How are your designs configured? Are you looking at MRAM etc.? Comments or email are very welcome.

Colin’s most recent publication, Embedded Software: The Works is available now on the Elsevier Store. Save 30% on his book and other Newnes Press and embedded systems books. Use discount code “STC3014″ at checkout. 

About the Author

Colin WallsColin Walls (@Colin_Walls) is an embedded software technologist at Mentor Graphics (@mentor_graphics), the leading EDA software company.

You can read more about Colin and his work on embedded systems at The Colin Walls Blog at Mentor Graphics here. Connect with Colin online here:

facebook google plus linkedin slideshare twitter wordpress

Connect with us on social media and stay up to date on new articles

3 thoughts on “Thanks for the Memory

Comments are closed.

Computer Science

Computing functionality is ubiquitous. Today this logic is built into almost any machine you can think of, from home electronics and appliances to motor vehicles, and it governs the infrastructures we depend on daily — telecommunication, public utilities, transportation. Maintaining it all and driving it forward are professionals and researchers in computer science, across disciplines including:

  • Computer Architecture and Computer Organization and Design
  • Data Management, Big Data, Data Warehousing, Data Mining, and Business Intelligence (BI)
  • Human Computer Interaction (HCI), User Experience (UX), User Interface (UI), Interaction Design and Usability
  • Artificial intelligence (AI)
Morgan Kaufmann companion resources can be found here You can also access companion materials and instructor’s resources for all our new books on the Elsevier Store. Search by author, title or ISBN, then look for the “Resources” tab on any book page. Looking for companion materials or instructor’s resources for these titles? Connect below: