Re: dot matrix display infrastructure

[Sergei Gavrikov <sergei dot gavrikov at gmail dot com>]

Hi,

On Sat, 14 Jan 2012, Ilija Kocho wrote:

> On 11.01.2012 16:41, Tomas Frydrych wrote:
> > Hi,
> > 
> > I am working on a driver for the Freescale Kwikstik LCD, which is a
> > segment lcd organized as a dot matrix. As part of that, I have
> > prototyped a simple system for drawing text, consisting of a couple of
> > minimal bitmapped fonts, a simple font generation tool, and a
> > rudimentary API.
> > 
> > I am wondering whether rather than bundling such API into the Kwikstick
> > slcd driver package, it would be beneficial to split it out and have a
> > common API in io/dmd/ along the lines of:

>From point of view the eCos BSP concept, it would be great (and quite
enough) to define needed bitmaps/routines in hal/variant misc sources to
manage the display as a simple text console, i.e. I mean to setup eCos
auxiliary diagnostic channel for such a hardware in your HAL and as a
result to get a chance to run eCos tests using that diagnostic channel.

> >    typedef struct cyg_dmd_device_s cyg_dmd_device;
> > 
> >    cyg_dmd_set_pixel (const cyg_dmd_device *display,
> >                       bool on,
> >                       uint x, uint y);
> > 
> > 
> >    typedef struct cyg_font_s cyg_font;
> > 
> >    cyg_dmd_draw_string (const cyg_dmd_device *display,
> >                         const cyg_font *font,
> >                         const char *text,
> >                         uint x, uint y);
> > 
> > and perhaps also something like
> > 
> >    cyg_dmd_shift_horizontal (const cyg_dmd_device *display,
> >                              bool rotate,
> >                              int pixels);
> > 
> > and then driver implementations in devs/dmd/<some/hw>.
> > 
> > Any thoughts?

As for me I think that eCos I/O layer and device abstraction is not for
such things.

> Maybe you could first check the Framebuffer. It may be overkill for small
> displays but it might be possible to extract functionality that you need.

I agree with Ilia, but if you plan to develop some kind of an abstract
library to manage small graphical arrays (of course, first look for any
portable prototypes with right licence :-) then a right place for such
packages is eCos 'services' directory.

Sergei

> > Tomas
>