From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27693 invoked by alias); 15 Jan 2012 18:34:14 -0000 Received: (qmail 27581 invoked by uid 22791); 15 Jan 2012 18:34:13 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from r-finger.com (HELO r-finger.com) (178.79.160.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 15 Jan 2012 18:34:01 +0000 Received: from air.local (host86-138-175-84.range86-138.btcentralplus.com [86.138.175.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by r-finger.com (Postfix) with ESMTPSA id B84609C0A for ; Sun, 15 Jan 2012 18:34:00 +0000 (GMT) Message-ID: <4F131C18.20609@r-finger.com> Date: Sun, 15 Jan 2012 18:34:00 -0000 From: Tomas Frydrych User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: ecos-devel@ecos.sourceware.org Subject: Re: dot matrix display infrastructure References: <4F0DADB1.1090404@r-finger.com> <4F119D17.7010702@siva.com.mk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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/msg00015.txt.bz2 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