PathogenDavid
commented
2 months ago This example specification is a clone of harp-tech#44 just to show how the issue form slightly affects formatting.
The changes are minor, but here they are:
- The proposal status has a heading. This can't really be avoided unfortunately.
- IMO GitHub needs the ability to embed arbitrary markdown in the issue for stuff like this anyway, it's annoying that it shows up on the issue form.
- You can avoid the heading by replacing it with a zero-width space (the heading is required but GitHub doesn't recognize the zwsp), but it looks weird.
- See https://github.com/PathogenGymnasium/HarpProtocol/issues/2
- The headings are all level 3 headings for some reason
- (Pet peeve of mine but some people hate big text and I guess one of them works at GitHub)
- "No response" showing up for sections with no response
- Maybe slightly annoying for these sections in particular as they don't always start with content.
- You can make them mostly empty with a zero-width space again, looks like this: https://github.com/PathogenGymnasium/HarpProtocol/issues/3
- You can also use HTML comments (basically like the old issue template), but then there's noise in the submission form instead https://github.com/PathogenGymnasium/HarpProtocol/issues/4
Proposal status
Summary
Deprecate the current way to store information regarding the version of hardware, firmware and core in favor of a single register.
Motivation
The current registers 01-07 are used to version hardware, application firmware and harp core. We are moving into a direction where we will additionally need to keep track of the protocol spec as the harp core and its implementation will now diverge given how we support two parallel core hardware implementations (rp2040 and atmega). Since we need to add a new register, I propose we start deprecating the current ones in favor of a single register that stores all this information.
Detailed Design
Deprecate all current registers and add a new one with the following specs:
Register: Name: Version Type: U8 Access: Read Length: 15 PayloadSpec: HarpProtocol[Major, minor, patch], CoreImplementation[Major, minor, patch], App[Major, minor, patch], Hardware[Major, minor, patch], Assembly[Major, minor, patch].
This has a huge benefit of all versions now being able to be read out with a single call.
Finally, until the deprecated registers are removed from the spec, the available information should be duplicated (in this case only Major and Minor versions)
Drawbacks
No real drawback as we will need to add a register anyway.
Alternatives
Adding a new register with the harp protocol version and keep all others as is.
Unresolved Questions
No response
Design Meetings
No response