From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7600 invoked by alias); 28 Oct 2009 22:25:45 -0000 Received: (qmail 7565 invoked by uid 22791); 28 Oct 2009 22:25:44 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from cheviot10.ncl.ac.uk (HELO cheviot10.ncl.ac.uk) (128.240.234.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Oct 2009 22:25:39 +0000 Received: from cheviot10.ncl.ac.uk (localhost.localdomain [127.0.0.1]) by cheviot10.ncl.ac.uk (8.13.8/8.13.8) with ESMTP id n9SMPZ2b008554; Wed, 28 Oct 2009 22:25:35 GMT Received: from exhubct01.campus.ncl.ac.uk (exhubct01.ncl.ac.uk [10.8.239.5]) by cheviot10.ncl.ac.uk (cheviot10.ncl.ac.uk [128.240.234.73]) envelope-from with ESMTP id l9RMPZ2561039446WG ret-id none; Wed, 28 Oct 2009 22:25:36 +0000 Received: from EXSAN01.campus.ncl.ac.uk ([10.8.239.12]) by exhubct01.campus.ncl.ac.uk ([10.8.239.5]) with mapi; Wed, 28 Oct 2009 22:25:35 +0000 From: Steven Clugston To: Sergei Gavrikov CC: "ecos-discuss@ecos.sourceware.org" Date: Wed, 28 Oct 2009 22:25:00 -0000 Message-ID: <4DCF6DBD3535F742BB167C528BBEE9803828822385@EXSAN01.campus.ncl.ac.uk> References: <4DCF6DBD3535F742BB167C528BBEE9803828B88A30@EXSAN01.campus.ncl.ac.uk> <20091027215856.GA4551@sg-laptop> In-Reply-To: <20091027215856.GA4551@sg-laptop> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-smtpf-Report: sid=l9RMPZ256103944600; client=lan,relay,white,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 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/msg00181.txt.bz2 Hi Sergei Thanks for your comments. >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/powerp c/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. Ok so you gone a bit further with it than me already! It seem that there are now three implementations which are all still board = specific, probably more in peoples private repos. I know these screen drivers are relatively trivial, but it seems silly to h= ave to reimplement it for each new board. My approach was to try and formalise it into a standard driver rather than = have it as a low level a set platform diagnostic routines. I was thinking more about how it could be used by an application as a chara= cter driver with cyg_io_set_config keys to control specific things that per= culiar to an lcd screen. I thought any terminal emulation could then be don= e in a higher layer such as a pdcurses driver. I would like to think that in future I could buy any board with some spare = gpio and hook up an LCD screen then just have to supply either a few macros= or a routine like the i2C bitbang hal_platform_i2c_bitbang(..) one in orde= r to get it working. >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 >(=3Dfeatures). 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. Sorry Sergei, I was a bit confused at first by what you ment by this, but I= think I understand now. The generic part provides devs level common interf= ace which will just call the relevant funs in the hd44780 (or other) contro= ller specific part. Is it necessary to layer it this much? The devs/lcd/arm/sam7ex256 bit I think I would prefare just some entries in= the platform hal or in the actual application (as per the bitbang I2C), ot= herwise there would need to be a driver file (and cdl) for each board that = uses it. >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? Yes, or maybe more just: ecosconfig new sam7ex256 ecosconfig add lcd devs_lcd_hd44780 And then let the compilation fail at the link stage if the plaform specific= routine/macros aren't in place somewhere either in hal or the final applic= ation. >I this case /dev/haldiag (=3D/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. That's what I had in mind. The pdcurses driver can then just call the corre= sponding key with cyg_io_set_config() to control the cursor position/visabi= lity or whatever terminal type attirbutes can be exploited. The question is which of these are common to various types of LCD screen, I= 've only used the 2x16 HD44780 type todate but there must be others that ar= e more sophisticted and let you invert the colours and other stuff besides. >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 I think I've looked at this before. Do you think it is necessary or useful = to add this VT53 emulation? The pdcurses driver could do the same without needing to emulate all of the= control codes. >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. I'm awaiting comments :) Any ideas how to take this forwards (maybe consolidate it with what you've = already done) before I have to move on from it or put it back on a low flam= e? 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