Eeprom and Flash Emulated Eeprom

This post talks about some basics of EEPROM and FEE.
To start with the discussion it is necessary to know what EEPROM stands for. EEPROM stands for Electrically Erasable PROM. Where PROM means Programmable Read only memory. The very fact that we are highlighting the Electrically Erasable means that there are other methods to erase the PROM. I leave it to the reader to find out what these are and leave as a comment.
Why do we need it?
In any system there are some set of parameters that need to be remembered through power cycles and can/may change between power cycles. An example....Well Your monitor settings ( i.e. the brightness contrast etc that you do on your monitor) is remembered through power cycles even if you connect the monitor to another PC or whatever. One of the places to store this could be the EEPROM.
What does this mean?
To write to the EEPROM i should be able to erase it and then rewrite it. Also it should be capable of being written several times ( maybe a few lakh times). Also, it should have data retention capacity. i.e if i write it today and check after say some 10 years the data should be same in the absence of any power.
What is FEE then?
As you can see some of the properties of EEPROM are held by the flash memory also. Like i can write into the Flash memory electrically, it can retain information across power cycles, it can be written multiple times. However, the biggest different is that the flash technology ensures that it can be written only in huge chunks like 64 or 128 bytes. Also, the life of the Flash memory is much lesser than the EEPROM. On the other hand the best part is that it costs much less than the EEPROM.
So FEE which stands for Flash Emulated EEPROM is basically a method of emulating the behaviour of the EEPROM using the Flash memory. This means if a Flash memory has 10000 write cyles, i should make it some how work as if it is 100,000 write cycles ( like in case of EEPROM). Also, i should provide somehow the capability of writing a single word/ single byte as available in the EEPROM.
In short if i have FEE then the application should feel as if it is having EEPROM....
How to do this ? Well that is for another post....


Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

Simulate Emulate and Debug....

Here i try to talk about a widely misunderstood topic. It is about Emulators, Simulators and Debuggers.

For starters, these three are different things and have different ways of operation and capabilities but have a common intent. Helping the embedded developer, develop his software in a more robust way with lesser number of bugs.

Lets start with the most common one, Simulator. A simulator is a software that runs on the host pc ( Your personal computer), and is able to mimic some/all of the behavior of micro controller. I use the term µC because that is what we will be dealing more in the future posts. However, this is equally applicable to the µC too. Some/all is in bold because simulators often cannot mimic all the functionalities that can occur in the real hardware. Some of the very good simulators i have seen are the AVR simulators. This should be available to you if you download AVR studio which i discussed in my earlier post here.

Next is a Debugger. A debugger is a device ( Typically an external peice of hardware connected to your PC via a serial link like USB) which talks to your µC and provides information to the host PC which is displayed in some kind of a debugging environment. Often the external hardware debugger is accompanied with a PC envirnonment to debug it and people confuse this environment to be the debugger. Unfortunately, that is incorrect. E.g of Debuggers 

• Nec Mini Cube with IEQB850 as the debugging environment
• ATMEL -ICE with AVR studio as the debugging environment.

Technically speaking, if you are a great PC prorgammer, then it should be possible for you to create your own debugging environment which talks to the hardware debugger and displays relavent information on your screen.
It should be obvious that to really use a debugger u needed a µC to which you can talk to. Without having a µC ( often called Target), there is not much you can do with a debugger.


Finally we have the Emulator. This is where everyone gets confused. An Emulator emulates the functionality of the µC. This means that the real µC is not present in the system. This is in contrast with the Debugger which requires an external µC to really talk to. Since, the Emulator emulates the functionality of the µC, there is no need for an extra µC. The question now arises why do we need an Emulator at all if we have a debugger? Why take pains to emulate the functionality of the micro when we already have it available?

Answer

• Often the real micro controller will be in developmental stages, while companies still want to use them. So Micro vendors like NEC come up with Emulators.
• Emulators can have more debugging capabilities compared to the real µC.
• Since, the Emulator is emulating the µC, it can be reconfigured via different means ( we will discuss this else where) to emulate more than one type of µC ( of course, not at the same time!!).

Eg: Nec IE-CUBE is a emulator for NEC V850 micro controllers

Costwise, typically simulators are cheap, Debuggers are costly and Emulators are very costly. Also, for debuggers to exist the µC should provide some kind of debug interface ( remember the debugger needs to talk to the micro!!). We will talk about debug interfaces in one of the future posts.

I hope this post helps people to lose some myths about the three components.

Wanna add your point or provide additional info ? Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.