public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
* dot matrix display infrastructure
@ 2012-01-11 15:41 Tomas Frydrych
  2012-01-14 15:20 ` Ilija Kocho
  0 siblings, 1 reply; 5+ messages in thread
From: Tomas Frydrych @ 2012-01-11 15:41 UTC (permalink / raw)
  To: ecos-devel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: dot matrix display infrastructure
  2012-01-11 15:41 dot matrix display infrastructure Tomas Frydrych
@ 2012-01-14 15:20 ` Ilija Kocho
  2012-01-14 17:09   ` Sergei Gavrikov
  2012-01-15 18:26   ` Tomas Frydrych
  0 siblings, 2 replies; 5+ messages in thread
From: Ilija Kocho @ 2012-01-14 15:20 UTC (permalink / raw)
  To: ecos-devel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: dot matrix display infrastructure
  2012-01-14 15:20 ` Ilija Kocho
@ 2012-01-14 17:09   ` Sergei Gavrikov
  2012-01-15 18:34     ` Tomas Frydrych
  2012-01-15 18:26   ` Tomas Frydrych
  1 sibling, 1 reply; 5+ messages in thread
From: Sergei Gavrikov @ 2012-01-14 17:09 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: ecos-devel

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
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: dot matrix display infrastructure
  2012-01-14 15:20 ` Ilija Kocho
  2012-01-14 17:09   ` Sergei Gavrikov
@ 2012-01-15 18:26   ` Tomas Frydrych
  1 sibling, 0 replies; 5+ messages in thread
From: Tomas Frydrych @ 2012-01-15 18:26 UTC (permalink / raw)
  To: ecos-devel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: dot matrix display infrastructure
  2012-01-14 17:09   ` Sergei Gavrikov
@ 2012-01-15 18:34     ` Tomas Frydrych
  0 siblings, 0 replies; 5+ messages in thread
From: Tomas Frydrych @ 2012-01-15 18:34 UTC (permalink / raw)
  To: ecos-devel

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-01-15 18:34 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-11 15:41 dot matrix display infrastructure Tomas Frydrych
2012-01-14 15:20 ` Ilija Kocho
2012-01-14 17:09   ` Sergei Gavrikov
2012-01-15 18:34     ` Tomas Frydrych
2012-01-15 18:26   ` Tomas Frydrych

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).