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

writeDataRaw() & writeDigitAscii() descriptions are incorrect & incomplete #70

Open
ricknun opened this issue Mar 16, 2022 · 3 comments · May be fixed by #75
Open

writeDataRaw() & writeDigitAscii() descriptions are incorrect & incomplete #70

ricknun opened this issue Mar 16, 2022 · 3 comments · May be fixed by #75

Comments

@ricknun
Copy link

ricknun commented Mar 16, 2022

http://adafruit.github.io/Adafruit_LED_Backpack/html/class_adafruit__7segment.html
says writeDigitRaw() parameter x is "Character position (0-3)." It is 0-4 with character position 2 being the ":" in the display. It would also be helpful to explain that both LEDs in the display ":" (I expected them to be individually controlled) are controlled by bit1 of the bitmask parameter (I expected bit0) and all other bitmask bits are ignored.

Similarly it says writeDigitAscii() parameter x is "Character position" and nothing more. It is also 0 to 4 with character 2 being the ":" in the display. It is unclear what to expect when writing an ASCII character with "dot" true or false to the display ":" (I didn't try it.) It seems like this is an coding error that now should just be clearly documented and supported. The function interface would have been better written as character positions 0 to 3 and nothing to do with the ":" in the display.

I'm not sure if those are the only errors on that page, but encourage someone that understands the code better to proofread the Doxygen documentation -- It is the first place I go when trying to understand libraries. And many thanks for the libraries -- They are very useful and valuable.

@SleepySpaceBear
Copy link

I'm about to make a fork then PR to fix the source code so the behavior matches the documentation in the header file.

@ricknun
Copy link
Author

ricknun commented Oct 20, 2023

SleepySpaceBear: I hope you don't change the behavior of the code in any way that makes my (and others') using source code have to change -- no backward incompatibilities. I meant to suggest the documentation change to agree with what the code is already doing, not the other way around.

@SleepySpaceBear
Copy link

SleepySpaceBear commented Oct 20, 2023

I'm doing both as separate PRs and letting the maintainers choose.
Edit see #74 and #75

@SleepySpaceBear SleepySpaceBear linked a pull request Oct 20, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants