From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24910 invoked by alias); 27 Oct 2009 21:59:18 -0000 Received: (qmail 24902 invoked by uid 22791); 27 Oct 2009 21:59:16 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-bw0-f215.google.com (HELO mail-bw0-f215.google.com) (209.85.218.215) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Oct 2009 21:59:11 +0000 Received: by bwz7 with SMTP id 7so247026bwz.6 for ; Tue, 27 Oct 2009 14:59:09 -0700 (PDT) Received: by 10.103.87.26 with SMTP id p26mr50791mul.44.1256680748318; Tue, 27 Oct 2009 14:59:08 -0700 (PDT) Received: from localhost ([93.85.204.90]) by mx.google.com with ESMTPS id 14sm1747414muo.45.2009.10.27.14.59.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Oct 2009 14:59:05 -0700 (PDT) Date: Tue, 27 Oct 2009 21:59:00 -0000 From: Sergei Gavrikov To: Steven Clugston Cc: "ecos-discuss@ecos.sourceware.org" Message-ID: <20091027215856.GA4551@sg-laptop> Mail-Followup-To: Steven Clugston , "ecos-discuss@ecos.sourceware.org" References: <4DCF6DBD3535F742BB167C528BBEE9803828B88A30@EXSAN01.campus.ncl.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DCF6DBD3535F742BB167C528BBEE9803828B88A30@EXSAN01.campus.ncl.ac.uk> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Alphanumeric LCD driver X-SW-Source: 2009-10/txt/msg00167.txt.bz2 On Tue, Oct 27, 2009 at 12:20:09PM +0000, Steven Clugston wrote: > Hi all. > > I've got some code to offer for discussion/comments. Hi Steven, > I've written a simple bit-bash style LCD driver for those very > common 2-line LCDs that use the Hitachi 4 or 8-bit HD44780 protocol. > I created an IO layer so that other types such as SPI, I2C, USB > might be added at a later stage. > I've been using this code with an Olimex SAM7MT256 board which comes > with one of these screens already soldered on it. I think they also > do an almost identical board which uses an LPC2xxx chip instead of > an AT91. > > Anyway, the code works as it stands with the above board, but I need > to add some macros in a similar way to the I2C bit bang bus so that > the HAL or application can define which IO lines are used for the > LCD data and control lines. > > The end goal for me is to be able to use a pdcurses wrapper driver > with it so that the management of the screen's contents is improved > by creating virtual pages which can be cycled through for example. > It might seem like overkill and a major code bloat for a 2-line > screen I suppose, but it could be extended for larger screens at > some point in the future. I've started to write the pdcurses driver > and tested it and it seems to work in a standalone application, but > I've not included it yet as it need more cleanup and testing. Why not? IMHO, for _some_ eCos targets PDCurses are not bloat. > I think LCD screens can be a useful debugging/tracing tool when all > serial ports are taken or where there are none in the first place. > They are a step better than just flashing a LED anyway. Agreed. Two examples. There is implementation eCos vectored virtual channel (VV) on FEMA 162B 16x2 LCD in powerpc/cogent HAL http://hg-pub.ecoscentric.com/ecos/file/tip/packages/hal/powerpc/cogent/current/src/hal_diag.c#l442 When I "found" it, I did embed the same for my Olimex LPC22x4 targets (some of those boards use HD44780 IC) http://bitbucket.org/tickling/olpcx22xx/src/tip/hal/arm/lpc2xxx/olpcx22xx/common/current/src/lcd_driver.c Well, at the least I know that RedBoot is started just looking on LCD. I even thought that LCD would be not a bad diagnostic channel for OpenOCD JTAG, well, w/out a layering and just to out a few nibbles on LCD controller. With minimal LCD init in RAM and a few GDB macros it would be possible "to cry" something. > Before I send any more time on it, is anybody else interested in > this and would it eventually acceptable for CVS? > > Are there any comments/suggestions particularly with regard to the > IO layer generality? My look on LCD layering in a picture (although, may be that is odd, I like VVs on LCD, but not all targets can use ROM monitor) SYNOPSYS io/lcd ;# less than framebuffer... devs/lcd/generic ;# write, config (pos, etc.) devs/lcd/hitachi/hd44780 ;# hwr funs implementation devs/lcd/arm/sam7ex256 ;# inline target's privates ... This controller http://en.wikipedia.org/wiki/HD44780_Character_LCD in fact is IC controlled via 4/8-bit parallel bus with some lines (=features). It seems for me that devs/lcd/hitachi/hd44780 must have all set of functions to use all features, but generic device driver (devs/lcd/generic) can have a few. Well, Steven that is just my view. As I could understand you thought about /dev/lcd like about character device, that /dev/haldiag: ecosconfig new sam7ex256 ecosconfig add lcd devs_lcd_arm_sam7ex256 ... Is it right? I this case /dev/haldiag (=/dev/lcd) is almost to ready for PDCurses like w-only serial driver. Well, may be I missed something from your idea, then correct me. Steven, I found this just now. Look, please (I liked those echos for Linux) via... /dev/lcd: http://lcd-mod.sourceforge.net/ http://lcd-mod.sourceforge.net/faq.php Really, Why not to have own choir for eCos? But it seems for me that LCD "layering" must be discussed more detailed to get more opinions about all pros/cons on implementation. Regards, Sergei > Regards, > > Steven -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss