embedded c - lecture 4

Prepared by: Mohamed AbdAllah

Embedded C-Programming

Lecture 4

1

Agenda

Memory alignment.

Bitwise operations.

HW and I/O concepts (Memory mapped registers, polling, interrupts, DMA),

Bootloader, Startup file.

Inline Assembly.

Software layered architecture.

MISRA rules.

Task 4.

2

Agenda

3

Memory alignment

4

What is alignment

The way our C compiler lays out basic C data types in memory is constrained in order to make memory accesses faster.

Storage for the basic C data types on an x86 or ARM processor doesn’t normally start at arbitrary byte addresses in memory. Rather, each type except char has an alignment requirement; chars can start on any byte address, but 2-byte shorts must start on an even address, 4-byte ints or floats must start on an address divisible by 4, and 8-byte longs or doubles must start on an address divisible by 8. Signed or unsigned makes no difference.

The jargon for this is that basic C types on x86 and ARM are self-aligned. Pointers, whether 32-bit (4-byte) or 64-bit (8-byte) are self-aligned too.

5

Memory alignment

What is alignment

Self-alignment makes access faster because it facilitates generating single-instruction fetches and puts of the typed data.

Without alignment constraints, on the other hand, the code might end up having to do two or more accesses spanning machine-word boundaries.

Characters are a special case; they’re equally expensive from anywhere they live inside a single machine word. That’s why they don’t have a preferred alignment.

6

Memory alignment

Structure alignment and padding

1. Alignment

Consider this structure:

struct foo1 {

char *p;

char c;

long x;

};

Assuming a 32-bit machine, the memory layout of one of these looks like this:

struct foo1 {

char *p; /* 4 bytes */

char c; /* 1 byte

char pad[3]; /* 3 bytes */

long x; /* 4 bytes */

}; 7

Memory alignment


1. Alignment

In general, a structure instance will have the alignment of its widest scalar member. Compilers do this as the easiest way to ensure that all the members are self-aligned for fast access.

Consider previous structure but char c is put first then it will look like:

struct foo2 {

char c; /* 1 byte */

char pad[3]; /* 3 bytes */


long x; /* 4 bytes */

};

If the members were separate variables, c could start at any byte boundary and the size of pad might vary. Because struct foo2 has the pointer alignment of its widest member, that’s no longer possible. Now c has to be pointer-aligned, and following padding of 3 bytes is locked in.

8

Memory alignment


2. Padding

Consider this example on a 32-bit machine:

struct foo3 {



};

struct foo3 quad[4]; /* Array of structures */

sizeof(struct foo3) is 8 not 5. Thus, in the quad array, each member has 3 bytes of trailing padding, because the first member of each following struct in the array wants to be self-aligned on an 4-byte boundary. The memory layout is as though the structure had been declared like this:

struct foo3 {



char pad[3];

}; 9

Memory alignment


If our structure has structure members, the inner structs want to have the alignment of longest scalar too. Suppose we write this:

struct foo5 {

char c;

struct foo5_inner {

char *p;

short x;

} inner;

};

The char *p member in the inner struct forces the outer struct to be pointer-aligned as well as the inner.

10

Memory alignment


Actual layout will be like this on a 32-bit machine:

struct foo5 {

char c; /* 1 byte*/

char pad1[3]; /* 3 bytes */

struct foo5_inner {


short x; /* 2 bytes */

char pad2[2]; /* 2 bytes */

} inner;

};

This structure gives us a hint of the savings that might be possible from repacking structures. Of 12 bytes, 5 of them are padding. That’s more than 40% waste space!

11

Memory alignment

#pragma pack()

GCC supports a set of #pragma directives that change the maximum alignment of members of structures (other than zero-width bit-fields), unions, and classes subsequently defined. The n value below always is required to be a small power of two and specifies the new alignment in bytes:

#pragma pack(push) /* Store packing settings */

#pragma pack(1) /* Align on 1 byte basis */

struct foo11 {

struct foo11 *p;

short x;

char c;

};

#pragma pack(pop) /* Restore packing settings */

The structure will be aligned on 1 byte basis, so it will have 7 bytes size.

12

Memory alignment

Bitfields

They give us the ability to declare structure fields of smaller than character width, down to 1 bit, like this:

struct foo6 {

short s;

char c;

int flip:1;

int nybble:4;

int septet:7;

};

foo6 f1;

f1.nybble = 0b1001;

The thing to know about bitfields is that they are implemented with word- and byte-level mask and rotate instructions operating on machine words, and cannot cross word boundaries.

Bitfields member can be accessed by its name as any normal structure member.

13

Memory alignment

Bitfields

The memory layout of the structure will be something like that:

struct foo6 {

short s;

char c;

char pad[1];

int flip:1;

int nybble:4;

int septet:7;

int pad2:20;

};

The size of the structure will be 8 bytes, but if we made 3 different integers for flip, nybble and septet the size would have been 16 bytes, which save 50% of memory.

14

Memory alignment

Bitwise operations

15

To set a specific bit in a specific register or variable:

16

Bitwise operations

/*--------------------------------------------------------------------

Description : Macro used to set a specific bit in a specific register

Input : .Register : register name

.Pin_Num : Pin number to set

--------------------------------------------------------------------*/

#define SET_BIT(Register,Pin_Num) ((Register) |= (1<<(Pin_Num)))

To clear a specific bit in a specific register or variable:

/*----------------------------------------------------------------------

Description : Macro used to clear a specific bit in a specific register


.Pin_Num : Pin number to clear

----------------------------------------------------------------------*/

#define CLEAR_BIT(Register,Pin_Num) ((Register) &= (~(1<<(Pin_Num))))

To check if a specific bit in a specific register or variable is set:

17

Bitwise operations

/*----------------------------------------------------------------

Description : Macro used to check if a specific bit in a specific register is set


.Pin_Num : Pin number to check

----------------------------------------------------------------*/

#define IS_BIT_SET(Register,Pin_Num) ((Register) & (1<<(Pin_Num)))

To check if a specific bit in a specific register or variable is clear:

/*----------------------------------------------------------------

Description : Macro used to check if a specific bit in a specific register is clear


.Pin_Num : Pin number to check

----------------------------------------------------------------*/

#define IS_BIT_CLEAR(Register,Pin_Num) (!((Register) & (1<<(Pin_Num))))

To toggle a specific bit in a specific register or variable:

18

Bitwise operations

/*--------------------------------------------------------------------

Description : Macro used to toggle a specific bit in a specific register


.Pin_Num : Pin number to toggle

--------------------------------------------------------------------*/

#define TOGGLE_BIT(Register,Pin_Num) ((Register) ^= (1<<(Pin_Num)))

To shift a register or variable left or right:

var1 = var1 >> 1; /* Shift all bits one step right, equals to dividing variable by 2 */

var2 = var2 << 1; /* Shift all bits one step left , equals to multiplying variable by 2 */

To rotate a register or variable left, assuming 8-bits register or variable:

19

Bitwise operations

/*-------------------------------------------------

Description : Macro used to rotate a register left


.Num : Number of rotations

-------------------------------------------------*/

#define ROTATE_L(Register,Num) (REG = (REG<<NUM) | (REG>>(8-NUM)))

To rotate a register or variable right, assuming 8-bits register or variable:

/*-------------------------------------------------

Description : Macro used to rotate a register right


.Num : Number of rotations

-------------------------------------------------*/

#define ROTATE_R(Register,Num) (REG = (REG>>NUM) | (REG<<(8-NUM)))

HW and I/O concepts

20

Memory mapping

Device drivers communicate with peripheral devices through device registers. A driver sends commands or data to a device by storing into its device register, or retrieves status or data from a device by reading from its device register.

Many processors use memory-mapped I/O, which maps device registers to fixed addresses in the conventional memory space. To a C or C++ programmer, a memory-mapped device register looks very much like an ordinary data object. Programs can use ordinary assignment operators to move values to or from memory-mapped device registers.

Example on Arm-CortexM4 processor:

#define GPIO_PORTF_DATA_R (*((volatile unsigned long *)0x400253FC))

Then when typing:

GPIO_PORTF_DATA_R |= 0x01;

It will output logic high on pin0 of PORTF. 21

HW and I/O concepts

Polling vs. Interrupt

A single microcontroller can serve several devices, that are two ways to do that: interrupts or polling

• Polling: In the Polling method, the microcontroller must "access by himself" the device and “ask” for the information it needs for processing. In fact we see that in the Polling method the external devices are not independent systems; they depend on the microcontroller, and only the micro is entitled to obtain access to the information it needs.

The main drawback of this method when writing program is waste of time of microcontroller, which needs to wait and check whether the new information has arrived.

The microcontroller continuously monitors the status of a given device until required information is ready. After that, it moves on to monitor the next device until everyone is serviced. The microcontroller checks all devices in a round robin fashion.

22

HW and I/O concepts


• Interrupt: Interrupt is the signal sent to the micro to mark the event that requires immediate attention.

