[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