Add getPixel and fix compile error in glcdfont.c
This pull request contains two modifications:
-
Add a getPixel method to both HT1632 and HT1632LEDMatrix to enable reading back the currently set pixel values. The pixel index calculation logic was extracted from drawPixel so it could be shared. I needed this to implement Conway's Game Of Life. (See https://github.com/jraymakers/gameOfLife.)
-
Fix a compile error in glcdfont.c caused by a missing "const". Without this, I get the following error:
/Users/jeff/Documents/Arduino/libraries/HT1632/glcdfont.c:9:23: error: variable 'font' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
static unsigned char font[] PROGMEM = {
^
Error compiling.
Both changes have been tested with an Arduino Uno R3 and a (single) HT1632C 16x24 LED matrix using the above gameOfLife sketch.
I am getting the same error message:
Build options changed, rebuilding all gameOfLife.ino: In function 'void loop()': gameOfLife.ino:84:25: error: 'class HT1632LEDMatrix' has no member named 'getPixel' gameOfLife.ino:85:25: error: 'class HT1632LEDMatrix' has no member named 'getPixel'
Let me know if this gets fixed.
@stadham It looks like you're trying to build gameOfLife.ino using the unmodified HT1632 library (without my changes). That won't work, because gameOfLife.ino depends on the changes in this pull request, which hasn't been merged into adafruit/HT1632. It should build correctly if you use jraymakers/HT1632 instead.
I got it!! thanks and it looks great I have been looking for this for about a year now. Thanks so much for the code. Well Done.
Glad to hear it!
Thanks for your work here @jraymakers :smile:
I split out the const fix into #9 to isolate this change. Can I suggest creating a separate issue for adding the getPixel method? The project maintainers might have an opinion on whether and how to implement it.
Since the const fix is only one line, I'm not sure it's worth creating an additional pull request. No one's responded to this pull request in over half a year anyway, so I don't have much hope of it being merged.
@jraymakers maintainers can more readily merge a change when it is atomic, so creating a separate PR that is easier to merge gets us one step further :smile: I'll ping maintainers in my PR.
If the maintainers take your PR (indicating that this project is actually being maintained), then I'll gladly fix up mine.
thanks bro :+1: