CODEWITHSUNDEEP
carchitectureembeddedsoftware-design
Suvi_Eu
Suvi_Eu

Reputation: 275

Design solutions when the same code part is used/executed by great part of a project modules/code files diferent architecture level distributed

I would like to know how a good embedded sw architect will choose the best option for using a same part of code at different C files modules when those modules are in different architecture levels.

Every module is a file.c with internal and external functions with its corresponding .h file with public functions declarations.

I have 1) low level modules, 2) middle level modules, 3)high level modules and 4)app level modules. Where 4) calls 3) functions, 3) calls 2) functions, etc..

But I have realised that some of 1), 2) and 3) functions are executing the same instructions at differents points of their routines. What is the best option to do a good and efficient code architecture design if a part of code in some 1) routines is also present at routines of some 2) and 3) modules?

My first thought is packing the instruction set in a public function_x and declarate it in a header file in order to be called for upper level modules functions. As architect I have learnt:

  1. to think about headers files file_x.h as a module API to be seen and to be used for other and upper files (the only interface communication between modules).
  2. If an API function is used as internal function in the same module file_x.c that implements them it's not a good design.
  3. ie: 4) modules can not communicate with an 1) module API directly. A 4) module function can only call a 3) module API function, 3) module function can only call a 2) module function; hence 2) module function can only call 1) module functions.

The fact is that I have inheritated an old project and they wrote a byte by digital output sending the byte through serial bus to a potenciometer. But they have implemented and declarate the same function, with the same name as internal function at every module/file. Other times I have found they rewrote this code inside other routines, where I would just call the routine instead of. I thought it could be improved.

So, my doubts are:

  1. Is a good design to pack the instructions set in a function at 1) module level and get called from the rest of the levels modules?

  2. Is a better idea if 2) level module also packs the 1) level module function giving a different name and bringing it to its API header, ready to be used for 3 level modules functions?

  3. What to do if I also use the code in a differents modules but they belong to the same modules level?

  4. How do you face the design if the same function need to be used as internal function and at the same time needs to be called by other files as public function.

Upvotes: 1

Views: 66

Answers (1)

Paul Ogilvie
Paul Ogilvie

Reputation: 25286

A few hints and experiences (not a decisive answer).

Utility functions can be packed in one or more source-level "library" C-files. They are utility, so not hardware specific, and only implement repetitive tasks. For example strcmp is a utility function. You also could provide these as true object libraries that you can distribute to developers/teams.

Data structures and their manipulation can be implemented in their own module (C-file). For example a Btree or linked list.

Hardware specific functions are your "level 1" low-level functions. They provide an API and no-one may manipulate the hardware directly; only through this API. You can "stack" APIs, providing more and more abstraction, but you could see this also as the "level 1" design which itself consists of multiple levels.

App-level coding uses all of the previously described.

Don't be too dogmatic in your levels. When necessary a higher level function may call a low-level function directly without forcing it to go through the intermediate levels. A clean top-to-bottom design is often very difficult to achieve.

Upvotes: 2

Related Questions