Hardware abstraction layer for microcontrollers

Lukasz Krzak
Department od Electronics,
Faculty of Computer Science, Electronics and Telecommunications
AGH University of Science and Technology in Kraków
lukasz.krzak@agh.edu.pl
www.wsn.agh.edu.pl
Outline

1. How the story began.

2. Important qualities of embedded software and how to reach them.
3. How others are doing embedded software.
4. What we did and what is already done.
5. What are the results.
6. What we still want to do.
7. How YOU can participate.

2
How the story began...

3
Wireless Sensor and Control Networks Laboratory
● Wireless communications (hardware and software)
● Embedded systems

● Resonant power supply and energy harvesting

● Electromagnetic compatibility

Many of these projects were commercially deployed in industrial applications.

The developed hardware and software solutions are licensed by AGH.
4
Our initial motivation (2007)

Question: What hardware/software platform to choose ?

5
Important qualities of embedded software

6
Important qualities of embedded software
AKA: How to distinguish good code from bad code

A good code:

● works! (but that's obvious)

● is reliable (works every time)

● is testable (we can easily proove that it works)

● is portable (to different hardware and build tools)

● is reusable (we can use it many times)

● is simple, user-friendly, and easy to maintain

● is feature-rich

7
Important qualities of embedded software

reusable
speeds up the development
(off-the shelf components)
increases reliability
(more applications, more confidence)

embedded
software

simple feature-rich

8
reusable == portable

9
Reusable == portable

source: ubmdesign.com / http://www.slideshare.net/MTKDMI/2013-embedded-market-study-final 10

Reusable == portable

source: ubmdesign.com / http://www.slideshare.net/MTKDMI/2013-embedded-market-study-final 11

 Reusable <=> portable

because
changes
sucks!

source: ubmdesign.com / http://www.slideshare.net/MTKDMI/2013-embedded-market-study-final 12

How others are doing it?

13
AUTOSAR (AUTomotive Open System Architecture)
“Cooperate on standards,compete on implementation”

source: www.autosar.org
14
CMSIS (Cortex Microcontroller Software Interface Standard)

source: www.arm.com
15
Arduino

Arduino is an open-source electronics prototyping platform, based on flexible,

easy-to-use hardware and software. It's intended for artists, designers,
hobbyists and anyone interested in creating interactive objects or environments.

Arduino programs are written

in C or C++. The Arduino IDE
comes with a software library
called "Wiring" from the
original Wiring project, which
makes many common
input/output operations much
easier.

source: http://arduino.cc/
16
Why reinvent the wheel? We have C stdlib!

#include <stdio.h>
Standard C library is already
portable (same with C++/STL)
It supports I/O operations
int main(void) Works in embedded world too!
{ Focused on batch processing and
text communication
printf(“Hello World!”); Lack of support for multithreaded
applications
return 0; Lack of support for real-time
Usually leads to large code
}
MISRA says: no!

17
Component based software architecture

18
Component-based architecture

User Interface Data processing

Graphical User Communication

Interface (GUI) Library stack

Communication
LCD driver
port driver

Hardware

19
How to design reusable/portable code?

My Precious Code

20
Important design choices

Applications

My Precious Code

What is the potential range of applications?

21
Important design choices

Applications

My Precious Code

Hardware

What is the potential range of hardware we need to run on?

22
Important design choices

Applications

My Precious Code

RTOS
Hardware (Really Tricky
Operating System)

Will an OS be used? Which one(s)?

23
Important design choices

Applications

Other libs My Precious Code

RTOS
Hardware (Really Tricky
Operating System)

What is the level of integration with other software components?

24
Important design choices

Toolchain
Applications
(Complainer etc)

Other libs My Precious Code

RTOS
Hardware (Really Tricky
Operating System)

What programming language? What toolchains need to be supported?

25
Important design choices

Toolchain
Applications
(Complainer etc)

Other libs My Precious Code Standards

RTOS
Hardware (Really Tricky
Operating System)

What standards must be obeyed?

26
How to design reusable software?

Application code

Defines usability

Component code

Defines portability

Hardware RTOS

27
How to design reusable software?

Application code

“egocentric” approach
Component code

HW glue OS glue

Hardware RTOS

28
How to design reusable software?

Application code

“egocentric” approach
Component code Component code multiplied

HW glue OS glue HW glue OS glue

Hardware RTOS

29
Towards abstraction...

Application code

Component code Component code

HW/OS
HW interface RTOS interface abstraction
layer

Hardware RTOS

30
Hardware Abstraction Layer (HAL)

31
 Bad reputation: HAL 9000

“Open the pod bay doors, HAL.”

32
 Consequences of having HAL

Application-dependent code Application code

(changes with application)

Independent code = resusable Component code Component code

(does NOT change even when
hardware or OS or application changes)

HW/OS Abstraction Layer

HW/OS-dependent code
(changes with hardware or operating
system used -in ex. peripheral drivers)
Hardware RTOS

33
 Advantages of HAL: switching HW/OS

It is possible to more easily switch Application code

to other microcontroller or other
operating system during
development:

less risk in picking up wrong

tools Component code Component code

HW/OS Abstraction Layer

Hardware RTOS
(AT91SAM3S)
(STM32) (FreeRTOS)
(uC/OS-II)

34
 Advantages of HAL: cross-development

It is possible to develop Application code

component and application code in
a more convenient environment on
a PC:

speeds up the development

allows easier unit and Component code Component code
integration testing of components
allows to build large scale
simulation environments

stress tests not possible

HW/OS Abstraction Layer

Hardware RTOS
OS
(STM32)
(PC) (Windows/Linux)
(FreeRTOS)

35
Advantages of HAL: less effort == less bugs
Effort ~ number of errors

coding
architecture testing
requirement
analysis
time
deadline !

Effort ~ number of errors

coding
requirement testing
architecture
analysis
time
deadline !

36
Advantages of HAL: cross platform testing

We can reuse the software across platfroms to enable communication between them.
This is useful for both the application development and testing.

utilities (data analysis, utilities (data analysis,

visualization) visualization)

software
test case software
under test

communication communication

Embedded hardware PC

37
Advantages of HAL: automated unit testing

We can run the embedded software on a PC platform, extending the concept of

continuous integration with automated unit tests.

version control automated automated

repository build test

continuous integration system

38
Disadvantages of HAL – major concerns

Efficiency.
Our experiments show that handling HAL abstraction can have little or no overhead
compared to chip vendor libraries. We try to follow the “only pay for what you use”
paradigm. The efficiency depends heavily on the actual realization of HAL interfaces on
the target platform.

Limitation of functionality due to choosen abstraction.

Although HAL cannot cover 100% of all available functionality of a microcontroller, it shall
not limit the potential usage of additional functionality.

Conflicts with other frameworks / libraries / components.

Modular HAL design shall help with the integration of different libraries.

39
 HALFRED
Hardware Abstraction Layer For Real-time Embedded Designs

www.wsn.agh.edu.pl/halfred

40
HALFRED wishlist

Universal layer acting as a bridge between hardware and reusable

software components
Unified interfaces covering as much microcontroller functionality as
possible
Clear line between hardware dependent and independent code,
maximizing the second one
No assumptions about the application style
Built-in support for multithreaded applications
Good support for real-time applications
Included support for in-application diagnostics
Modular, tunable architecture
Compatible between modern compilers
Good documentation
Test driven development
Written in C (C99)

41
HALFRED current modules

The up-to-date documentation can be found on the project webpage:

www.wsn.agh.edu.pl/halfred

42
Design process example
(GPIO module)

43
HALFRED design process

Choose microcontroler representatives

Analyze architecture (core, peripherals, memory etc.)
Design abstractions (UML)
Generate interfaces
Write test cases
Implement code
Test
Repeat :)

