Release 0.2.0 - #5
Merged
Merged
Conversation
Adds `eeprom-write`/`eeprom-read` and the wire commands behind them, so a feature release rather than a patch. Nothing this project treats as breaking moved: no existing command byte, header layout, chunk framing or error code changed -- 9 and 10 and the new error codes take unused numbers -- no subcommand or flag was renamed or made required, the load addresses are the same, and both MSRVs stay where they were. The handshake's protocol version does go to 2, in both halves, which is a bump for an addition the version byte cannot express as one. It earns it by naming the mismatch this project actually produces: the loader is flashed once and left on the card for months while the CLI is reinstalled from crates.io whenever, so a newer CLI meeting an older loader is ordinary. Before, `eeprom-write` against a 0.1.0 loader returned `error code 0` -- an unknown command byte answered with `FAIL`, then its arguments read as further commands -- which reads as a fault on the I2C bus rather than a stale image on the card. Now the handshake says so first, and still only warns, so an older CLI keeps driving a newer loader for everything they share. Covered by a test, since the bump is worth nothing if the warning does not appear: the fake device claims one version behind, and the CLI has to both name it and carry the command through.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds
eeprom-write/eeprom-readand the wire commands behind them, so a feature release rather than a patch. Nothing this project treats as breaking moved: no existing command byte, header layout, chunk framing or error code changed -- 9 and 10 and the new error codes take unused numbers -- no subcommand or flag was renamed or made required, the load addresses are the same, and both MSRVs stay where they were.The handshake's protocol version does go to 2, in both halves, which is a bump for an addition the version byte cannot express as one. It earns it by naming the mismatch this project actually produces: the loader is flashed once and left on the card for months while the CLI is reinstalled from crates.io whenever, so a newer CLI meeting an older loader is ordinary. Before,
eeprom-writeagainst a 0.1.0 loader returnederror code 0-- an unknown command byte answered withFAIL, then its arguments read as further commands -- which reads as a fault on the I2C bus rather than a stale image on the card. Now the handshake says so first, and still only warns, so an older CLI keeps driving a newer loader for everything they share.Covered by a test, since the bump is worth nothing if the warning does not appear: the fake device claims one version behind, and the CLI has to both name it and carry the command through.