LCDproc development and user support list

Text archives Help

[Lcdproc] Noritake-Itron GU600 series driver

Chronological Thread 
  • From: peter at (Peter Wurmsdobler)
  • Subject: [Lcdproc] Noritake-Itron GU600 series driver
  • Date: Wed, 15 Dec 2010 21:59:38 +0000

Hello Markus, many thanks for your feedback.

> * Please have a look at
> Yo don't need to rewrite your code as 'indent' will take care of
> this. However, C++ style comments need be removed before I can
> pass it through indent.
Habits. An improved patch should be on

> * Do you now about the CU200/400 series? Any change to integrate it?
> Otherwise we will have a third Noritake driver, leading to the
> question why.
You are right, not only are there several modules, but also they do not
differ that much. Most is repetitive code.
It must be said that my NoritakeGU600lcd lcdproc-GU600 glue code only
exploits a small fraction of the NoritakeGU600 capabilities. I could
imagine a single Module inking in some form:

NoritakeLCD.c|h module entry point
NoritakeGU600.c|h, NoritakeCUx00.c|h, NoritakeXYZ.c|h: specific drivers

where the NoritakeLCD driver chooses depending on the Family/Model which
low level calls to make to actually draw a string or to set the brightness.

As a matter of fact, most drivers use double buffering of strings,
eventually making only a couple of low level calls to the hardware,
namely in flush and to set brightness.

The difference is certainly on how to deal with v|hbars and special
characters. The latter I have not quite understood how it is supposed to
work. Does it use non-printable ASCII character codes to encode special

> * The serialport thing is nice. I thought of something similar
> already. However, to be useful as a general part I would love to
> have it an 'allowed port speed' setting. A driver should be able
> to pass a list (maybe an array of int) to the initialization
> routine so it may check if the port selected is supported by the
> device.
Yes, I sort of can imagine that, a serialport_create() could for
instance take an argument, or several.
It would be nice to "factor out" the serial port of all drivers; there
is a lot of repetition. Even better, if there was an abstract commsport,
which implements create/free/open/close/read/write for say serial or
parallel, then it would even be better.

> * I wonder if there is any advantage / disadvantage of using 'enums'
> instead of #define in NoritakeGU600.h despite it groups things nicely.
Well, in my dayjob I try to keep things as strictly typed as possbible.
First, it forces the user of a function to be specific; no freedom on
function arguments or the compiler complains (we count warnings as
errors). Second, it relieves the function itself from boundary checking.

I have informed technical support at Noritake of this driver and hope
for some feedback or contribution; it is after all in their interest. I
would hope that Noritake verifies and maintains the low level bits.

For me lcdproc works fine with XBMC, with the exception of the fact that
every 5 seconds, the lcdproc system message appears. I tried to mitigate
this by setting the waittime very big.

Kind regards,

Archive powered by MHonArc 2.6.18.

Top of page