44
STEP1: Analyze representative microcontrolers
STM32F1

45
STEP1: Analyze representative microcontrolers
EFM32LG

46
STEP2: Identify abstract model

output state
register (0/1)
OD/PP

peripherals
(USART, SPI etc.)
PORT.PIN

input state
register (0/1)

configuration
interrupts
register

47
STEP3: Design and generate interfaces

48
STEP4: Write test case

main.c
void testGPIO(void)
{
int i;

// initialize GPIO module

GPIO_Init();

// configure test port

GPIO_ConfigurePin(TEST_PIN, DEFAULT_CONFIG);

// do some GPIO stuff

for (i=0; i < 100; i++) {
GPIO_TogglePin(TEST_PIN);
}

// deinitialize GPIO module

GPIO_Deinit();
}

49
STEP5: Implement and test

hal_config.h
#define TEST_PIN_PORT GPIOC
#define TEST_PIN_PIN 13
#define TEST_PIN_DEFAULT_CONFIG GPIO_Mode_Out_PP

50
Results

51
 What we've done so far

● Identified the level of abstraction needed, identified key modules

● Designed a modular architecture (UML)
● Made first implementation supporting various microcontrollers
● Documented it.
● Prepared simple examples.
● Used it in several complex real-world projects
● Gathered test results, performance metrics and user remarks
● Updated architecture and implementation based on user reviews

52
 Supported hardware / OS / toolchain

● STM32F1, STM32F4 from STMicroelectronics

● ATSAM3S from Atmel
● EFM32LG, EFM32GG from Silicon Labs (formerly Energy Micro)
● ATmega from Atmel
● PCs

 FreeRTOS
 uC/OS-II
 Linux (posix)
 Windows (win32 api)

 GNU Compiler Collection

 MS Visual Studio

53
 Feedback from our initial project

● STM32 turned out to be fine, we didn't have to make the switch

● Designing/implementing HAL took more time that I thought it will :)

● Having HAL positively influenced the architecture of other components

● It was easy to standarize components on HAL

● Components tested on STM32 worked out-of-the-box on AVR

● The project was deployed successfully in an industrial application

54
(not so) Unexpected outcomes

● Thanks to the PC port quite a lot of embedded software

was developed (coded/debugged) in a convenient PC
environment, and then just tested on the target hardware
platform. It was possible to run unit tests on a PC.

● Having ports for linux (posix) and Windows (WIN32 API)

allowed for easy writing of cross-platform utilities (for testing
purposes).

● It was easy to insert other general-purpose components into

HAL (buffer pools, heap managers, logging/diagnostic tools, data
structures)
● It was natural to incorporate build tools into HAL, which shifted

a lot of makefile horror away from application code.

HAL became more like a framework than just a bunch of drivers.

55
Emulating and developing distributed systems

discrete event simulator

Application code

Component code

HALFRED

OMNeT++

56
Emulating and developing distributed systems

discrete event simulator

Application code

Component code

HALFRED

EFM32

57
The future

58
Current design choices

Switch to C++11.

Depend on GNU tools with options to support other toolchains.

Do not depend on chip vendor libraries (efficiency, co-existence)

Make full usage of language and toolchain features (optimization, removal of

unused code sections, detection of ambigous constructs, etc.)

Gracefully degrade when there's no OS.

Follow reasonable safety guidelines, such as MISRA C++.

Consider certification options, such as IEC 61508 SIL.

59
Vendor libraries independency

HALFRED now tends not to use

Application code
libraries provided by chip vendor.

This is why these libraries can be

easily used by the application!
(no version conflicts)
Component code

Vendor libraries

HALFRED

Hardware RTOS

60
 We need your help!

Check out how can you participate on the project webpage

(link will be available soon)

61