Custom Characters #55
Conversation
Interesting. It might make sense to see how other implementations in other languages like C handle this in their libraries? |
|
I actually haven't looked at other implementations until now. It appears that the status includes the current DDRAM address. I would combine this PR with adding status fetching in that case, which would eliminate two problems at once. Though, this would first require implementing reading from the bus, which should be a separate PR. |
ColinTimBarndt
force-pushed
the
feature/custom-characters
branch
from
ec34e2b
to
d5e98f9
Compare
ColinTimBarndt
force-pushed
the
feature/custom-characters
branch
from
d5e98f9
to
99152cc
Compare
|
I have tried to use this with my LCD1602, and it did not work like expected. The code also looks differently to the one specified here: https://github.com/mjhouse/ag-lcd/blob/24389f4e69de5f7d332504d70b9fc64d3301b668/src/display.rs#L752 which worked for me. |
|
Can you please explain what happened that was not expected? |
|
It was just another character than expected I think. I'd need to add back the old code to reproduce it.. I'm just wondering about the differences between this implementation and the ag-lcd one. I have since solved the issue differently, when looking up things in the datasheet, I saw that ° is actually part of the available characters in the driver peripheral. |
This pull request allows defining custom characters. Closes #8.
This branch is currently based on #54 just for convenience, but I can rebase it onto the current version as it doesn't touch anything changed in that PR.
The current implementation has the drawback that it will reset the cursor position. This is required to change the writing mode from CHRAM back to DDRAM and we are currently not keeping track of the cursor position.
It would be nice to have a second opinion on this. Should we keep track of the cursor or just accept resetting the position?