From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8829 invoked by alias); 14 Jan 2012 17:09:15 -0000 Received: (qmail 8821 invoked by uid 22791); 14 Jan 2012 17:09:14 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-bk0-f49.google.com (HELO mail-bk0-f49.google.com) (209.85.214.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 14 Jan 2012 17:09:01 +0000 Received: by bkty8 with SMTP id y8so4792672bkt.36 for ; Sat, 14 Jan 2012 09:09:00 -0800 (PST) Received: by 10.205.112.6 with SMTP id eq6mr2349103bkc.16.1326560940111; Sat, 14 Jan 2012 09:09:00 -0800 (PST) Received: from vostro ([178.123.249.118]) by mx.google.com with ESMTPS id y22sm26317488bkf.4.2012.01.14.09.08.58 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jan 2012 09:08:59 -0800 (PST) Date: Sat, 14 Jan 2012 17:09:00 -0000 From: Sergei Gavrikov To: Ilija Kocho cc: ecos-devel@ecos.sourceware.org Subject: Re: dot matrix display infrastructure In-Reply-To: <4F119D17.7010702@siva.com.mk> Message-ID: References: <4F0DADB1.1090404@r-finger.com> <4F119D17.7010702@siva.com.mk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-01/txt/msg00012.txt.bz2 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/. > > > > 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 >