Embedded C - Lecture 3

Prepared by: Mohamed AbdAllah
Embedded C-Programming
Lecture 3
1

Agenda
 Memory types (RAM, ROM, EEPROM, etc).
 Program memory segments.
 Static vs. Dynamic memory allocation.
 Static vs. Dynamic linking.
 Function call with respect to stack, i/p, o/p and i/o parameters and return
value.
 Functions types (Synch. vs. ASynch, Reentrant vs. non-Reentrant, Recursive,
Inline function vs. function-like macro).
 Task 3.
2

 ROM
Read-Only Memory (ROM), a very cheap memory that we can program it
once, and then we can never change the data that is on it. This makes it
useless because we can't upgrade the information on the ROM chip (be it
program code or data), we can't fix it if there is an error, etc....
Because of this, they are usually called "Programmable Read-Only
Memory" (PROM), because we can program it once, but then we can't
change it at all.
5
Memory types

 EPROM
In contrast to PROM is EPROM ("Erasable Programmable Read-Only
Memory"). EPROM chips will have a little window, made of either glass or
quartz that can be used to erase the memory on the chip.
To erase an EPROM, the window needs to be uncovered (they usually have
some sort of guard or cover), and the EPROM needs to be exposed to UV
radiation to erase the memory, and allow it to be reprogrammed.
6
Memory types

 EEPROM
A step up from EPROM is EEPROM ("Electrically Erasable Programmable
Read-Only Memory"). EEPROM can be erased by exposing it to an
electrical charge. This means that EEPROM can be erased in circuit (as
opposed to EPROM, which needs to be removed from the circuit, and
exposed to UV). We can erase one byte at a time or an appropriate
electrical charge will erase the entire chip, so we can't erase just certain
data items at a time.
Many modern microcontroller have an EEPROM section on-board, which
can be used to permanently store system parameters or calibration values.
These are often referred to as non-volatile memory (NVM). They can be
accessed - read and write - as single bytes or blocks of bytes. EEPROM
allows only a limited number of write cycles, usually several ten-thousand.
Write access to on-board NVM tends to be considerably slower than RAM.
Embedded software must take this into account and "queue" write
requests to be executed in background.
7
Memory types

 RAM
Random Access Memory (RAM) is a temporary, volatile memory that
requires a persistent electric current to maintain information. As such, a
RAM chip will not store data when we turn the power OFF.
RAM is more expensive than ROM, and it is often that Embedded systems
can have many Kbytes of ROM (sometimes Megabytes or more), but often
they have less than 100 bytes of RAM available for use in program flow.
8
Memory types

 Flash memory
Flash memory is a combination of the best parts of RAM and ROM. Like
ROM, Flash memory can hold data when the power is turned off. Like
RAM, Flash can be reprogrammed electrically, in whole or in part, at any
time during program execution.
Flash memory modules are only good for a limited number of Read/Write
cycles, which means that they can burn out if we use them too much, too
often. As such, Flash memory is better used to store persistent data, and
RAM should be used to store volatile data items.
Flash memory works much faster than traditional EEPROMs because it
writes data in chunks, usually 512 bytes in size, instead of 1 byte at a time
like EEPROM can do, but it may be a disadvantage as we have to erase a
whole sector in the Flash even we need to erase only 1 byte.
9
Memory types

In object files there are areas called sections. Sections can hold executable
code, data, dynamic linking information, debugging data, symbol tables,
relocation information, comments, string tables, and notes.
There are several sections that are common to all executable formats (may be
named differently, depending on the compiler/linker) as listed below:
 .text
 .bss
 .data
 .rdata
11
Program Memory segments

 .text
This section contains the executable instruction codes and is shared
among every process running the same binary. This section usually has
READ and EXECUTE permissions only. This section is the one most affected
by optimization.
 .bss
BSS stands for ‘Block Started by Symbol’. It holds un-initialized global and
static variables. Since the BSS only holds variables that don't have any
values yet, it doesn't actually need to store the image of these variables.
The size that BSS will require at runtime is recorded in the object file, but
the BSS (unlike the data section) doesn't take up any actual space in the
object file.
12

 .data
Contains the initialized global and static variables and their values. It is
usually the largest part of the executable. It usually has READ/WRITE
permissions.
 .rdata
Also known as .rodata (read-only data) section. This contains constants
and string literals.
13

 Stack vs. Heap
There are also 2 more memory segments when program is loaded into
memory (Stack and Heap).
 Stack:
The stack area contains the program stack (functions working area), a
LIFO (Last In First Out) structure, typically located in the higher parts
of memory. On the standard PC x86 computer architecture it grows
toward address zero, on some other architectures it grows the
opposite direction.
A “stack pointer” register tracks the top of the stack, it is adjusted
each time a value is “pushed” onto the stack.
It is where automatic variables are stored, along with information that
is saved each time a function is called.
14

 Heap:
It is the segment where dynamic memory
allocation takes place.
The heap area begins at the end of the BSS
segment and grows to larger addresses from there.
The Heap area is managed by malloc, realloc, and
free.
The stack area traditionally adjoined the heap area
and grew the opposite direction.
Heaps are more difficult to implement. Typically,
we need some code that manages the heap. We
request memory from the heap, and the heap
code must have data structures to keep track of
which memory has been allocated.
15

 Static Memory Allocation
Memory is allocated for the declared variable by the compiler. The
address can be obtained by using ‘address of’ & operator and can be
assigned to a pointer. The memory is allocated during compile time.
Since most of the declared variables have static memory, this kind of
assigning the address of a variable to a pointer is known as static memory
allocation.
We have no control over the lifetime of this memory. E.g: a variable in a
function, is only there until the function finishes.
17
Memory allocation

 Dynamic Memory Allocation
Allocation of memory at the time of execution (run time) is known as
dynamic memory allocation. The functions calloc() and malloc() support
allocating of dynamic memory.
Dynamic allocation of memory space is done by using these functions
when value is returned by functions and assigned to pointer variables.
We control the exact size and the lifetime of these memory locations. If we
don't free it, we'll run into memory leaks, which may cause our application
to crash, since it, at some point cannot allocation more memory.
Example:
/* Allocate block of 100 integers */
int *ptr1 = (int*) malloc(100*sizeof(int));
/* Allocate block of 100 integers zero initialized */
int *ptr2 = (int*) calloc(100, sizeof(int));
/* Free allocated memory */
free(ptr1); free(ptr2);
18
Memory allocation

 Dynamic Memory Allocation Problems
There are a number of problems with dynamic memory allocation in a
real time system:
• The standard library functions (malloc() and free()) are not normally
reentrant, which would be problematic in a multithreaded application.
• A more intractable problem is associated with the performance of
malloc(). Its behavior is unpredictable, as the time it takes to allocate
memory is extremely variable. Such nondeterministic behavior is
intolerable in real time systems.
• Without great care, it is easy to introduce memory leaks into
application code implemented using malloc() and free(). This is caused
by memory being allocated and never being deallocated. Such errors
tend to cause a gradual performance degradation and eventual failure.
This type of bug can be very hard to locate.
• Memory fragmentation problems arise because of dynamic memory
allocation.
19
Memory allocation

Memory segmentation problem example:
For this example, it is assumed hat there is a 10K heap. First, an area of 3K
is requested, thus:
#define K (1024)
char *p1;
p1 = malloc(3*K);
To check if allocation succeeded
if (p1 != NULL)
{
printf(“Succeeded”);
}
Then, a further 4K is requested:
p2 = malloc(4*K);
3K of memory is now free. 20
Memory allocation
3K
4K
3K - Empty
p1
p2

Some time later, the first memory allocation, pointed to by p1, is de-
allocated:
free(p1);
This leaves 6K of memory free in two 3K chunks. A further request for a 4K
allocation is issued:
p1 = malloc(4*K);
This results in a failure – NULL is returned into p1 – because, even though
6K of memory is available, there is not a 4K contiguous block available.
This is memory fragmentation.
21
Memory allocation
3K - Empty
4K
3K - Empty
p2

malloc(0) is implementation defined, it can return NULL or it can return a
valid pointer to be used in free() but shouldn’t be dereferenced.
malloc(-10) or any negative number returns NULL pointer as malloc()
accepts unsigned values, so the negative number is converted to a very big
positive number.
22
Memory allocation

 Linking
The linker actually enables separate compilation. An executable can be
made up of a number of source files which can be compiled and
assembled into their object files respectively, independently.
In a typical system, a number of programs will be running. Each program
relies on a number of functions, some of which will be standard C library
functions, like printf(), malloc(), strcpy(), etc. and some are non-standard
or user defined functions.
If every program uses the standard C library, it means that each program
would normally have a unique copy of this particular library present within
it. Unfortunately, this result in wasted resources, degrade the efficiency
and performance.
24
Program linking

 Linking
Since the C library is common, it is better to have each program reference
the common, one instance of that library (shared library), instead of
having each program contain a copy of the library.
This is implemented during the linking process where some of the objects
are linked during the link time (static linking) whereas some done during
the run time (deferred/dynamic linking).
25
Program linking

 Static Linking
The term ‘statically linked’ means that the program and the particular
library that it’s linked against are combined together by the linker at link
time.
This means that the binding between the program and the particular
library is fixed and known at link time before the program run. It also
means that we can't change this binding, unless we re-link the program
with a new version of the library.
Programs that are linked statically are linked against archives of objects
(libraries) that typically have the extension of .a. An example of such a
collection of objects is the standard C library, libc.a.
You might consider linking a program statically for example, in cases where
you weren't sure whether the correct version of a library will be available
at runtime, or if you were testing a new version of a library that you don't
yet want to install as shared.
26
Program linking

 Static Linking
To generate a static library using gcc and be used later for linking:
1-Generate object code for required source file
27
Program linking
D:newProject>gcc -c file.c -o file.o
D:newProject>ar rcs file.lib file.o
D:newProject>gcc main.c file.lib -o app.exe
2-Archive the object code inside a library
3-Statically link the library to our main.c file
The drawback of this technique is that the executable is quite big in size,
all the needed information need to be brought together.

 Dynamic Linking
The term ‘dynamically linked’ means that the program and the particular
library it references are not combined together by the linker at link time.
Instead, the linker places information into the executable that tells the
loader which shared object module the code is in and which runtime linker
should be used to find and bind the references.
This means that the binding between the program and the shared object is
done at runtime that is before the program starts, the appropriate shared
objects are found and bound.
This type of program is called a partially bound executable, because it isn't
fully resolved. The linker, at link time, didn't cause all the referenced
symbols in the program to be associated with specific code from the
library. 28
Program linking

 Dynamic Linking
Instead, the linker simply said something like: “This program calls some
functions within a particular shared object, so I'll just make a note of
which shared object these functions are in, and continue on”.
Symbols for the shared objects are only verified for their validity to ensure
that they do exist somewhere and are not yet combined into the program.
The linker stores in the executable program, the locations of the external
libraries where it found the missing symbols. Effectively, this defers the
binding until runtime.
Programs that are linked dynamically are linked against shared objects that
have the extension .so. An example of such an object is the shared object
version of the standard C library, libc.so.
29
Program linking

 Dynamic Linking
The advantageous to defer some of the objects/modules during the static
linking step until they are finally needed (during the run time) includes:
• Program files (on disk) become much smaller because they need not
hold all necessary text and data segments information. It is very useful
for portability.
• Standard libraries may be upgraded or patched without every one
program need to be re-linked. This clearly requires some agreed
module-naming convention that enables the dynamic linker to find the
newest, installed module such as some version specification.
Furthermore the distribution of the libraries is in binary form (no
source), including dynamically linked libraries (DLLs) and when you
change your program you only have to recompile the file that was
changed.
30
Program linking

 Dynamic Linking
• Software vendors need only provide the related libraries module
required. Additional runtime linking functions allow such programs to
programmatically-link the required modules only.
• In combination with virtual memory, dynamic linking permits two or
more processes to share read-only executable modules such as
standard C libraries. Using this technique, only one copy of a module
needs be resident in memory at any time, and multiple processes, each
can executes this shared code (read only). This results in a
considerable memory saving, although demands an efficient swapping
policy.
31
Program linking

 Dynamic Linking
To generate a shared library using gcc and be used later for linking:
1-Generate the shared library directly for the required source file
32
Program linking
D:newProject>gcc -shared file.c -o file.dll
D:newProject>gcc main.c -L. -lfile -o app.exe
D:newProject>gcc main.c file.dll -o app.exe
2-Dynamically link the library to our main.c file
OR we can simply type
Now the code inside file.dll will not exist inside the output executable
but file.dll should exist when running app.exe.

 Function call with respect to stack
Assembly languages provide the ability to support functions. Functions are
perhaps the most fundamental language feature for abstraction and code
reuse. It allows us to refer to some piece of code by a name. All we need
to know is how many arguments are needed, what type of arguments, and
what the function returns, and what the function computes to use the
function.
In particular, it's not necessary to know how the function does what it
does to be able to manage function calls with respect to stack.
34
Function call

To think about what's required, let's think about what happens in a
function call.
• When a function call is executed, the arguments need to be evaluated
to values (at least, for C-like programming languages).
• Then, control flow jumps to the body of the function, and code begins
executing there.
• Once a return statement has been encountered, we're done with the
function, and return back to the function call.
Programming languages make functions easy to maintain and write by
giving each function its own section of memory to operate in.
35
Function call

For example, suppose we have the following function:
int pickMin( int x, int y, int z )
{
int min = x;
if (y < min)
min = y;
if (z < min)
min = z;
return min;
}
We declare parameters x, y, and z. We also declare local variables, min.
We know that these variables won't interfere with other variables in other
functions, even if those functions use the same variable names.
36
Function call

In fact, we also know that these variables won't interfere with separate
invocations of itself. For example, consider this recursive function:
int factorial(unsigned int i)
{
if(i <= 1)
{
return 1;
}
return i * factorial(i - 1);
}
Each call to fact produces a new memory location for i. Thus, each
separate call (or invocation) to fact has its own copy of i.
How does this get implemented? In order to understand function calls, we
need to understand the stack, and we need to understand how assembly
languages (MIPS as our example) deal with the stack. 37
Function call

When a program starts executing, a certain contiguous section of memory
is set aside for the program called the stack.
38
Function call

The stack pointer is usually a register that contains the top of the stack.
The stack pointer contains the smallest address x such that any address
smaller than x is considered garbage, and any address greater than or
equal to x is considered valid.
In the example above, the stack pointer contains the value 0x0000 1000,
which was somewhat arbitrarily chosen.
The shaded region of the diagram represents valid parts of the stack.
It's useful to think of the following aspects of a stack:
• Stack bottom: The largest valid address of a stack. When a stack is
initialized, the stack pointer points to the stack bottom.
• Stack limit: The smallest valid address of a stack. If the stack pointer
gets smaller than this, then there's a stack overflow (this should not be
confused with overflow from math operations). 39
Function call

Like the data structure by the same name, there are two operations on the
stack: push and pop.
Usually, push and pop are defined as follows:
• Push: We can push one or more registers, by setting the stack pointer
to a smaller value (usually by subtracting 4 times the number of
registers to be pushed on the stack) and copying the registers to the
stack.
• Pop: We can pop one or more registers, by copying the data from the
stack to the registers, then to add a value to the stack pointer (usually
adding 4 times the number of registers to be popped on the stack)
Thus, pushing is a way of saving the contents of the register to memory,
and popping is a way of restoring the contents of the register from
memory.
40
Function call

Some ISAs have an explicit push and pop instruction. However, MIPS (as
our example) does not. However, we can get the same behavior as push
and pop by manipulating the stack pointer directly.
The stack pointer, by convention (not mandatory but recommended), is
$r29. That is, it's register 29.
Here's how to implement the equivalent of push $r2 in MIPS, which is to
push register $r2 onto the stack.
push: addi $sp, $sp, -4 # Decrement stack pointer by 4
sw $r3, 0($sp) # Save $r3 to stack
The label "push" is unnecessary. It's there just to make it easier to tell it's
a push. The code would work just fine without this label.
41
Function call

Here's a diagram of a push operation:
42
Function call
The diagram on the left shows the stack before the push operation.
The diagram in the center shows the stack pointer being decremented by 4.
The diagram on the right shows the stack after the 4 bytes from register 3 has
been copied to address 0x000f fffc

Popping off the stack is the opposite of pushing on the stack. First, we
copy the data from the stack to the register, then we adjust the stack
pointer:
pop: lw $r3, 0($sp) # Copy from stack to $r3
addi $sp, $sp, 4 # Increment stack pointer by 4
43
Function call
As we can see, the data still is on the stack, but once the pop operation is
completed, we consider that part of the data invalid. Thus, the next push
operation overwrites this data.

That’s why when we return a pointer to a local variable or to a parameter
that was passed by value and the value stayed valid initially, but later on
got corrupted.
The data still stays on the garbage part of the stack until the next push
operation overwrites it (that's when the data gets corrupted).
44
Function call

Stack and Functions: Let's now see how the stack is used to implement
functions. For each function call, there's a section of the stack reserved for
the function. This is usually called a stack frame.
Let's imagine we're starting in main() in a C program. The stack looks
something like this:
45
Function call

We'll call this the stack frame for main. A stack frame exists whenever a
function has started, but yet to complete.
Suppose, inside of body of main() there's a call to foo(). Suppose foo()
takes two arguments. One way to pass the arguments to foo() is through
the stack. Thus, there needs to be assembly language code in main() to
"push" arguments for foo() onto the stack. The result looks like:
46
Function call

As you can see, by placing the arguments on the stack, the stack frame for
main() has increased in size. We also reserved some space for the return
value. The return value is computed by foo(), so it will be filled out once
foo() is done.
Once we get into code for foo(), the function foo() may need local
variables, so foo() needs to push some space on the stack, which looks
like:
47
Function call

foo() can access the arguments passed to it from main() because the code
in main() places the arguments just as foo() expects it.
We've added a new pointer called FP which stands for frame pointer. The
frame pointer points to the location where the stack pointer was, just
before foo() moved the stack pointer for foo()'s own local variables.
Having a frame pointer is convenient when a function is likely to move the
stack pointer several times throughout the course of running the function.
The idea is to keep the frame pointer fixed for the duration of foo()'s stack
frame. The stack pointer, in the meanwhile, can change values.
Thus, we can use the frame pointer to compute the locations in memory
for both arguments as well as local variables. Since it doesn't move, the
computations for those locations should be some fixed offset from the
frame pointer. 48
Function call

And, once it's time to exit foo(), you just have to set the stack pointer to
where the frame pointer is, which effectively pops off foo()'s stack frame.
It's quite handy to have a frame pointer.
We can imagine the stack growing if foo() calls another function, say, bar().
foo() would push arguments on the stack just as main() pushed arguments
on the stack for foo().
So when we exit foo() the stack looks just as it did before we pushed on
foo()'s stack frame, except this time the return value has been filled in.
49
Function call

50
Function call
Once main() has the return value, it can pop that and the arguments to
foo() off the stack:

 Function call with respect to parameters
Input parameter: parameter passed to function to provide an information
for the function, it can be passed by value or by address:
 Pass by value: variable value is passed, gets a new name local to the
function so if this new named variable is changed the original variable
that was passed will not be affected.
void muFunc(int x)
{
x++;
}
Inside any other function we typed:
int x = 10;
myFunc(x);
printf(“%d”, x); /* Still prints 10 */
51
Function call

 Pass by address: variable address is passed and saved inside a pointer,
so if we dereference the pointer and change the variable it points at
then the original variable that was passed will be changed.
void muFunc(int* ptr)
{
*ptr += 1;
}
int x = 10;
myFunc(&x);
printf(“%d”, x); /* Prints 11 */
Passing by reference is very useful when passing a structure for example
so that instead of passing the whole structure we can just pass a pointer to
it, so memory is saved.
52
Function call

Output parameter: parameter passed to function to be filled by function
with the required information so it should be a pass by address.
void readTemperature(int *temp_ptr)
{
*temp_ptr = readADCValue();
}
int temp;
myFunc(&temp);
After returning from myFunc(), temp will contain the updated temperature
value.
Output parameter is very useful when it is required to return multiple
variables not only one.
53
Function call

I/O parameter: parameter passed to function to provide an information
then filled by function with the a new information so it should be also a
pass by address.
void myFunc(int *ptr)
{
*ptr = doSomeProcessing(*ptr);
}
54
Function call

Return value: Function can return only one value, or a void data type in
case of no return value.
int square(int x)
{
return x*x;
}
int sq = square(10); /* sq value will be 100 */
55
Function call

 Synchronous vs. Asynchronous function
Synchronous function: function returns after all the required processing is
finished, it may do some sort of busy wait for a specific operation like I/O.
void getDeviceDataSynch(char *data)
{
/* Will not return until reading is finished */
data = readInputDevice();
}
Asynchronous function: function returns immediately after submitting
operation request and the operation makes some sort of callback to your
code or ISR when it completes to give its completion status.
void getDeviceDataAsynch (void)
{
/* Will return immediately without any data */
submitReadRequest();
}
57
Functions types

 Reentrant vs. Non-Reentrant function
Reentrant function: A function is reentrant if it can be invoked while
already in the process of executing. That is, a function is reentrant if it can
be interrupted in the middle of execution (for example, by a signal or
interrupt) and invoked again before the interrupted execution completes.
A Reentrant Function shall satisfy the following conditions:
• Should not call another non-reentrant function.
• Should not contain static time variables.
• Should not use any global variables.
• Should not use any shared resources.
Non-Reentrant function: Function is non-reentrant if it breaks one or
more condition of reentrancy conditions.
58
Functions types

 Recursive function
Recursive function: Recursion is the process of repeating items in a self-
similar way. In programming languages, if a program allows you to call a
function inside the same function, then it is called a recursive call of the
function.
Example: the factorial function:
int factorial(unsigned int i)
{
if(i <= 1)
{
return 1;
}
return i * factorial(i - 1);
}
Recursive function is not safe as It may lead to stack overflow for example
in case of missing break condition. 59
Functions types

 Inline function vs. Function-like macro
Inline function: By declaring a function inline, you can direct the compiler
to make calls to that function faster. One way it can achieve this is to
integrate that function's code into the code for its callers (copy function’s
code in call location without actual call). This makes execution faster by
eliminating the function-call overhead.
inline int myFunc(unsigned int i)
{
/* Any code */
}
Note that inline is just a request for the compiler, it may be done or not,
but function-like macro will always be replaced with corresponding code
lines.
Inline function is the same as any normal function with respect to type
checking and so on, so it doesn’t contain the problems of function-like
macro. 60
Functions types

Mohamed AbdAllah
Embedded Systems Engineer
mohabdallah8@gmail.com
62

Embedded C - Lecture 3

Recommended

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to Embedded C - Lecture 3 (20)

Recently uploaded (20)

Embedded C - Lecture 3