This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Alphanumeric LCD driver


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]