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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: