CODEWITHSUNDEEP
cembedded
Adnan
Adnan

Reputation: 193

How to write configurable Embedded C code which can run on multihardware platform

What are the techniques used to write an embedded C software which has multi features. Features can be configurable for multi-hardware platform.

I have developed a firmware based on a RTOS for ARM7. Now i want to make it a baseline firmware which can be used with similar, more or less features (configurable) on different microcontrollers, like MSP, or AVR etc.

Being more specific, if i want to change different features of firmware for one hardware and others for the second. What technique should i adopt and is there any study material available. Regards

Upvotes: 1

Views: 2678

Answers (4)

Amardeep AC9MF
Amardeep AC9MF

Reputation: 19024

Generally portability can be address by:

  1. Using drivers for I/O so application code has no hardware specific dependency.
  2. Write an abstraction layer for OS calls so your application code can be adapted to a different RTOS by rewriting a thin layer of function calls.
  3. Avoid use of compiler-specific directives and pragmas or isolate them into a few header files that may be replaced centrally.
  4. Avoid platform dependent data types such as 'int' and use types defined with specified storage size where its important (i.e. uint32_t).
  5. Consider your lowest common denominator when selecting how memory architecture should be designed.

Best of luck.

Upvotes: 1

Judge Maygarden
Judge Maygarden

Reputation: 27573

FreeRTOS has been ported to a lot of architectures including the three you listed. Why don't you take a look at their porting guide for inspiration?

Their approach involves a configuration header file, C file for platform specific driver functions and an assembler file for more platform specific subroutines. All of the other source code only contains common functionality and then uses a common interface for platform-specific driver functions and a few #ifdef's and macros from the configuration header as needed.

Upvotes: 1

Adam Shiemke
Adam Shiemke

Reputation: 3742

There are two approaches that are commonly used: 1) lots of #ifdefs 2) write "drivers" and make sure that other code is abstracted

If you are running on similar platforms, 1) probably would work best for you. If the platforms are very different, then 2) is probably a better idea. Most real-world solutions that I have seen take the #ifdef approach, but this quickly leads to a tangled maze of code that can be difficult to modify. I would recomend something in between, since it is difficult to design the drivers in 2).

Types should be specified in a types.h file, or use explicit types like uint16_t. We define all our own types based on absolutes (U8, U16, U32, S8...), since built-in types in C are implementation dependant. This file is then changed when the architecture changes.

Upvotes: 2

eaanon01
eaanon01

Reputation: 1079

The general key is to take all platform dependtent information and gather it in one or several header files. You can leave the system to be conigured by #ifdef's as well if you cant let them run the same code. I use this method on AVR'r MSP's and for running the code somulated on a standard computer.

Upvotes: 0

Related Questions