Re: [Lcd4linux-devel] Driver for "Bit-mapped" displays

[Ernst B. <e.b...@xe...>]

On Tuesday 01 August 2006 00:41, C. Maj wrote:
> On Mon, Jul 31, 2006 at 10:44:09PM +0200, Ernst Bachmann waxed:
> > Hi List,
> >
> > I'm currently implementing a LCD4Linux driver for (non dot-matrix) VFDs
> > and similar displays. Think VCR, digital clock and such, or see the
> > attached page from a datasheet.
> >
> > Since such displays don't fit the drv_generic_text and
> > drv_generic_graphic models well (There is no concept like rows/cols or
> > pixels), I'll probably have to code the driver from scratch.
>
> My VCR pretty much has one row for ASCII, and the rest of
> the blinking lights with pre-printed text cutouts in front
> seem like GPOs to me.  No sense re-inventing the wheel.

Well, the main difference would be that they are no "General Purpose Output", 
but are symbols multiplexed like the rest of the display.
I could reuse the Widget_GPO class, but I'd need a more exact address spec for 
it, so instead of just "GPO 16" I'd have to say: "Byte 16, Bit 3".

struct WIDGET_GPO only has "int num", I could abuse that to contain the bit 
location (like num = (byte_location << 3) | bit_location)

> > This will require some additions to the core functionality, so I'm asking
> > beforehand if there are some objections/ideas for improvement:
> >
> > Since I want the code to be somewhat generic and usefull for different
> > devices, I'm splitting it in three parts:
> >
> >  - drv_generic_bitmapped: Provides a "framebuffer", where each bit is
> > linked to a segment on the display and helper routines
> >
> >  - lowlevel-driver: transfer of the framebuffer to the device (parport,
> > usb, whatever)
> >
> >  - layout config file: describing which bits in the framebuffer lights
> > which segment on the display.
>
> Are you proposing a new .conf file in addition to lcd4linux.conf ?

No, I'd thought about putting that in the layout section, or maybe the widget 
sections, but that would it make impossible to use the same widget in 
different layouts...

> > Which this split it should be possible to attach different Displays
> > without having to touch the driver source, the uC or its firmware...
>
> I would think keeping this functionality in the driver
> display source would prevent conf file dependency issues.

> > Now I would need an additional set of Widgets, like
> >
> >  - "Symbol": a non-character symbol, think "Record" "Play" or "Pause" on
> > a VCR.
> > the existing "icon" class does way to much here, the symbol would be a
> > simple "on/off" switch. GPOs wouldn't work here, too, since a display can
> > easily exceed the 32 allowed GPOs.
>
> Where is this limit of 32 GPOs defined ?
drv_generic_gpio.c:
#define MAX_GPIS 32
#define MAX_GPOS 32
 :)

>   - "7Segment Text": provides translation ascii->7Segment display, and
> > "knows" (from config) which bits in the framebuffer are part of it.
> >  - "14Segment Text": same, for more sophisticated displays
>
> I would think you'd want to keep the vanilla 'Text' widget
> so that there would be little changes to configuration
> required when changing displays.  Creating a header file
> with some arrays for translations from ascii->Nsegment
> display bits would allow each driver to implement the
> translation in its drv_generic_text_real_write callback.

Well, the translation asci->segment bits isn't the big problem, the problem 
would be configuring which segments correspond to which bits in the 
backbuffer.

And if I keep the std text class I'd have to implement some additional mapping 
in the driver, like "Row1 => the two digit 7segment display", "Row2=> the 
14segment text area" and so on...

> >  - a specialization of the "Bar" class, for those nifty equalizer bars
> > found on my display
> >
> > Those would be of a new type, "WIDGET_TYPE_BM", since the "_XY" and "_RC"
> > Types won't work here, with additions to layout.c to read them with a
> > special location spec...
> >
> > (Btw, off-topic:
> > why are the existing widget types defined as 1,2,3,4,5 when widget.c does
> > a bit-wise compare on the type [if ((Class->type & type) == 0) {]?
> > Shouldn't they be more like 1,2,4,8,16 ?
> > Or does it make sense that e.g. a KEYPAD widget can be positioned
> > wherever a TIMER or RC widget can?
> > )
>
> That looks like a bug.  The widget_find proc right below
> there uses an integer comparison.  Although I think I wrote
> that one in widget_find, so I shouldn't comment.

Hmm, it might make sense to, say, declare widget text with 
type=WIDGET_TYPE_RC | WIDGET_TYPE_XY, that way the layout would accept text 
widgets with an Row/Col location as well as with a X/Y location. But I didn't 
read all the code there, esp. not the graphic display code, so I could be 
dead wrong here...

> > So, any ideas/comments/flames?
> >
> > /Ernst
>
> I think it sounds like a cool hack.  I'm pretty curious to
> how you hook the wires up to such a display.

Well, I attached a picture of the current state... I've snaped it with my 
mobile phone cam and had to resize it to fit into the 40k limit, so its a bit 
blurry...

Its mounted in a 5 1/4" Frame, up front is a little button, a IR receiver, and 
the segment/grid drivers (lots of Transistors...)
Behind that a PCB with four 74HC595 shift registers.
The dangerous looking thing is the PSU (an inverter), generating -30V Grid 
voltage and ~4V filament voltage for the VFD. Yeah, the coil is too big, I 
salvaged it from an old PC supply...

The uC part isn't finished, I have a mostly-working one with an ATTiny2313, 
hooking to a serial port, and a not-so-much working with a PIC18F2550, 
connecting to USB.

GPL'ed Firmware for both (avr-gcc or sdcc) available on request.

/Ernst