Software modules (for embedded)

Discussion in 'C Programming' started by Erik Cato, May 17, 2004.

  1. Erik Cato

    Erik Cato Guest

    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
     
    Erik Cato, May 17, 2004
    #1
    1. Advertising

  2. Erik Cato

    Case Guest

    Erik Cato wrote:
    > 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
     
    Case, May 17, 2004
    #2
    1. Advertising

  3. Erik Cato wrote:
    > 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
     
    Thomas Matthews, May 17, 2004
    #3
  4. Erik Cato

    Erik Cato Guest

    Case <> wrote in message news:<40a8a128$0$15375$4all.nl>...
    > Erik Cato wrote:
    > > 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.
    >


    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
     
    Erik Cato, May 18, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Colin Paul Gloster
    Replies:
    48
    Views:
    1,891
    Colin Paul Gloster
    Apr 10, 2007
  2. John
    Replies:
    0
    Views:
    1,032
  3. John
    Replies:
    0
    Views:
    1,046
  4. Thomas Dodds

    Databind an embedded control in an embedded datagrid

    Thomas Dodds, Jul 26, 2004, in forum: ASP .Net Datagrid Control
    Replies:
    0
    Views:
    402
    Thomas Dodds
    Jul 26, 2004
  5. Trans
    Replies:
    11
    Views:
    302
    micathom
    Sep 5, 2007
Loading...

Share This Page