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

Refactor the memory sub system #636

Closed
krichardsson opened this issue Oct 26, 2020 · 0 comments
Closed

Refactor the memory sub system #636

krichardsson opened this issue Oct 26, 2020 · 0 comments
Milestone

Comments

@krichardsson
Copy link
Contributor

The current implementation of the memory module has dependencies to all modules that has memory read or write functionality. A better design would be to move the read/write implementations out to the modules them selfs and add functionality in the memory module to register handlers. This would break the dependencies from the memory module.

krichardsson added a commit that referenced this issue Oct 27, 2020
Moved memory handling into the modules that own the data. Memory handling is registered by modules in the mem.c module during init instead.
Important changes include:
* Memory handling related to decks (LED ring colors for instance) are only available when the deck is mounted
* There is a limited number of handlers (20) that can be registered, an assert will fail if too many handlers are registered. 20 should be enough for a foreseeable future.
* The LOCO memory type is no longer available. LOCO was superseded by LOCO2 and is not used by the client anymore.
@krichardsson krichardsson added this to the next-release milestone Oct 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant