This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Alphanumeric LCD driver
- From: Sergei Gavrikov <sergei dot gavrikov at gmail dot com>
- To: Steven Clugston <steven dot clugston at newcastle dot ac dot uk>
- Cc: "ecos-discuss at ecos dot sourceware dot org" <ecos-discuss at ecos dot sourceware dot org>
- Date: Tue, 27 Oct 2009 23:58:56 +0200
- Subject: Re: [ECOS] Alphanumeric LCD driver
- References: <4DCF6DBD3535F742BB167C528BBEE9803828B88A30@EXSAN01.campus.ncl.ac.uk>
On Tue, Oct 27, 2009 at 12:20:09PM +0000, Steven Clugston wrote:
> Hi all.
>
> I've got some code to offer for discussion/comments.
Hi Steven,
> I've written a simple bit-bash style LCD driver for those very
> common 2-line LCDs that use the Hitachi 4 or 8-bit HD44780 protocol.
> I created an IO layer so that other types such as SPI, I2C, USB
> might be added at a later stage.
> I've been using this code with an Olimex SAM7MT256 board which comes
> with one of these screens already soldered on it. I think they also
> do an almost identical board which uses an LPC2xxx chip instead of
> an AT91.
>
> Anyway, the code works as it stands with the above board, but I need
> to add some macros in a similar way to the I2C bit bang bus so that
> the HAL or application can define which IO lines are used for the
> LCD data and control lines.
>
> The end goal for me is to be able to use a pdcurses wrapper driver
> with it so that the management of the screen's contents is improved
> by creating virtual pages which can be cycled through for example.
> It might seem like overkill and a major code bloat for a 2-line
> screen I suppose, but it could be extended for larger screens at
> some point in the future. I've started to write the pdcurses driver
> and tested it and it seems to work in a standalone application, but
> I've not included it yet as it need more cleanup and testing.
Why not? IMHO, for _some_ eCos targets PDCurses are not bloat.
> I think LCD screens can be a useful debugging/tracing tool when all
> serial ports are taken or where there are none in the first place.
> They are a step better than just flashing a LED anyway.
Agreed. Two examples.
There is implementation eCos vectored virtual channel (VV) on FEMA
162B 16x2 LCD in powerpc/cogent HAL
http://hg-pub.ecoscentric.com/ecos/file/tip/packages/hal/powerpc/cogent/current/src/hal_diag.c#l442
When I "found" it, I did embed the same for my Olimex LPC22x4 targets
(some of those boards use HD44780 IC)
http://bitbucket.org/tickling/olpcx22xx/src/tip/hal/arm/lpc2xxx/olpcx22xx/common/current/src/lcd_driver.c
Well, at the least I know that RedBoot is started just looking on LCD.
I even thought that LCD would be not a bad diagnostic channel for
OpenOCD JTAG, well, w/out a layering and just to out a few nibbles on
LCD controller. With minimal LCD init in RAM and a few GDB macros it
would be possible "to cry" something.
> Before I send any more time on it, is anybody else interested in
> this and would it eventually acceptable for CVS?
>
> Are there any comments/suggestions particularly with regard to the
> IO layer generality?
My look on LCD layering in a picture (although, may be that is odd, I
like VVs on LCD, but not all targets can use ROM monitor)
SYNOPSYS
io/lcd ;# less than framebuffer...
devs/lcd/generic ;# write, config (pos, etc.)
devs/lcd/hitachi/hd44780 ;# hwr funs implementation
devs/lcd/arm/sam7ex256 ;# inline target's privates
...
This controller http://en.wikipedia.org/wiki/HD44780_Character_LCD in
fact is IC controlled via 4/8-bit parallel bus with some lines
(=features). It seems for me that devs/lcd/hitachi/hd44780 must have
all set of functions to use all features, but generic device driver
(devs/lcd/generic) can have a few. Well, Steven that is just my view.
As I could understand you thought about /dev/lcd like about character
device, that /dev/haldiag:
ecosconfig new sam7ex256
ecosconfig add lcd devs_lcd_arm_sam7ex256
...
Is it right?
I this case /dev/haldiag (=/dev/lcd) is almost to ready for PDCurses
like w-only serial driver. Well, may be I missed something from your
idea, then correct me.
Steven, I found this just now. Look, please (I liked those echos for
Linux) via... /dev/lcd:
http://lcd-mod.sourceforge.net/
http://lcd-mod.sourceforge.net/faq.php
Really, Why not to have own choir for eCos? But it seems for me that
LCD "layering" must be discussed more detailed to get more opinions
about all pros/cons on implementation.
Regards,
Sergei
> Regards,
>
> Steven
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss