I am trying to understand and implement a method of reusable code, starting with STM32 projects. Any ideas on the best method(s)?

[JNoon.1]

Hi,

I am trying to implement a method of reusable code starting with STM32 projects. I have multiple micro controllers (F4, F7 etc) that will need to run the same application code. As STM generate the Drivers/HAL for me. Would I need to write API functions that will sit between the application code and the HAL functions?

In terms of version control, I would be looking at making the application code and API code submodules, and having the hardware project with the Drivers and HAL etc in its own repo too. The application and API sub modules won't be able to build individually, but when built with the main hardware project they will.

I was thinking of having it structured something like this:

Code/
  API/
    Inc/
    Src/
  Application/
    Inc/
    Src/
  Core/
    Inc/
    Src/
  Drivers/
  Middlewares/
 
Test/
  "Similar structure to Code/ but only for my own code"

I've read some books and searched Google etc but there does not seem to be enough information for what I need. I've seen examples of making the HAL layer reusable, I'm guessing its normal for the HAL/API/Application code to not be built separately and only all together?

Any feedback or suggestions or help would be very much appreciated.

Thanks!

[Javier1]

I would bet youre an experienced programmer but not in embedded, youhave an API mindset, smells like web developer. XD, im not sure you understand how the compiler works.

>>Would I need to write API functions that will sit between the application code and the HAL functions?

Thats how everyone i know does it.

>>In terms of version control, I would be looking at making the application code and API code submodules, .h/.c files.

>>and having the hardware project with the Drivers and HAL etc in its own repo too.

why do you want to sepparate them

>>The application and API sub modules won't be able to build individually, but when built with the main hardware project they will.

this makes no sense to me, isnt that how a regular compiler works?

My own limited experience tells me everyone has its own arquitecture answering to their own set of problems ans requirements, but almost all (including mine) looks like what youre proposing, a sepparate folder with .h and .c "API" code included in main.c and using HAL libraries.

[KnarfB]

This is a very broad topic and there is no single best approach. There is a trade-off between portability, performance, and readability. As HAL is already considered bloated, putting yet another API layer inbetween HAL and your app code may work, or may not work. Also depends on the planned man power and project time line.

As you said, look at a number of existing portable projects like https://github.com/betaflight/betaflight and imitate some approach that feels right for you.

Apps are typically built all together, because then the compiler has the largest decision space for all kinds of optimization, and you have the best/easiest debugging experience.

hth

KnarfB

[JNoon.1]

Thanks for your reply!

No I am not a web dev.... just a Embedded Engineer not long into their career, and I know that in the Embedded world code reuse is not a strong point!

I would want to keep them separate as I am trying to support using the same application code with different hardware, and not sure on the best way to structure it and control it in version control.

Basically the "glue", the API would not be compiled alone as why would it, same as the application code why would they need to be complied separately. That's why I thought I would use submodules so that any new hardware I need to use would be able to get the submodules and all I would need to change is the HAL function calls in the API layer.

I didn't know if it would be needed or not to add the API layer at all. Instead just controlling which HAL functions to call in the application code.

[JNoon.1]

Thank you for the reply, I appreciate it!

That's the conclusion I'm coming to... there is no right or wrong answer.

I could just control which HAL functions I call in my application code the same as I would have as if it was in an API.

I'm trying to figure out a good way of being able to reuse the application code on multiple micro controllers without changing a lot. I've started to move any HAL function calls into a API, where I would call the API from my application code and the API would use the pre-processor to decide which HAL to call.

Only problem I'm coming to is structuring it in a nice way not to make it difficult to maintain. And especially if I want to add testing in the future.

Joe

[S.Ma]

The first thing to check are the reference manual. Design IP generations may vary, consequently the APIs or behaviour. DMAMUX is one big difference if it is.

Try to have a portable code as much as possible as baseline first. Then once the code is "mature", optimize it for a specific target (this is the non-reuse time you'll spend).

My humble advice : Try to avoid using global variables in functions. Make generic functions with few entry points to drivers functions (concentrate).

There is a balance between cost (optimisation) and (development) time.

Maintenance cost and time is one key parameter to consider when choices need to be made.