dot matrix display infrastructure

dot matrix display infrastructure

[Tomas Frydrych]

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:

  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?

Tomas

Re: dot matrix display infrastructure

[Ilija Kocho]

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

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.

> Tomas

Re: dot matrix display infrastructure

[Sergei Gavrikov]

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
> 

Re: dot matrix display infrastructure

[Tomas Frydrych]

Hi Sergei,

On 14/01/2012 17:08, Sergei Gavrikov wrote:
>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.

The diagnostic channel is an interesting idea, but I don't think I want
to build the bitmaps, etc., into the variant hal. The problem of
outputing text on a dot matrix display is generic, not specific to the
board, so should be addressed in a reusable manner.

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

Ah, I think that is exactly the answer I have been looking for :-)

Tomas

Re: dot matrix display infrastructure

[Tomas Frydrych]

Hi Ilija,

On 14/01/2012 15:19, Ilija Kocho wrote:
> 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 had looked at the fb, and I thought it was an overkill in this case.
The manipulation of the individual pixels on the LCD is quite trivial,
and for the size of the display does not require an abstraction. The
only thing that merits additional API is text output, which is not
provided for by the fb anyway.

Tomas