Interrupt is “requesting" the processor to stop performing the current program and to “make time” to execute a special code. Whenever any device needs its service, the device notifies the microcontroller by sending it an interrupt signal.

Upon receiving an interrupt signal, the microcontroller interrupts whatever it is doing and serves the device. The program which is associated with the interrupt is called the interrupt service routine (ISR) or interrupt handler.

23

HW and I/O concepts


24

HW and I/O concepts

Is info ready

?

No

yes

Process information

Polling Interrupt

DMA

Direct memory access (DMA) is a feature of computer systems that allows certain hardware subsystems to access main system memory (RAM) independently of the central processing unit (CPU).

Without DMA, when the CPU is using programmed input/output, it is typically fully occupied for the entire duration of the read or write operation, and is thus unavailable to perform other work.

With DMA, the CPU first initiates the transfer, then it does other operations while the transfer is in progress, and it finally receives an interrupt from the DMA controller when the operation is done.

This feature is useful at any time that the CPU cannot keep up with the rate of data transfer, or when the CPU needs to perform useful work while waiting for a relatively slow I/O data transfer.

25

HW and I/O concepts

Bootloader

On reset, processor will always start executing a specific code located at a particular memory location, this piece of software is called “Bootloader”.

The job of the bootloader then, is to do one of two things:

1. Replace the existing application code with a new application (Flashing).

2. Start the existing application (By jumping to the application startup code).

How it determines which of these two things to do varies by implementation, but generally some external signal (such as a command on the serial port or a particular I/O line being pulled low) will tell it to load a new application from the communication port (or some other location) and write it to the application memory.

26

HW and I/O concepts

Startup file

One of the things that traditional software development tools do automatically is insert startup code: a small block of assembly language code that prepares the way for the execution of software written in a high-level language.

Each high-level language has its own set of expectations about the runtime environment. For example, programs written in C use a stack. Space for the stack has to be allocated before software written in C can be properly executed. That is just one of the responsibilities assigned to startup code for C programs.

Most cross-compilers for embedded systems include an assembly language file called startup.asm, crt0.s (short for C runtime), or something similar. The location and contents of this file are usually described in the documentation supplied with the compiler.

27

HW and I/O concepts

Startup file

Startup code for C programs usually consists of the following series of actions:

• Disable all interrupts.

• Copy any initialized data from ROM to RAM.

• Zero the uninitialized data area.

• Allocate space for and initialize the stack.

• Initialize the processor’s stack pointer.

• Call main.

Typically, the startup code will also include a few instructions after the call to main. These instructions will be executed only in the event that the high-level language program exits (i.e., the call to main returns). Depending on the nature of the embedded system, we might want to use these instructions to halt the processor, reset the entire system, or transfer control to a debugging tool.

28

HW and I/O concepts

Inline Assembly

29

Inline assembly is a feature of some compilers that allows very low level code written in assembly to be embedded in a high level language like C. This embedding is usually done for one of three reasons:

• Optimization (ex. Increase speed).

• Access to processor specific instructions (ex. Test and Set).

• System calls.

Example for GCC compiler:

asm("movl %ecx, %eax"); /* moves the content of ecx to

eax */

The main problem of using inline assembly in our code is portability because assembly instructions and syntax is hardware and compiler dependent.

30

Inline Assembly

Software layered architecture

31

The drive to reduce product development cycle times has led to the need for designing reusable code. It's apparent that reusing code across software projects decreases project development time.

In a simple embedded system, the layered architecture can be divided into this layers:

32


Microcontroller HW

DIO UART I2C SPI

External EEPROM WiFi module On/Off Device

Application

MCAL Abstraction

HW Abstraction

MCAL: Micro-Controller Abstraction layer which contains the different device drivers for controller hardware parts.

HW/AL: Hardware Abstraction Layer which abstracts the external connected hardware, it uses the APIs provided by the MCAL layer to control the external connected hardware.

Application layer: which contains the logic of the whole application using the APIs provided by the HW/AL.

Layered architecture has a lot of advantages like:

• code reusability: We can reuse all different modules in other projects without major changes.

• code portability: We can change the used micro controller and only change the MCAL layer.

• code maintainability: Maintaining code will be easier as only one or few modules will get affected with code maintenance.

but it also has its draw back of execution speed, design complexity. 33


Layered architecture goals are achieved through making each module concerned with a specific part (ex. UART driver) and provide some APIs to be used by higher layers (ex. UART_send, UART_receive), so any need to change this module (ex. Changing the microcontroller) will not affect all modules but only a specific module (MCAL in our example including UART) and any new module will also provide the same APIs (In our example UART_send, UART_receive and other MCAL APIs) to be used inside the same project without changing higher layers code.

