# stm32_module Design Choice
###### tags: `firmware_hardware` `electrical_system` `NTURT`

## Introduction

In order to increase the maintainability and reusability of our code, we decided to implement modules instead of hard written code specific for our needs. Such as a controller for variable amount of leds instead of a set of pre-determined leds with dedicated functionality.

In this way, modification can be done easliy without needing to change the implementation part of controlling logic (to the stm32 hal library in this module), just the application code that interacts with the module needs to be changed.

## Object-oriented style c

This module (and so should every c program) is written in object-oriendted style c, for how to do that, checkout: [Object-Oriented Programming](https://www.state-machine.com/oop).

The advantage of oop is obvious, to say the least. It allows us to code like a human (majority of people code in oop) and most important of all, uses [design pattern](https://refactoring.guru/design-patterns).

However, object-oriented c is cumbersome and error-prone as discussed in the [tutorial](https://www.state-machine.com/oop). The best alternative is to use c++ instead of c, but stm32cubeide is really designed for c++ as every of it's source file extension (in `Core` ) is still `c`. We decided to adopt this approach instead. And were it written in c++, it could not be used in other c projects.

## Static allocated everything

Since in real-time control, dynamically allocating memory is **strongly discouraged**,

However, this causes problems such as the user is now responsible for allocating memory for the control block, say new added led.

## Test Driven Development (TDD)