You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to greatly improve maintainability and expandability of Firmware code, a hardware abstraction layer (HAL) should be implemented in context of a big refactoring. The new architecture will then form the base of firmware version 2.x.x
Multiple components have to be extracted out of the current code (mainly from Mount.cpp and init files) and placed into well designed and encapsulated units. These units should follow single-responsibility principle (e.g. a stepper driver should only be responsible for the actual driver hardware and not care about higher level hardware or software like the board it is attached to or the interrupt routine used for step triggering).
The strict encapsulation will allow proper automated unit testing later and increase stability of the whole firmware after code or configuration changes. It will also provide an easy way for further hardware support implementations.
stepper abstraction
driver abstraction
platform abstraction
board abstraction
The text was updated successfully, but these errors were encountered:
I plan on taking a look at this, I also want to have the code build for a STM32L4. Platformio should still be applicable. I would be happy to hear some of your ideas if you have put some thought into this task since first posting this.
No work has taken place on this, the primary developer needed to take a break and hasn't returned (yet). There is a branch that was started to help with porting to STM32 platforms, it's called stm32-debug. I'm not sure what state it is in.
In order to greatly improve maintainability and expandability of Firmware code, a hardware abstraction layer (HAL) should be implemented in context of a big refactoring. The new architecture will then form the base of firmware version 2.x.x
Multiple components have to be extracted out of the current code (mainly from Mount.cpp and init files) and placed into well designed and encapsulated units. These units should follow single-responsibility principle (e.g. a stepper driver should only be responsible for the actual driver hardware and not care about higher level hardware or software like the board it is attached to or the interrupt routine used for step triggering).
The strict encapsulation will allow proper automated unit testing later and increase stability of the whole firmware after code or configuration changes. It will also provide an easy way for further hardware support implementations.
The text was updated successfully, but these errors were encountered: