You are on page 1of 33

1

Low level programming,


drivers, interrupts service
routines-1
LECTURER: P.PIRAPURAJ
Low level programming 2

 We program computers to do certain tasks teaching them


to act according to a set of rules (algorithms) whenever
they receive input of predefined type(s), in order to receive
expected output. For all such purposes we use
programming languages.
Low level programming… 3

 Its highly advised that you know the most basic


classification of programming languages. Programming
languages can be broadly classified into three categories:
Low level programming… 4

 MACHINE LANGUAGES: Imagine them as the “native


tongue” of the computer, the language closest to the
hardware itself. Each unique computer has a unique
machine language.

A machine language program is made up of a series of


binary patterns (e.g., 01011100) which represent simple
operations that can be accomplished by the computer (e.g.,
add two operands, move data to a memory location).
Low level programming… 5

 Machine language programs are executable, meaning that


they can be run directly. Programming in machine
language requires memorization of the binary codes and
can be difficult for the human programmer
Low level programming… 6

 ASSEMBLY LANGUAGES: They represent an effort to


make programming easier for the human. The machine
language instructions are replaced with simple pneumonic
abbreviations (e.g., ADD, MOV). Thus assembly
languages are unique to a specific computer (machine).
Low level programming… 7

 Prior to execution, an assembly language program requires


translation to machine language. This translation is
accomplished by a computer program known as an
Assembler. Assemblers are written for each unique
machine language.
Low level programming… 8

 HIGH LEVEL LANGUAGES: High-level languages,


like C,C++, JAVA etc., are more English-like and,
therefore, make it easier for programmers to “think” in the
programming language. High-level languages also require
translation to machine language before execution.
Low level programming… 9

 This translation is accomplished by either a compiler or an


interpreter. Compilers translate the entire source code
program before execution.(Eg: C++, Java) Interpreters
translate source code programs one line at a time. (Eg:
Python)Interpreters are more interactive than compilers.
Low level programming… 10

Micro-code
 Each component of CPU is directed by this machine specific code in
order to perform minute scale operations.
 The programmers develop instructions written in micro-code in
order to execute micro-programs.
 Generally used in CPUs and other processing units such as
microcontrollers, channel and disk controllers, processing unit of
digital signal and graphics, controllers of the network interface etc.
 Microcode typically converts instructions into machine language
and be a feature of high speed memory.
Low level programming… 11

Low level programming language


 It is a type of programming language that has negligible or no
abstract with the set of instructions configured in computer’s
architecture.
 Low level language refers to both the assembly language and
machine code.
 However, the language does not have any abstractions with the
machine language but is related to the hardware.
 It does not require the use of interpreter or compiler to translate the
language into machine code.
 Low level language written programs are simple with negligible
memory footprint and runs much faster.
Low level programming… 12

 Therefore, the main advantage of high-level languages


over lower-level languages is that they are easier to read,
write, and maintain.

 Some examples of higher-language programming


languages are C, C++, C#, JAVA, etc.
Low level programming… 13

 Rather than dealing with registers, memory addresses and


call stacks, higher-level languages deal with variables,
arrays, objects, complex arithmetic, threads, locks, and
other abstract computer science concepts, with a focus on
usability over optimal program efficiency.
Low level programming… 14

 The term “higher level language” does not mean that the
language is superior to lower-level programming
languages.

 Lower-level languages have the advantage that the


programmer is able to tune the code to be smaller or more
efficient, and that more system-dependent features are
sometimes available.
Drivers 15

 One of many difficulties in embedded systems


development is hardware dependencies. A software
developer targeting PC/web/mobile platforms generally
doesn’t need to understand the hardware, at least not in
any detail. To an embedded systems developer, this is
critical.
Drivers… 16

 Embedded software interacts with the hardware to get


access to, and to control various hardware resources called
peripheral modules. These can be timers, A/D or D/A
converters, digital I/O, LCD display controllers, and much
more. To use hardware resources like these, you will have
to write device drivers, also known as a HAL (hardware
abstraction layer).
Peripheral Modules 17

A microcontroller often includes hardware functionalities (peripheral modules) like:


 Serial communication (common examples are USB, UART, I2C, etc.)
 Timers (watchdogs, to drive RTOS scheduling, PWM signals for stepper motors,
etc.)
 Digital I/O (for example connected to LED’s, push buttons etc.)
 Analog I/O (A/D converters for measurement, or D/A converters for control)
 Super-fast data transfers (using direct memory access, DMA)
 GUI (LCD and touch controllers)
 Networking (Ethernet for office equipment, CAN for automotive etc.)
 And much more
