(2013-01-20, 17:15)herrnst Wrote: (2013-01-19, 20:25)Elf1sh Wrote: I'm using the following display:
http://playground.arduino.cc/Main/M204SD01B
The arduino lib is emulation a CFontz-Display.
So i'm using the CFontz-Driver in lcdproc.
The arduino program provides a internal way to remap characters that lcdproc tells it to display.
I just remapped the y with two dots to a full block.
Would be interesting to know if this works without changes for CFontz-displays that don't need a wrapper (maybe someone can comment on this?). I somehow suspect the wrapper being the culprit if it works on other CFontz-driven displays. If they also cause trouble, the problem rather is in the CFontz driver (as said, there's numerous hardware where the progress bar pseudolabel works without problems).
Mind to share what you've done in detail to fix the problem, so I can put instructions or even patches on the repo's Wiki page?
Regards,
nst
The display used by the arduino wrapper uses the following char map.
Source
According to the comments in CFontz.c (lcdproc source code), the driver works for 632 and 634 crystalfontz displays.
The following char map can be found in the documentation.
Source
I disabled all re-mapping in that arduino display wrapper. So the chars (char codes) should be 1:1 that should be used in regular CFontz displays.
When the progress bar lcdproc widget tried to display a full block it displayed a y with two dots, meaning it tried to display 0xFF.
If you lookup that char code in cfa634 char map it results in }.
So the full block displayed on a real CFontz display should be wrong aswell.
In the lcdproc source code a CFontz-charmap.h can be found.
How ever as far is unterstood the source:
Code:
if ((x >= 0) && (y >= 0) && (x < p->width) && (y < p->height))
p->framebuf[(y * p->width) + x] = (p->newfirmware)
? CFontz_charmap[(unsigned) c]
: c;
that char map should only take effect if you use the newfirmware setting in the lcd.conf (which i set to no, so i shouldn't use any addional charmap in lcdproc).
as i already said, there is a remapper function in that arduino wrapper.
i simply made it use a different char once it's told to display 0xFF, resulting in the correct char shown.