A portable driver framwork

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been putting together a project lately that puts together a software framwork that allows same device driver libraries to be used across multiple SoC platforms. Currently I have been working with atmega328p, AT91SAM3 arm and STM32 arm chips.

 

My framework operates in three levels:

level 0) SoC architechture interface with speciffic code for every architecture

level 1) External peripheral drivers (displays, ethernet chips etc) that use SoC interface to communicate with devices that are part of same project

level 2) Application code

 

The level 0 code is basically code that consists of macros and simple functions that provide a generice interface to various on chip interfaces. This code uses for the most part vendor speciffic libraries to set up clocks, registers, memory, etc. This code provides library functions for higher level drivers so that they can be kept portable across many different platforms.

 

The level 1 drivers are responsible for talking to devices like radio modules, accelerometers, motors etc. This level is intended to be chip independent for the most part. It should use standard macros and methods defined in level0 to talk to devices outside of the chip.

 

The application is then built in such way that it uses services defined primarily in the board driver to do stuff like changing speed of motors, reading radio receiver etc. The framework is designed to free applicaiton from all hardware specific register manipulation so that programmer can just focus on developing appliation specific code.

 

To make it all highly configurable, menuconfig is used. It is basically a gui where you can configure which interfaces you will be using and what hardware you want to compile against. This configuration utility automatically determines which drivers you can use and which ones you can't use depending on the hardware you have chosen.

 

Since I have started with the atmega328p architecture, many drivers are originally written for avr. But I am currently working on making them completely portable across both avr and arm. I want to be able to use the same code on both avr, stm32 and sam3.

 

Here is a screenshot of the config utility (run: "make menuconfig"):

 

 

Here is an example project for a multiwii board based flight controller: https://github.com/mkschreder/bettercopter

 

Here is the source code of the framework: https://github.com/mkschreder/martink

 

The closest thing to what I'm working on is probably the u-boot project: http://www.denx.de/wiki/U-Boot/ However, u-boot only works on much higher level chips that boot from sd card and have external ram and lots of resources. I have not been able to find an equivalent framwork for simple controllers like the AVR. Uboot does not run on avr.. So I decided to build a software framwork for bare metal software development on chips that u-boot does not support.

LibK - device driver support for flash based microcontrollers: GitHub project

http://oskit.se - join me on my quest to become a better programmer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought i was building the linux kernel!

i gather you've heard of Arduino? How does you effort compare against it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My project differs from linux kernel in that it targets flash based mcus that linux simply is not suitable for (and does not even officially support). And it differs from arduino in terms of portability and better code reuse. You simply can not easily compile an arduino library written for avr duino on an arm. And often support for multiple chips is hacked in using scattered ifdefs all over the code which is a maintenance nightmare. It is possible to avoid all that by separating code into different layers where bottom ones take care of chip specifics so that top ones can be completely portable.

The build system I use is indeed same config program used in linux. :) But that is simply because it only consists of few c files yet it is so powerful tool for fine grained control over what files are included and which ones are skipped. I started with cmake, but quickly realized cmake did not provide what is necessary for a project like this.

It should be possible to also make arduino libraries compile against the framework, but after looking at a few arduino libraries my first though was "ok this is code with zero code reuse reimplementing even the simplest concepts every time" so my conclusion is that in order to have portable arduino libraries WITHOUT the ifdefs all over the code for every chip is to write such libraries on top of a portable api that does the low level stuff. So that a library for an sd card does not contain any references to avr specific registers at all. All that processor specific stuff simply does not belong in an sd card library if one wants to be able to use it across several different chips with no changes (most importantly being able to add support for new chips without having to make any changes to the code).

So one "problem" with a generic api that I have been thinking about is the overhead of an extra software layer. But the truth is, such a layer can be written intelligently by utilizing macros so that it all compiles into only a few instructions or few simple method calls that would be there anyway even if one were developing everything from scatch for each project. So I try to make the overhead minimal.

Now that I have put in arduino due support in the arch folder it is only a little more work to make all the drivers compile seamlessly for arm and avr without having to make any changes to the driver. And in the future if one wants to add a new architecture, all one has to do is add the manufacturer library to archs and write a glue layer in form of macros which would then allow one to build all of the other drivers for the new arch without having to add nor modify any code in the driver. No ifdefs, no mess, faster time to market for a new architecture.

LibK - device driver support for flash based microcontrollers: GitHub project

http://oskit.se - join me on my quest to become a better programmer