Peripheral Modules… 18

 To use these functionalities from your software


application, you will need to interact with them. That is
done using device driver software, which acts as a
hardware abstraction layer. A device driver library is an
interface between the hardware and the application
software.
The Anatomy of a Device Driver 19

A device driver library is generally modularized around the peripheral


modules – i.e. there is typically one device driver module for each
peripheral module. For each peripheral module, the device driver
contains 4 types of API functions:
 Initialization (for example, enable a UART channel and initialize
data structures)
 Configuration (for example, to set the baud rate)
 Runtime control (for example, to send characters or retrieve
received characters)
 Shutdown
The Anatomy of a Device Driver… 20

The initialization phase is typically done by one device


driver API function, for example:
UART_Initialize()
 Sometimes, peripheral modules have parallel instances of
hardware functionalities, for example, several serial
channels (UART’s). In such case, the device driver can be
designed to initialize one channel at a time:
UART_Initialize_Channel0()
UART_Initialize_Channel1()
The Anatomy of a Device Driver… 21

Another alternative is to use the channel number as a


parameter:
UART_Initialize( 0 )
UART_Initialize( 1 )
 Itis up to the developer of the device driver library to
decide which architectural model to use.
The Anatomy of a Device Driver… 22

Alternatively, using a per-parameter model, like this:


 UART_SetBaudrate( 9600 )
 UART_SetDatabits( 8)
 UART_SetParity( ‘N’ )
 UART_SetStopbits( 1)
The Anatomy of a Device Driver… 23

Runtime control functions handle the actual behavior as the


system runs – for example sending or receiving characters on
a UART cable, writing pixels to an LCD display, or starting
and stopping timers. Examples of device driver API runtime
control functions are:
 UART_SendChar( ‘a’ )
 UART_SendString( “Hello world!” )
 UART_RetrieveChar()
The Anatomy of a Device Driver… 24

The shutdown phase is often not needed and is usually


omitted in such case. But it might sometimes be required, for
example, to disconnect from a network in a well-behaved
manner. Perhaps, something like this:
ETHERNET_Disconnect()
The Anatomy of a Device Driver… 25

 Many peripheral modules also generate


interrupts/exceptions, that are notifications the hardware
gives to the software indicating a particular hardware
event has happened – for example, a character has been
received on a UART channel, a timer has expired, or a
DMA block memory transfer is completed.
The Anatomy of a Device Driver… 26

 To respond to a hardware event, the device driver


developer has to write an interrupt handler, that is a C
function that is never called by the application program.
Instead, the hardware starts the interrupt handler C
function automatically, whenever a hardware event occurs.

UART_CharacterReceived_InterruptHandler()
Accessing The Hardware – Special 27

Function Registers
 Device driver API functions (for initialization,
configuration, runtime control, or shutdown) and interrupt
handler functions need to talk to the hardware in a bi-
directional fashion. This is done using Special Function
Registers, more commonly called SFR’s or SFR registers.
Special Function Registers 28

 A special function register is just a memory location with a


special meaning and behavior. A special function register
might, for example, be 8 bits wide (16- and 32-bit registers
are common too) and hardcoded by the chip designer to
live on the memory address 0x00F40020.
Special Function Registers… 29

 The SFR register is often divided into several bit groups


that are used for different purposes. In an 8-bit register, the
3 leftmost bits (MSB, most significant bits) might be used
to configure the baud rate of a UART channel, the next 2
bits might be used to configure the parity, the next bit
might be used to configure the number of stop bits, and the
final 2 rightmost (LSB, least significant bits) might be
unused.
Special Function Registers… 30

 Each functional group of bits in the SFR register is a bit


field. In the example above, the first bit field is used for
baud rate configuration, the next bit field is used for parity
configuration, etc.

 Individual bits or bit fields may be read-only, read/write,


write only or unused. To make matters even more
confusing, some SFR register bits might auto-set or auto-
clear themselves if you read or write to them.
Special Function Registers… 31

 So how can we access these hardware functionalities from


software? Assume we want to write code that configures
the baud rate to 2400 baud and leave all other bits
untouched. First, we need to be able to access the register
in a general manner.
Special Function Registers… 32

 Our aim is to be able to read from and write to the register


in the same way we access any other variable. To do that,
we must create a “variable” that is hardcoded to live at the
same memory address as the SFR register, which in our
example is 0x00F40020. We also need to ensure that our
“SFR variable” is the same size as the SFR register – in
this case, 8 bits wide.
33

Thank You

You might also like