Stop reporting a finished charge as an ongoing one on the IP5306 - #337
Merged
Conversation
The register document describes two flags for this part: REG_READ0 bit3 to tell charging from discharging, and REG_READ1 bit3 to tell whether the cell has already been filled. Only the first was read. It stays set once charging is enabled and a supply is present - the completed charge included - so a finished charge was reported as an ongoing one, and so was a board running with no cell installed. Read both. They sit at adjacent addresses, but the document only ever shows a single-byte read and never states that the address auto-increments, so they are read separately rather than resting on unspecified behaviour. Measured on a Core BASIC v2.7 across every branch: supply removed (70=16 -> false), charging (70=19 71=70 -> true), charge disabled (70=11 -> false), and charge complete (71=A8 -> false, where the earlier form stayed true). Behaviour change: isCharging() now returns false once the cell is full, where it used to stay true for as long as a supply was present. Callers that watched for the transition as a sign that external power was lost will see it at full charge instead; the library has no way to express "full" through this return type yet.
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
2 participants
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.
M5.Power.isCharging()returns true on M5Stack Basic / GRAY / GO / FIRE whenever charging is enabled and a supply is present - including after the cell is already full, and on a board running with no cell installed.The register document for this part describes two flags:
REG_READ0bit3 tells charging from discharging, andREG_READ1bit3 tells whether the cell has already been filled. Only the first was read, and that one stays set once charging is enabled, so a completed charge kept reading as an ongoing one.This reads both.
Measured on a Core BASIC v2.7, all four cases
16001970110019A8Behaviour change
isCharging()now returns false once the cell is full, where it used to stay true for as long as a supply was present. Callers that watched for that transition as a sign that external power was lost will see it at full charge instead. The library has no way to express "full" through this return type yet.Notes
The two registers sit at adjacent addresses but are read separately on purpose - the register document only ever shows a single-byte read and never states that the address auto-increments.
Known limits, unchanged by this PR: the full flag has no defined reset value, so shortly after power-up it can read as full before the charger has settled; and a failed read is reported the same way as "not charging", because the return type has no room to say the question could not be answered.