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
[This issue contains a draft of an RFC. It is not actionable yet and is published only to promote discussion.]
The existing pin management system is extremely ugly and hard to use and should go. (This is the long-term maintainability goal number 4 from #234). At some point I thought this would be possible to address with a complete rewrite of our argument parsing system but at this point this is clearly infeasible and a more iterative approach is needed.
The requirements for a pin management system are:
Is declarative (with an additional imperative validation layer; answering the question of "is this pin config valid?" but not "which pin config do these options result in?");
Is based on Python code (at least for the time being, so far as we continue to allow implementing an applet as a single Python file);
Is built to integrate with Amaranth components from the lib.wiring library;
Allows the use of complex I/O buffering schemes (with clocked buffers, including tristate clocked buffers) while not requiring undue boilerplate for simple ones ("just give me this pin as an input/output/tristate");
Namespaced, allowing multiple applets to share pins without fear of name conflicts (for cases such as multiple simultaneous applets, or a single applet instantiating two SPI interfaces in parallel);
Composable and/or extensible, allowing an applet to instantiate another applet's subtarget with additional sideband pins (by far most common case of this being "SPI plus a bunch of other signals"), with minimal or no boilerplate requierd to hook up these sideband pins to the subtarget;
Introspectable, allowing to render the pin configuration as JSON or human readable text;
(Covered by the above goals, but an explicit goal in itself:) Possible to eventually use from a GUI configuration tool;
For the time being still relying on our existing argparse-based infrastructure.
[To be continued in the future.]
The text was updated successfully, but these errors were encountered:
(The issue is locked to allow edits by @GlasgowEmbedded/maintainers only, for the time being. It will be unlocked once the draft is finished. Feel free to discuss it on chat!)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
[This issue contains a draft of an RFC. It is not actionable yet and is published only to promote discussion.]
The existing pin management system is extremely ugly and hard to use and should go. (This is the long-term maintainability goal number 4 from #234). At some point I thought this would be possible to address with a complete rewrite of our argument parsing system but at this point this is clearly infeasible and a more iterative approach is needed.
The requirements for a pin management system are:
lib.wiring
library;argparse
-based infrastructure.[To be continued in the future.]
The text was updated successfully, but these errors were encountered: