lcd4linux-devel

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

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

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.

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.

Which this split it should be possible to attach different Displays without 
having to touch the driver source, the uC or its firmware...

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.

 - "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

 - 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?
)

So, any ideas/comments/flames?

/Ernst

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

[C. M. <cm...@fr...>]

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.

> 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 ?

> 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 ?

>  - "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.

>  - 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.

> 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.


-- 
Chris Maj
Pronunciation Guide: Maj == May

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

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

[Michael R. <re...@eu...>]

Hi there,

>>> 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.

Well, maybe. But try to keep as close as possible on the "generic text"
side, as lots of widgets depend upon it.

> struct WIDGET_GPO only has "int num", I could abuse that to contain the bit 
> location (like num = (byte_location << 3) | bit_location)
You can define one single symbol as a GPO, but you can group them, too.
Just as you like.

>>>  - drv_generic_bitmapped: Provides a "framebuffer", where each bit is
>>> linked to a segment on the display and helper routines
Please don't do that yet. Write a driver, do it the "ugly" way, wait for
the next display that fits into this area, try to find commonalities,
and then think about a "generic" part.

This stuff is difficult: I've got a fisplay here that shares a part of
graphic area (about 100x8 pixels) with lots of symbols and a 7-digit
area. Where would that one fit into? I've no idea....

>>>  - "Symbol": a non-character symbol, think "Record" "Play" or "Pause" on
>>> a VCR.
I'd suggest GPO's here.

>>> since a display can
>>> easily exceed the 32 allowed GPOs.
> drv_generic_gpio.c:
> #define MAX_GPIS 32
> #define MAX_GPOS 32
Ignore these limits. they can be easily extended to whatever number you
need....

>>   - "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
Hmmm... you can render all alphanumeric into 7-digit, too, by mixing
upper and lowercase.

As I said above, don't try to generalize at this time.


>>>  - a specialization of the "Bar" class, for those nifty equalizer bars
>>> found on my display
That could be a GPO, too. GPO's are 32 bit at the moment, so if your
bars exceed 32 leds....

>>> (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?
You're right, this looks like a bug. Thanks fopr pointing this out!

> 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.
No, the text widget is Row/Col only.

There may be a "TrueType" Widget for graphic displays in the future (any
volunteers? :-)




bye, Michael (looking forward to see your cool display working with
lcd4linux!)

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

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

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

On Tuesday 01 August 2006 23:04, Michael Reinelt wrote:
> Hi there,
>
> >>> 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.
>
> Well, maybe. But try to keep as close as possible on the "generic text"
> side, as lots of widgets depend upon it.

Well, sure.

> > struct WIDGET_GPO only has "int num", I could abuse that to contain the
> > bit location (like num = (byte_location << 3) | bit_location)
>
> You can define one single symbol as a GPO, but you can group them, too.
> Just as you like.

Ah, that was the missing bit... I somehow had the impression they were 
single-bit. So unless I implement different brightness levels/greyscales per 
segment, GPOs should do the trick.

> >>>  - drv_generic_bitmapped: Provides a "framebuffer", where each bit is
> >>> linked to a segment on the display and helper routines
>
> Please don't do that yet. Write a driver, do it the "ugly" way, wait for
> the next display that fits into this area, try to find commonalities,
> and then think about a "generic" part.

hmm, I probably could base the driver on generic_text and generic_gpio, add 
some "translation" layer in the driver mapping the different text areas on 
different virtual rows. No new widgets or changes to layout.c needed here, 
but probably hard to adapt to different displays.
>
> This stuff is difficult: I've got a fisplay here that shares a part of
> graphic area (about 100x8 pixels) with lots of symbols and a 7-digit
> area. Where would that one fit into? I've no idea....

Heh. 100x8 Pixels would fit into 25 GPOs. (just kidding)

...
>
> Hmmm... you can render all alphanumeric into 7-digit, too, by mixing
> upper and lowercase.

Well, I know... my very first computer had eight 7segment chars as only 
display...

> As I said above, don't try to generalize at this time.
>
> >>>  - a specialization of the "Bar" class, for those nifty equalizer bars
> >>> found on my display
>
> That could be a GPO, too. GPO's are 32 bit at the moment, so if your
> bars exceed 32 leds....

Yep, some sort of "percent value" => "bit pattern" translation would be 
missing, but could be quite easily added as evaluator plugin.

> There may be a "TrueType" Widget for graphic displays in the future (any
> volunteers? :-)

Well, sorry. I'll pass... Though there are quite some 7Segment Truetype fonts 
out there *g*.

> bye, Michael (looking forward to see your cool display working with
> lcd4linux!)

Well, looking forward myself, having it sit arround in a box half done for 
quite a while now ;)

BTW, in case someone wants to play in the same sandbox, the display I used is 
still sold by Pollin (www.pollin.de) for 75 cent (50cent if you order three). 
They also have some example schematic for it (bit banging iface on parport, 
with some pascal software)

/Ernst

[Lcd4linux-devel] New LCD2USB pcbs

[Till H. <ti...@ha...>]

Hi,

i got some cheap new LCD2USB interface pcbs. So i can now sell
them for EUR 8,- each ...

Ciao,
  Till

-- 
Dr.Ing. Till Harbaum <ti...@ha...>
http://www.harbaum.org/till

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

[Michael R. <re...@eu...>]

> Well, I know... my very first computer had eight 7segment chars as only 
> display...
that leads me to the evil question: how old are you? :-)

my first one was a Commodore VC20.

>> That could be a GPO, too. GPO's are 32 bit at the moment, so if your
>> bars exceed 32 leds....
> 
> Yep, some sort of "percent value" => "bit pattern" translation would be 
> missing, but could be quite easily added as evaluator plugin.
Oh no, that should be possible right now:
2^x-1 should give you the result...

> BTW, in case someone wants to play in the same sandbox, the display I used is 
> still sold by Pollin (www.pollin.de) for 75 cent (50cent if you order three). 
> They also have some example schematic for it (bit banging iface on parport, 
> with some pascal software)

sounds cool, but pollin has pretty high shipping costs to austria. I'm
*not* going to buy *anything* from pollin with this costs.... Maybe you
could buy one for me and send it to me? (I'll pay for the regular
shipping costs, of course)



bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

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

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

On Thursday 03 August 2006 00:09, Michael Reinelt wrote:
> > Well, I know... my very first computer had eight 7segment chars as only
> > display...
>
> that leads me to the evil question: how old are you? :-)

Turning 30 next year...
That computer was used by the german "Post" for education, Z80 CPU, 2k Ram.
I learned programming on it, hacking in hex opcodes...

> my first one was a Commodore VC20.

Was probably arround the same time then :)

> sounds cool, but pollin has pretty high shipping costs to austria. I'm
> *not* going to buy *anything* from pollin with this costs.... Maybe you
> could buy one for me and send it to me? (I'll pay for the regular
> shipping costs, of course)

I have one leftover (I ordered three back then)
If you want it, drop me a mail.


> bye, Michael

cu,
/Ernst