LCDproc development and user support list

Text archives Help


[Lcdproc] Noritake-Itron GU600 series driver


Chronological Thread 
  • From: bsdfan at nurfuerspam.de (Markus Dolze)
  • Subject: [Lcdproc] Noritake-Itron GU600 series driver
  • Date: Wed, 15 Dec 2010 21:25:49 +0100

Hi Peter,

nice work. A few comments / questions I do have:

* Please have a look at
http://lcdproc.sourceforge.net/docs/current-dev.html#code-style.
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.
* 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.
* 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.
* I wonder if there is any advantage / disadvantage of using 'enums'
instead of #define in NoritakeGU600.h despite it groups things nicely.

Regards,
Markus


On 14.12.2010 17:14, Peter Wurmsdobler wrote:
> Hello,
>
> Over the past few days I finally got around to implement a driver for
> my Noritake-Itron VFD, model GU240x64D-K612A8-F2-f7. From Noritake's
> technical support I have learned that Noritake-Itron range exposes 5
> command interfaces:
>
> - GU 600 series, the products ending in A4/A7/A8.
> - GW 600 series, small displays
> - GU 7806A series, the LCD compatible range.
> - CU KTW series, the character range.
> - Message signs.
>
> My GU240x64D-K612A8-F2-f7 is in the first category, which was the
> reason for calling my driver NoritakeGU600. I went through the manual
> and decided to cut the lcdproc driver in three pieces
> (http://www.wurmsdobler.org/files/NoritakeGU600.patch):
>
> 1. NoritakeGU600.c|h
> the "application-independent" low level code that translates
> meaningful commands into a sequence of bytes defined by the protocol.
> The result is more or less the technical manual converted into C code,
> which could be used with little modification in any system, embedded,
> Linux, Windows, etc. This is something Noritake could maintain.
>
> 2. NoritakeGU600lcd.c|h
> This is the glue code that implements the LCD proc character oriented
> interface and translates it into protocol independent calls of the
> underlying NoritakeGU600_* functions.
> Note that this implementation does not bother going beyond normal
> characters (no v and h bars, etc); should I need them, then I would go
> through the serialdisp meta driver once available.
> (I considered using the graphlcd metadriver for a while, but going to
> C++ via an adapter and back to C sounds a bit strange. I would prefer
> the whole thing in C++ though).
>
> 3. serialport.c|h
> I found it worthwhile to "factor out" the serial port into its own
> module. Going through the existing drivers I found that all serial
> devices seem to implement the same functionality. Perhaps other people
> might find it useful to use an instance of this serial port in the
> private data rather than copying code across.
>
> Consequently, anybody can use the NoritakeGU600.c|h in another
> "applicaton", be it embedded or an alternative to LCDproc, potentially
> with a slightly different serialport implementation.
>
> Having said that, I consider integrating the NoritakeGU600.c|h into
> the serialdisp project, too, potentially requiring another piece of
> glue code, e.g. NoritakeGU600sdisp.c|h . Then all the graphical
> abilities of the GU series can be exploited.
>
> LCDd with the Noritake driver works fine for me with XBMC, even though
> now and again the LCDproc system information is shown, "#LCDproc
> Server ####" ... I did not find why that is, perhaps LCDd does not get
> fed enough data from XBMC, or the connection breaks. Any ideas?
>
> I am looking forward to receiving some feedback.
>
> Kind regards,
> peter
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.omnipotent.net/pipermail/lcdproc/attachments/20101215/7e9e8982/attachment.htm>




Archive powered by MHonArc 2.6.18.

Top of page