This means that higher layers use the provided APIs to call lower layers, but what if a lower layer want to call the higher layers ? This is achieved by the call back function concept.

34


Call back function

It is using a pointer to function to be used by the lower layers to call higher layers.

Example: if the Timer driver wants to know how to notify higher layers when the timer fires, then the initialization function of the timer would be something like that:

void timer_Init(uint32 time_ms,void (*callBack_ptr)(void));

Input parameters are:

time_ms: required time to make the timer fire after.

callBack_ptr: the required function to be called after timer fire.

So when timer_Init function is called by higher layers, it will store the pointer to function provided by higher layer, then when timer fires it will use the pointer to function to notify the higher layer by calling this function.

35


MISRA rules

36

MISRA

The Motor Industry Software Reliability Association (MISRA) is an organization that produces guidelines for the software developed for electronic components used in the automotive industry.[1] It is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies.

MISRA C

MISRA C is a set of software development guidelines for the C programming language developed by MISRA.

Its aims are to facilitate code safety, portability and reliability in the context of embedded systems, specifically those systems programmed in ISO C. There is also a set of guidelines for MISRA C++.

MISRA has evolved as a widely accepted model for best practices by leading developers in sectors including aerospace, telecom, medical devices, defense, railway, and others. 37

MISRA rules

Rule classification

Rules are divided into 2 main types:

• Required rules: These are mandatory requirements placed on the programmer. There are 93 ‘required’ rules. C code which is claimed to conform to MISRA rules shall comply with every required rule (with formal deviations required).

• Advisory rules: These are requirements placed on the programmer that should normally be followed. However they do not have the mandatory status of required rules. There are 34 ‘advisory’ rules. Note that the status of ‘advisory’ does not mean that these items can be ignored, but that they should be followed as far as is reasonably practical. Formal deviations are not necessary or advisory rules, but may be raised if it is considered appropriate.

38

MISRA rules

Rules examples

Rule 1 (required): All code shall conform to ISO 9899 standard C, with no

extensions permitted.

Rule 10 (advisory): Sections of code should not be ‘commented out’.

Rule 13 (advisory): The basic types of char, int, short, long, float and double should not be used, but specific-length equivalents should be typedef’d for the specific compiler, and these type names used in the code.

Rule 14 (required): The type char shall always be declared as unsigned char or signed char.

39

MISRA rules

Rules examples

Rule 20 (required): All object and function identifiers shall be declared before use.

Rule 21 (required): Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier.

Rule 22 (advisory): Declarations of objects should be at function scope unless a wider scope is necessary.

Rule 23 (advisory): All declarations at file scope should be static where possible.

Rule 25 (required): An identifier with external linkage shall have exactly one external definition.

40

MISRA rules

Rules examples

Rule 50 (required): Floating point variables shall not be tested for exact equality or inequality.

Rule 52 (required): There shall be no unreachable code.

Rule 56 (required): The goto statement shall not be used.

Rule 57 (required): The continue statement shall not be used.

Rule 58 (required): The break statement shall not be used (except to terminate the cases of a switch statement).

Rule 59 (required): The statements forming the body of an if, else if, else, while, do ... while or for statement shall always be enclosed in braces.

41

MISRA rules

Rules examples

Rule 28 (advisory): The register storage class specifier should not be used.

Rule 30 (required): All automatic variables shall have been assigned a value before being used.

Rule 32 (required): In an enumerator list, the ‘=’ construct shall not be used to explicitly initialise members other than the first, unless all items are explicitly initialised.

Rule 37 (required): Bitwise operations shall not be performed on signed integer types.

Rule 43 (required): Implicit conversions which may result in a loss of information shall not be used.

42

MISRA rules

Rules examples

Rule 60 (advisory): All if, else if constructs should contain a final else clause.

Rule 61 (required): Every non-empty case clause in a switch statement shall be terminated with a break statement.

Rule 62 (required): All switch statements should contain a final default clause.

Rule 63 (advisory): A switch expression should not represent a Boolean value.

Rule 64 (required): Every switch statement shall have at least one case.

Rule 70 (required): Functions shall not call themselves, either directly or indirectly.

Rule 82 (advisory): A function should have a single point of exit. 43

MISRA rules

Task 4

44

Mohamed AbdAllah Embedded Systems Engineer [email protected]

45

embedded c - lecture 4

Engineering