[ECOS] Alphanumeric LCD driver

[ECOS] Alphanumeric LCD driver

[Steven Clugston]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

Hi all.

I've got some code to offer for discussion/comments.

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.

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.

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?

Regards,

Steven

[-- Attachment #2: alphanumlcd.tar.gz --]
[-- Type: application/x-gzip, Size: 5229 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Alphanumeric LCD driver

[Sergei Gavrikov]

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

RE: [ECOS] Alphanumeric LCD driver

[Steven Clugston]

Hi Sergei

Thanks for your comments.

>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/powerp
c/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.

Ok so you gone a bit further with it than me already!
It seem that there are now three implementations which are all still board specific, probably more in peoples private repos.
I know these screen drivers are relatively trivial, but it seems silly to have to reimplement it for each new board.

My approach was to try and formalise it into a standard driver rather than have it as a low level a set platform diagnostic routines.
I was thinking more about how it could be used by an application as a character driver with cyg_io_set_config keys to control specific things that perculiar to an lcd screen. I thought any terminal emulation could then be done in a higher layer such as a pdcurses driver.

I would like to think that in future I could buy any board with some spare gpio and hook up an LCD screen then just have to supply either a few macros or a routine like the i2C bitbang hal_platform_i2c_bitbang(..) one in order to get it working.

>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.

Sorry Sergei, I was a bit confused at first by what you ment by this, but I think I understand now. The generic part provides devs level common interface which will just call the relevant funs in the hd44780 (or other) controller specific part. Is it necessary to layer it this much?

The devs/lcd/arm/sam7ex256 bit I think I would prefare just some entries in the platform hal or in the actual application (as per the bitbang I2C), otherwise there would need to be a driver file (and cdl) for each board that uses it.

>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?

Yes, or maybe more just:
ecosconfig new sam7ex256
ecosconfig add lcd devs_lcd_hd44780

And then let the compilation fail at the link stage if the plaform specific routine/macros aren't in place somewhere either in hal or the final application.

>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.

That's what I had in mind. The pdcurses driver can then just call the corresponding key with cyg_io_set_config() to control the cursor position/visability or whatever terminal type attirbutes can be exploited.

The question is which of these are common to various types of LCD screen, I've only used the 2x16 HD44780 type todate but there must be others that are more sophisticted and let you invert the colours and other stuff besides.

>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

I think I've looked at this before. Do you think it is necessary or useful to add this VT53 emulation?
The pdcurses driver could do the same without needing to emulate all of the control codes.

>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.

I'm awaiting comments :)

Any ideas how to take this forwards (maybe consolidate it with what you've already done) before I have to move on from it or put it back on a low flame?

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

Re: [ECOS] Alphanumeric LCD driver

[Sergei Gavrikov]

Steven Clugston wrote:

[snip]

> It seem that there are now three implementations which are all still
> board specific, probably more in peoples private repos.  I know
> these screen drivers are relatively trivial, but it seems silly to
> have to reimplement it for each new board.
>
> My approach was to try and formalise it into a standard driver
> rather than have it as a low level a set platform diagnostic
> routines.  I was thinking more about how it could be used by an
> application as a character driver with cyg_io_set_config keys to
> control specific things that perculiar to an lcd screen. 

Certainly, I agree that would not bad to have abstract generic layers
for other devices for an interaction with a human like io/lcd, io/kbd,
etc. Although there are a few target-depended I/O layer under `devs',
for example, two keyboard (keypad) drivers in the eCos repository. So,
those drivers just "inherit" io, fileio packages and not absent io/kbd
and may be I was wrong with such an extra-layering, but, read the
below. 

> I thought any terminal emulation could then be done in a higher
> layer such as a pdcurses driver.
Sure.
> I would like to think that in future I could buy any board with some
> spare gpio and hook up an LCD screen then just have to supply either
> a few macros or a routine like the i2C bitbang
> hal_platform_i2c_bitbang(..) one in order to get it working.
[snip]
... and in this case those i2c/spi keyboards, lcd screens, touchpads
would use the absent abstract generic layers from io/*. Therefore,
both the design flows may exist.

> I think I understand now. The generic part provides devs level
> common interface which will just call the relevant funs in the
> hd44780 (or other) controller specific part. Is it necessary to
> layer it this much?

[snip]

That is a question :-) If we both in a doubt I can guess that two of
the design flows can be used. That is e_C_OS.

> Yes, or maybe more just:

> ecosconfig new sam7ex256
> ecosconfig add lcd devs_lcd_hd44780
> 
> And then let the compilation fail at the link stage if the plaform
> specific routine/macros aren't in place somewhere either in hal or
> the final application.

No compile time. Lets CDLs work.

For example, some CYGPK_DEVS_LCD_HITACHI_HD44780 may claim some interface
implementation, e.g. interface CYGINT_IO_LCD_DRIVER and your target must
implement such a thing, well, no bloat coding and it can just implement
a claimed 'init' function for that HD44780 device driver (package).

[snip]

> The question is which of these are common to various types of LCD
> screen, I've only used the 2x16 HD44780 type todate but there must
> be others that are more sophisticted and let you invert the colours
> and other stuff besides.

Steven, IMO, at the beginning your driver can quite live under entry
devs/lcd/arm/sam7ex256 and inherit some of generic IO package(s).

> >Steven, I found this just now.  Look, please (I liked those echos
> >for Linux) via... /dev/lcd: http://lcd-mod.sourceforge.net/
> 
> I think I've looked at this before. Do you think it is necessary or
> useful to add this VT53 emulation?  The pdcurses driver could do the
> same without needing to emulate all of the control codes.

No, I did not, I sent that for example only. The PDCurses can do it as
well.
 
> I'm awaiting comments :)
> 
> Any ideas how to take this forwards (maybe consolidate it with what
> you've already done) before I have to move on from it or put it back
> on a low flame?

It seemed for me that I do not answer on your questions. The questions
did not go away, I tried to say that both design flows can exist. And
it seems for me what to design any generic io package is more
difficult task than to design any private driver. All generic layers
are small in the lines but they are strong in the thoughts :-)

Just to know I cloned the first revision of eCos in /tmp and looked on
that tree. The `io' stuff was not born yet, there were a few types of
the devices under `devs' entry. I've got a conclusion: all went from
`devs' to `io', from private things to common ones. But both up/down
design streams may exist today. What a direction will you choose?

Regards,
Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss