LCDproc development and user support list

Text archives Help

[Lcdproc] Non-Latin characters in LCDd.conf

Chronological Thread 
  • From: ethan.dicks at (Ethan Dicks)
  • Subject: [Lcdproc] Non-Latin characters in LCDd.conf
  • Date: Sat, 29 Nov 2008 04:53:00 +1300

On Sat, Nov 29, 2008 at 4:27 AM, Dave Liquorice <allsorts at>
> On Fri, 28 Nov 2008 15:44:17 +0100, hansfong at wrote:
>> Now my question is: how do you know what characters are in the ROM and how
>> to address them?
> Normal place to look would be the displays data sheet from the manufacturer.

That's always the definitive answer, but I don't know how easy it is
to open up the picoLCD 20x4 to verify what display is used underneath.
Plus, as I mentioned previously, sometimes the vendor changes
types/brands of LCD display thinking it won't matter, but it does.

> Failing that, write a client that just sends each character code to the
> display, prehaps prefixed with that code. Be warned that unexpected things
> may happen, <tab>, <lf>, <cr> etc... Also it's probably not wise to send the
> <esc> character as that may put the display into command mode rather than
> display. Forgive me if we are talking a purely graphical display rather than
> one with a "text" mode, I've only half been following the thread.

There are two mingled threads here - the first was about how a client
would be able to display strings of Greek chars, but the most recent
question is about where glyphs like a degree symbol could be found in
a ROM font of a textual display.

In general, I agree with the technique you describe - but I think it's
"safe" for an LCDproc client to send random (i.e. - "non-printing")
chars to the server because the server should escape any unsafe chars
(for example, a backslash for a jw002, or an 0xFE for a Matrix Orbital
display). If you happen to have a parallel-attached display, then no
chars are "unsafe" since it's a raw display, not one that's trying to
interpret a serial data stream and emulate a terminal (as many serial
display to try to do). When directly writing to an LCD without
LCDproc, it _is_ important to avoid chars that might be interpreted as
commands. You pretty much have to hit the manual for your exact
display to learn what can and cannot be sent directly to that display.
Every vendor command set is different - there are no standards (but
the ones you mentioned are commonly a problem).

I did run across a bug recently, with the picoLCD 20x2 driver, IIRC,
where it was not possible to send a 0x00 character from the server to
the display. I traced the flow down into the underlying USB library
and lost track of things somewhere deep, but some bit of code was
given a byte count and a string, but still ended the string at the
zero byte. The problem with this is that the HD44780 uses chars 0x00
- 0x07 for user-definable chars, and this bug broke "bignum" mode.
Yes... thinking back it _was_ the picoLCD 2x20 driver, because I was
trying to debug that a few months ago. Unfortunately, since the
display itself, not the microcontroller on the picoLCD, defines what
soft-chars are, it's not possible to shift things around. Thinking
about it now, it _might_ be possible to send a 0x08 in place of a
0x00, but I'm not sure without trying it if that display has echoed
softchars at 0x08-0x0F or not. Certainly if it worked, it would be an
easy fix.

As for displaying one char at a time, I've found it more useful to
display 16 chars at a time... perhaps like this...

60 `abcdefghijklmno
70 pqrstuvwxyz{|}~

... etc

then you can fire up the client, let it write 2 or 4 lines of those
(depending on your display geometry), and either have it page through
the char set slowly, or just tell it at start which lines to display
and hold forever.

I know I wrote a client to do this once, but it's not very complex and
wouldn't take long to write one from scratch.


Archive powered by MHonArc 2.6.18.

Top of page