Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HAL implementation details #463

Open
Paciente8159 opened this issue Aug 3, 2023 · 0 comments
Open

HAL implementation details #463

Paciente8159 opened this issue Aug 3, 2023 · 0 comments
Labels
documentation Improvements or additions to documentation roadmap roadmap

Comments

@Paciente8159
Copy link
Owner

Paciente8159 commented Aug 3, 2023

These implementation details will target v1.8 and newer.

Documentation

Documentation is hard to keep up to date. It's even harder if breaking changes are introduced by a enancement, or new feature. Cumulative documentation for all different versions becomes too extensive and hard to read. Deleting old documentation may lead to older version to be used and modified if need by the user.

For this reason documentation will start to be embbeded in the project it self in several readmes spread across the project, that gather the vital information about a particular section of code or HAL. This is updated as need for each version and provides correct documentation for each version release.

HAL, tools, modules and all extra-core stuff

With the current code implementation modular approach, it's possible to move all HAL/module specific code to the specialized compilation unit and keeping it completely separated from generic core code.

As an example, each kinematic can (and should) not only implement the required kinematic.h template functions but also take care of implementing all custom settings (if needed) using the settings module API, system menu entries, custom G/M codes, etc...

For example all delta and linear delta kinematics, settings, system menus, etc... be implemented inside the respective kinematic compilation unit, instead of being spread around multiple files.

Tools can take advantage of this also.

Code will be gradually migrated to this model and future code will/should be implemented using these design rules.

There will always be some definition dependencies that might need to be added to the config helper (like enable some extension module or core feature).

Performance penalty should be minimal/neglegtable since the modules API is lightweight. The output bin should increase slighlty but that will only make some difference to UNO since the Flash capacity is at it's limits.

This further reinforces code modularity and flexibility. Core code will become easier to read.

@Paciente8159 Paciente8159 added the roadmap roadmap label Aug 3, 2023
@Paciente8159 Paciente8159 pinned this issue Aug 3, 2023
@Paciente8159 Paciente8159 added the documentation Improvements or additions to documentation label Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation roadmap roadmap
Projects
None yet
Development

No branches or pull requests

1 participant