Software modules (for embedded)

[Erik Cato]

Hi group!

I'm trying to create at strategy for writing software modules.
I'm writing code for embedded systems but this is not significant for
the solution.

What I'm trying to do is construct software modules that I can use
in several projects. I want the modules to be the same even if the
underlaying hardware change. What I was thinking of doing is to make
functions for talking to the hardware, like GetIO or SetIO and things
like that. I think you get the idea. But the problem is that i need
to include a header file with the function prototypes and the functions
need to be different if the hardware interface is different. Like if
i have a Motorola processor i need to call a Motorola GetIO() and
if i have Atmel MCU i need to call a Atmel GetIO(). But I still wouldn't
like to chang my software module!

Is this doable? If so, what is the best approach?

/Erik

 

[Case]

Hi group!

I'm trying to create at strategy for writing software modules.
I'm writing code for embedded systems but this is not significant for
the solution.

What I'm trying to do is construct software modules that I can use
in several projects. I want the modules to be the same even if the
underlaying hardware change. What I was thinking of doing is to make
functions for talking to the hardware, like GetIO or SetIO and things
like that. I think you get the idea. But the problem is that i need
to include a header file with the function prototypes and the functions
need to be different if the hardware interface is different. Like if
i have a Motorola processor i need to call a Motorola GetIO() and
if i have Atmel MCU i need to call a Atmel GetIO(). But I still wouldn't
like to chang my software module!

Is this doable? If so, what is the best approach?

One common strategy is to use the linker
========================================
Create different source file versions for each type of hardware.
To illustrate this point you could name them mxxx_io.c,
atmelxxx_io.c, ... Each file implements the same set of
functions. Then you place all common definitions in one
header file (e.g., io.h) which you include in each xxx_io.c
and also in your application module.

Selecting the right hardware is done by linking the right
hardware specific module (mxxx_io.o, atmelxxx_io.o, ...)
with you other application modules.

This strategy is simple and works well when you know which
hardware device you will use beforehand and don't need to
change it later or often. It is a static solution.

There are other techniques/strategy which give a more dynamic
result. They are more complicated or are off topic here
because they will use specific dynamic linking features of
your compilation/execution environment.

HTH

Kees

 

[Thomas Matthews]

Hi group!

I'm trying to create at strategy for writing software modules.
I'm writing code for embedded systems but this is not significant for
the solution.

What I'm trying to do is construct software modules that I can use
in several projects. I want the modules to be the same even if the
underlaying hardware change. What I was thinking of doing is to make
functions for talking to the hardware, like GetIO or SetIO and things
like that. I think you get the idea. But the problem is that i need
to include a header file with the function prototypes and the functions
need to be different if the hardware interface is different. Like if
i have a Motorola processor i need to call a Motorola GetIO() and
if i have Atmel MCU i need to call a Atmel GetIO(). But I still wouldn't
like to chang my software module!

Is this doable? If so, what is the best approach?

/Erik

There is a technique I like to call Software Reuse Through
Evolution. In this technique, common functions in two or more
modules are extracted into one {or more} modules. This also
involves making the interface more generic.

With your example, create a header file that contains the
declarations for GetIO() and SetIO(). Write the definitions
for the Motorola implementation in one file and the Atmel
processor in another. Use the linker, project file, or
build script to choose which file to use. This isolates
the implementation from the rest of the program, which
is a Good Thing.


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Erik Cato]

One common strategy is to use the linker
========================================
Create different source file versions for each type of hardware.
To illustrate this point you could name them mxxx_io.c,
atmelxxx_io.c, ... Each file implements the same set of
functions. Then you place all common definitions in one
header file (e.g., io.h) which you include in each xxx_io.c
and also in your application module.

Selecting the right hardware is done by linking the right
hardware specific module (mxxx_io.o, atmelxxx_io.o, ...)
with you other application modules.

This strategy is simple and works well when you know which
hardware device you will use beforehand and don't need to
change it later or often. It is a static solution.

Thanks a lot for that answer. My thoughts has been in this direction but
you really summarised them nicely. This is probably the way we should go.

Thanks!

/Erik