[ECOS] Alphanumeric LCD driver

Steven Clugston steven.clugston@newcastle.ac.uk
Wed Oct 28 22:25:00 GMT 2009


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



More information about the Ecos-discuss mailing list