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.

Const Keyword - Coding Myth 3

This post talks about the "C" keyword "const". It is very often thought that making a variable "const" ensures that it gets placed in the non-volatile memory (ROM or flash). But how true is this?

Well to start with w.r.t the ansi "C" compiler, the "const" keyword just tells the compiler that the user doesn't intend to modify the variable.
E.g.
           const unsigned int Gctrl_NoOfGears= 10;
so if i try to do this
           Gctrl_NoOfGears +=1;
I can either except a warning or an error. something like this
error: assignment of read-only variable `Gctrl_NoOfGears'
However, does this warrant me that the variable is now placed inside the memory in an non-volatile area.
Well, the answer is it is compiler (settings) dependent.
Why?
Most embedded compilers are very smart and automatically place the constants in the ROM/ flash area. However, some times the flash or ROM is used only as program memory and NOT as data memory. In which case there is no way (directly) that the compiler can place this in the program memory. Also In these processors the program memory is not directly accesible because the program & data are stored in differrent memory location & have different busses to access.  In such processors writing

const char DisplayStr[] = "Welcome";

will not cause DisplayStr to go into the ROM area.
You will have to do this via some compiler pragma's like

#pragma section start ROM
const char DisplayStr[] = "Welcome";
#pragma section end ROM

to make the compiler understand that it has to place the value in ROM & not in the RAM area.
Do I have to worry?
As a novice or some one programming for a simple system NO. However, when you are running low on resources and for various other reasons it makes sense to have a look at what the compilers is doing when you say "const". I repeat MOST compilers are clever enough to put the data into the ROM automatically.
The best practice is always to have a glance into the map file to ensure that you have everything at the right places.
Also, in one of the future posts i will be talking about another usages of const and how some constants are present even without your knowledge ( also little talk about const volatile...the common question in any interview on "C").

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

Previous coding myths here {1} ,{2}

Powered by ScribeFire.

Inlining code - Coding Myth 2

This post is regarding the inline keyword.
Very often we learn C & C++ together and end up mixing one language with the other. I learnt this the hard way when i found out in some debate that the "inline" keyword doesn't belong to the C language.....Boohooo!!..
Inline keyword natively belongs to C++.  It serves the purpose of just ensuring that the function is pasted inline instead of having a call to the function at every instance of the function call.
It was not a part of C. In "C" we achive similar functionality by using what are termed as "Function Like Macro's".
E.g.
#define Max(a,b)  ((a)>(b)?(a):(b))
The funciton like macros have a major disadvantage over Inline functions and that is the blindness to the compiler.
#define macro's are processed by what is known as the "C Preprocessor". The preprocessor looks for the macros and does a macro pasting operation. Which means that where ever in the above example Max is used the equivalent code is pasted.
E.g
y = Max(5,6); is equivalent to y = ((5)>(6)?(5):(6));
Then what is this blindness funda?
Well if iwrote this code
int *ptr;
y = Max(ptr,'5').
Then even this would work as for the Macro-Processor. Infact in this particular example even the compiler will not complain. However, if this was a inline function then the compiler would have been flag an error.  So it is easy to see that the inline key word has benifits over the #define macro.
Now some interesting stuff

• - Did you know that the inline keyword is just a request to the compiler. The compiler might choose to ignore you fully and would just make the function a normal function if it feels that by making it inline it is losing out on optimization.This is in contrast with #define function like macro's which are outside of the compiler's control.
  

• - Modern C compilers provide you various methods of inlining function by compiler extensions. E.g some compilers provide pragma's

#pragma InlineStart
void Inlinefunction(void)
#pragma InlineEnd
or things like
@inline void Inlinefunction(void)

• Inlining is very useful to ensure modularity & keep your code clean. However, In "C" if this was natively available then we embedded users would not have resorted to function like macro's.
• Evils of the keyword "inline".....Well it is difficult to debug your inline function because there is no call to the function and also it is not really visible to your debugger:-(.
  

Now that we have some idea of the keyword "Inline", you can try to check out the statements made above using our good old GCC compiler with "-S" option and have a look at the generated assembly code.
Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

When Size does matter - Coding Myth 1

Again i am slow in updating this blog and this time it is really because I was busy with some GUI building activity on Matlab. I will write more about in another post. However, today the topic is more about "C" coding myths.

Some dudes I have met write really write complicated code like the one below stating that it will be more efficient. Some how they seem to feel that compact code ( in terms of number of lines & characters used) translates directly into lesser code volume in the microcontroller. I just tried this....

Code:

unsigned char alt2(void)
{
    unsigned char var=10;
    unsigned char output;
    if(var==1)
        output=3;
    else if(var==2)
        output = 2;
    else
        output =1;
    return output;       
}
unsigned char Alt(void)
{
    unsigned char var= 10;
    unsigned char output;
    output = (var==1)?(3):((var==2)?(2):(1));
    return output;
}
void main(void)
{
    int x;
    x = alt();
    x = alt2();
}
Now on compiling this with avr-gcc with -S option you should be able to get the assembly code output also. Let us compare the functions Alt and Alt2 which have same functionalities.
alt2:
    push r29
    push r28
    rcall .
    in r28,__SP_L__
    in r29,__SP_H__
/* prologue: function */
/* frame size = 2 */
    ldi r24,lo8(10)
    std Y+2,r24
    ldd r24,Y+2
    cpi r24,lo8(1)
    brne .L2
    ldi r24,lo8(3)
    std Y+1,r24
    rjmp .L3
.L2:
    ldd r24,Y+2
    cpi r24,lo8(2)
    brne .L4
    ldi r24,lo8(2)
    std Y+1,r24
    rjmp .L3
.L4:
    ldi r24,lo8(1)
    std Y+1,r24
.L3:
    ldd r24,Y+1
/* epilogue start */
Alt2 takes a stack frame of 2 bytes and the code is readable to a great extent. I am sure it is more maintainable compared to Alt. However, Alt generates a stack frame of 4 bytes.
Alt:
    push r29
    push r28
    rcall .
    rcall .
    in r28,__SP_L__
    in r29,__SP_H__
/* prologue: function */
/* frame size = 4 */
    ldi r24,lo8(10)
    std Y+2,r24
    ldd r24,Y+2
    cpi r24,lo8(1)
    breq .L7
    ldd r24,Y+2
    cpi r24,lo8(2)
    brne .L8
    ldi r24,lo8(2)
    std Y+3,r24
    rjmp .L9
.L8:
    ldi r24,lo8(1)
    std Y+3,r24
.L9:
    ldd r24,Y+3
    std Y+4,r24
    rjmp .L10
.L7:
    ldi r24,lo8(3)
    std Y+4,r24
.L10:
    ldd r24,Y+4
    std Y+1,r24
    ldd r24,Y+1

We see that now the stack frame is 4 bytes & to  add to the woes the code is not so much readable as well.
Thus, we break a myth that complicated & compressed "C" files give compressed code. More often that not modern compilers are clever enough to do everything that is needed for optimisation. So please spare yourself the troubel and let the compiler do its job.
However, that doesn't mean that we should write inefficient code. What it means is that -  "Dont think you have optimized the code by just changing some "if" statements to "ternary"  operators. It is more than that and quite usually compiler dependent". The best way to optimize is to read the compiler manual and try to understand the compiler and its capability. Then you can use tricks in "C" to optimize the code.
 

Powered by ScribeFire.

C for embedded systems

This is for those who are completely new to programming micro controllers. using C language Here i try to give a head start to such people.

1. First choose a platform to work on. I suggest going for the AVR. AVR microcontrollers are relatively cheap and a fairly powerful. The best part however, is that you can test a multitude of the microcontrollers'' features using just the simulator provided in the IDE. You can download it from here free of cost after a small registration.
2. Now you have to download a compiler. Please note that IDE is different from compiler. I have seen this misconception very strong among freshers who have used Turbo C compiler for a long time. A compiler is more often than not a command line utility. IDE ( Integrated Development Environment) help us by managing the files and abstracting from us complex commandline arguments that are needed to compile your code. Download WINAVR.
3. Please install WINAVR first and then AVRStudio. This will ensure that AVRStudio automatically picks up the WINAVR path.
4. Use the GUI to guide you and create a simple project. There are many samples available. However, the wizard is very helpful. You can choose any microcontroller to start with. 
5. create a simple file with just the following code

int main(void)
{
     int i =0;
     int j = 5;
     i = i + j + 100;
     return 0;
}

 
[ compile the code (F7) after saving the file as anyname.c]

There you are done with your first C program for an embedded microcontroller. You will have to set the target as AVR simulator for debugging and stepping through your code.

I will not put more stuff here since that will take away the fun part from you.

What can you do?

• Try to write a program to add two number and store the output in a global variable.
• Other simple C programs without any printf or scanf statments.
  

Just one note, It is not really true to say the printf is a part of "C". Technically speaking pure "C" is the one in which there is no # include statement. When we say #include what we are doing is adding in libraries. Note that Libraries are not a part of "C", these are what users write. I dont know if i make full sense here :-S

In later posts i will try to explain the significance of #include in embedded code.

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