lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] New display: LEDMATRIX

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

Hi,

On Sunday 13 August 2006 15:48, Michael Reinelt wrote:
> Well, *now* I understand what your huge display is for :-)
In fact i wanted to do this since i started to build the display.

> This sounds very cool. *Please* add a picture to the wiki when it's
> finished...
Sure.

> I think the config could look like this
Ok, got it, thanks.

Till

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

Re: [Lcd4linux-devel] New display: LEDMATRIX

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

Hi Till,

> I am currently writing a kvv plugin. KVV is the "Karlsruher Verkehrsverbund"
> and you can get access via web interface to the train/bus timings usually 
> displayed at the stations (things like "Linie 3, Karlsruhe Hbf. in 5 
> Minuten"). I am extracting this information and use it to reconstruct 
> this again for use on my LED display. You can then specify the interesting 
> station in lcd4linux.conf and have the next 4 trains displayed in real
> time just like the real display at the station does.

Well, *now* I understand what your huge display is for :-)

This sounds very cool. *Please* add a picture to the wiki when it's
finished...

> Now my question: My plugin currently returns single strings for
> each line (like kvv(0) will return the train that will arrive next,
> kvv(1) the train that will arive second etc ect). Can i somehow include
> color information in this? I'd like to specify an additional time
> (the time it takes me to get to the station) and then have the trains
> displayed in red (if i can't reach them anymore) in yellow (if i have
> to hurry) and green (if i'll reach them easily). How would this be done?

First, are you writing the plugin in an asynchronous way? LCD4Linux
doesn't like delays in plugins very much; that's why you should use
threads when a plugin may take some time to get the needed information.
Take a look at the 'exec' plugin for how to handle that...

Now for your question: I'd use two different funtions in the plugin: One
for the "name" of the next train, one for the departure time (or for
'minutes until departure' or whatever you'll find handy here).

IIRC the color attributes of the text widget should re-evaluate on every
update (if not, I'm gonna change them; should be easy with the new
'dynamic properties').

I think the config could look like this

Widget Train1 {
 expression KVV:name(0)
 foreground KVV:time(0) < 2 ? FF0000 : KVV:time(0) < 5 ? FFFF00 : 00FF00
}

you got the point?



bye, Michael

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

Re: [Lcd4linux-devel] New display: LEDMATRIX

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

Hi,

On Sunday 13 August 2006 13:52, Michael Reinelt wrote:
> A further improvement comes to my mind: give different areas of the bar
> different colors? (say: 0-50% green, 51-80% yellow, 81-100% red)
Hmm ... I'll think about that ...

> Another great idea, which I already improved: I removed all the BOLD
> stuff (sorry, Till :-) an re-added this as a text-widget specific
Yes, i am currently working on a new plugin and i am seeing patches
coming in at quite a high rate ... but fortunately cvs/patch are able
to manage this ...

> btw, there's a 'truetype' widget for graphic displays on my wishlist....
Cool ...

I am currently writing a kvv plugin. KVV is the "Karlsruher Verkehrsverbund"
and you can get access via web interface to the train/bus timings usually 
displayed at the stations (things like "Linie 3, Karlsruhe Hbf. in 5 
Minuten"). I am extracting this information and use it to reconstruct 
this again for use on my LED display. You can then specify the interesting 
station in lcd4linux.conf and have the next 4 trains displayed in real
time just like the real display at the station does.

Now my question: My plugin currently returns single strings for
each line (like kvv(0) will return the train that will arrive next,
kvv(1) the train that will arive second etc ect). Can i somehow include
color information in this? I'd like to specify an additional time
(the time it takes me to get to the station) and then have the trains
displayed in red (if i can't reach them anymore) in yellow (if i have
to hurry) and green (if i'll reach them easily). How would this be done?

Till

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

Re: [Lcd4linux-devel] New display: LEDMATRIX

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

Hi Till, list,

> i have changed the generic widget extra color into a bar specfic barcolor0 und
> barcolor1 which can be used to set the colors of the both bars seperately (see
> the screenshot at http://ssl.bulix.org/projects/lcd4linux/wiki/LEDMatrix).

Great Idea!

A further improvement comes to my mind: give different areas of the bar
different colors? (say: 0-50% green, 51-80% yellow, 81-100% red)

I have no idea how to implement this in a clean (and understandable :-)
way...

maybe a bar could have a 'background image', and the bar drawing
function just does alpha blending?

> I have additionally added support for a bold 6x8 font'which you can see in 
> that screenshot as well. I just love to have more LEDs being switched on ...

Another great idea, which I already improved: I removed all the BOLD
stuff (sorry, Till :-) an re-added this as a text-widget specific
attribute. So you can add a "style 'bold'" attribute to every text
widget. This attribute is dynamically evaluated, so you can even change
between bold and normal font during operation (there's an example in the
lcd4linux.conf.sample from current CVS,  using the test::onoff() plugin.
Have a look at the CPU widget)

While implementing this, I found the current widget attribute handling
to be quite complex. So I tried to hide some of the complexity a bit in
the new 'dynamic property' functions. Some properties of the text widget
(namely prefix postfix and style) use this new stuff. Looks much cleaner
to me....


btw, there's a 'truetype' widget for graphic displays on my wishlist....


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

[Lcd4linux-devel] Start earning the salary you deserve by obtaining the appropriate University Degree.

[<lcd...@co...>]

<div align="left"><b><font size="5"> Want the degree but can’t find the time?</font></b><BR>
  <BR>
  WH@T A GREAT IDEA!<BR>
  We provide a concept that will allow @nyone with suff1cient work experience 
  to obtain a fully verif1able Univers1ty Degree.<BR>
  Bachel0r$, Masters 0r even a Doctorate.<BR>
  Think of it, with1n four to six week$, y0u too could be a college graduate.<BR>
  Many people share the same frustrati0n, they are all doing the work of the person 
  that has the degree @nd the person th@t has the degree i$ getting all the money.<BR>
  D0n’t you think that it is t1me you were paid fair compensation f0r the level 
  of work you are @lready doing?<BR>
  Th1s is your ch@nce to finalIy m@ke the r1ght move and receive your due benef1ts.<BR>
  If you are like most pe0ple, you are more than qualified with your experience, 
  but are lacking th@t prestigious piece 0f paper known as a d1plom@ that is o
ften 
  the pas$port to succe$$.<BR>
  <b>CALL US TOD@Y AND GIVE YOUR W0RK<BR>
  EXPERIENCE THE CHANCE TO E@RN YOU<BR>
  THE HIGHER COMPENS@TION YOU DE$ERVE!</b><BR>
  <font color="#FFO033" size="5">CALL NOW:</font><font color="#FF0033" size="7"><BR>
  <b>|-815-828-2222</b></f0nt><BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
   $leep e
ven th0ugh his eye$ stung and 1tched w1th tiredne$s. His back </d1v>

[Lcd4linux-devel] Obtain a University Degree based on your professional experience.

[<lcc...@ao...>]

<div align="left"><b><font size="5"> Want the degree but can’t find the t1me?</font></b><BR>
  <BR>
  WHAT A GREAT IDEA!<BR>
  We provide @ concept that wil] allow anyone with sufficient work experience 
  to obtain a fuIIy ver1fiable University Degree.<BR>
  B@chelors, M@sters or even a D0ctorate.<BR>
  Th1nk 0f it, within f0ur to six weeks, you too could be a college gradu@te.<BR>
  Many peop]e $hare the same fru$tration, they are all doing the w0rk of the person 
  that ha$ the degree and the per$on that ha$ the degree 1s getting @]l the money.<BR>
  D0n’t you th1nk that it 1$ time you were pa1d fair compen$ation for the leve1 
  of work you are already doing?<BR>
  This is your chance to f1nal1y make the right move and receive your due benefits.<BR>
  If y0u are like most people, you are m0re than qual1fied with your experience, 
  but are lacking that pre$tigiou$ piece of paper known as @ d1ploma that is often 
  the pas$po
rt t0 succes$.<BR>
  <b>C@LL US T0DAY AND GIVE YOUR WORK<BR>
  EXPERIENCE THE CHANCE TO E@RN YOU<BR>
  THE HIGHER COMPENSATl0N YOU DESERVE!</b><BR>
  <font coIor="#FF0033" $ize="5">CALL NOW:</font><font color="#FF0033" $ize="7"><BR>
  <b>I-815-828-2222</b></font><BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
   match against Hufflepuff i
n his third ye@r, which had taken pl@ce </div>

Re: [Lcd4linux-devel] New display: LEDMATRIX

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

Hi,

i have changed the generic widget extra color into a bar specfic barcolor0 und
barcolor1 which can be used to set the colors of the both bars seperately (see
the screenshot at http://ssl.bulix.org/projects/lcd4linux/wiki/LEDMatrix).

I have additionally added support for a bold 6x8 font'which you can see in 
that screenshot as well. I just love to have more LEDs being switched on ...

BTW: The small thing on top is a regular 4*20 lcd.

Till

-- 
Dr.-Ing. Till Harbaum

Re: [Lcd4linux-devel] New display: LEDMATRIX

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

Hi Till,

> i have added RGB support to the LEDMATRIX display. 

Great! Pictures! I wanna see pictures!

( I showed your pictures to my girlfriend. she said "really nice, but...
YOU'RE NOT GOING TO BUY THIS". Maybe you're familiar with this special
kind of timbre :-)

> Furthermore i made a change
> to the widget item which you might not like and which can easily be removed 
> again: I added the parameter "extracolor" which can be used to specify a 
> third color (besides foregound and background). This color is meant to be
> used for widget specific "special" purposes. I have changed the bar widget
> to use this color for the bordert (if style is set to hollow).
> 
> You can just ignore the new color and everything will look like it did before. 
> But if you use it you can change the border color of the bar.
> 
> Do you think this is a good idea?

I think it's a very good idea. I didn't look at the code now, but this
is a special attribute for the bar widget, isn't it? So why not call it
"border color" or something?

Due to the fact that your display seems to be the first multi-color
display available for lcd4linux, we didn't think about colors too much
in the past. Hopefully this will change in the future...


bye, Michael

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

Re: [Lcd4linux-devel] New display: LEDMATRIX

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

Hi,

i have added RGB support to the LEDMATRIX display. Furthermore i made a change
to the widget item which you might not like and which can easily be removed 
again: I added the parameter "extracolor" which can be used to specify a 
third color (besides foregound and background). This color is meant to be
used for widget specific "special" purposes. I have changed the bar widget
to use this color for the bordert (if style is set to hollow).

You can just ignore the new color and everything will look like it did before. 
But if you use it you can change the border color of the bar.

Do you think this is a good idea?

Till

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

Re: [Lcd4linux-devel] New display: USB Hub

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

Hi all,

> Now, after your driver for the biggest Display, I have a driver for the most 
> simple (only 4 LEDs on average), but probably the most common display:
> 
> A lcd4linux driver to control the port indicator LEDs on common USB Hubs.

Well, this is probably the funniest driver we'll ever get with
lcd4linux! Unfortunately, I don't own any USB hub, but I really like the
idea!

I think it shows the power and flexibility of lcd4linux, because
integrating such a driver (which has *absolutely nothing* to do with
LCD's or displays) was that easy and required exactly *no* changes to
the internal framework. Amazing!

Committed to CVS. Thanks a bunch!

btw, Ernst, would you care writing some docs in the wiki? Especially a
photo would be great...


bye, Michael

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

[Lcd4linux-devel] New display: USB Hub

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

Hi,
On Saturday 05 August 2006 23:30, Till Harbaum wrote:
> Hi,
>
> i had two spare hours, 
Same here ;)
> my old LED matrix display (for which i have never 
> really written an application) and lcd4linux. So i wrote a driver for what
> probably is the biggest (roughly 60 x 25 cm) and power hungry
> (20A @ 5V) display available to lcd4linux.

Now, after your driver for the biggest Display, I have a driver for the most 
simple (only 4 LEDs on average), but probably the most common display:

A lcd4linux driver to control the port indicator LEDs on common USB Hubs.

The driver is pretty straightforward: you specify the vendor/product ID for 
your hub in config, it then searches for the device, asks if it has 
controllable LEDS, and how many, and then initializes them as GPOs for your 
blinking pleasure.

The per-port GPOs accept the following values:
   0 : Automatic color (display link state etc)
   1 : Amber
   2 : Green
   3 : Off

Unfortunatly, my HUBs are all green-only, so I couldn't test "amber".

The normal function of the HUB isn't interrupted while the driver runs.

An example config file is attached.

Have fun with it,
/Ernst

[Lcd4linux-devel] New display: LEDMATRIX

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

Hi,

i had two spare hours, my old LED matrix display (for which i have never 
really written an application) and lcd4linux. So i wrote a driver for what 
probably is the biggest (roughly 60 x 25 cm) and power hungry
(20A @ 5V) display available to lcd4linux.

See the driver here:
https://ssl.bulix.org/projects/lcd4linux/wiki/LEDMatrix

and if you want to build one yourself, just follow these
instructions:
http://www.harbaum.org/till/ledmatrix/

Ciao,
  Till

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

Re: [Lcd4linux-devel] DOG-M via I2C on WRAP

[Luis.F.Correia <Lui...@se...>]

Hi Stefan, 

> -----Original Message-----
> From: Stefan Krister [mailto:ste...@cr...] 
> 
> Hi Folks,
> 
> yesterday my DOG-M awaked from death ...
> 
> There are 14 init-nibbles to send. Without them, the LCD keeps dark.
> There are instructions for setting 5 bits of contrast-level, 
> internal bias, booster, amplifier and follower (what ever 
> that means ...) and the usual things like 'display on', 
> 'cursor home', 'display clear', 'display size' and so on. If 
> you like to help me, take a look into the datasheets at [1] and [2].
> 
> I managed to do a 8bit init via dip-switches ... and it 
> awakes! Then I wrote a shellscript to do the same with 4bit 
> and it worked too.

Congratulations!

> 
> After initialisation lcd4linux runs on the display. I made a 
> few pictures, view it at [3].
> 
> But ...
> 
> I2C _is_ slow. No way to have scrolling lines by now.
> Luis, what about your 8bit (2x PCF8574) experiment? May I 
> have your details? Adressing, configuration, schematics?

Well, the 8bit version was really just an experiment... It is
still slow. But it depends on the actual timings on the
scx200 driver, one could alter them a bit to make it slightly
faster.

As for the 2xPCF8574 schematics, I have none, but it is basicly 
just using one as the 8bit output, and the other for the
EN and RS bits. But there is a lot of code to be written inside
lcd4linux, as we'll need to separate the 4bit from the 8 bit
routines.

> 
> The DOG-M seems to use a different way for adressing the 
> positions on the display. I've one with 3 lines / 16 
> characters and one with 2 lines / 16 characters. Maybe my 
> init isn't correct by now. I'll keep trying more.
> 
> By the limits of the WRAP-Board, I'll try to plug the DOG-M 
> on the GPIO-header too. There are 7 gpio pins to use. I 
> think, that I could use parts of the "Routerboard" or 
> "Soekris" code for that.
> 
> But how to integrate into lcd4linux? By now, I think I should 
> add a new 'Model' to the HD44780 section. 

You could do as Martin Hejl has done, create a 'ppdev emulator'
driver. Check out http://soekris.helj.de for some details.


> Is that the right 
> way? I want to have the init-sequence once for both 
> wiring-variants. I want also to have the contrast setting by 
> configuration. Maybe one wants to plug a DOG-M via parport or 
> USB at 5V - it's possible and the init should work for that too.
> 
> [1] german: http://www.lcd-module.de/deu/pdf/doma/dog-m.pdf
> [1] english: http://www.lcd-module.de/eng/pdf/doma/dog-me.pdf
> [2] http://www.lcd-module.de/eng/pdf/zubehoer/st7036.pdf
> [3] http://gallery.port23.de/v/bastard/wrap/lcd/
> 
> MfG
> 
> Stefan

Luis Correia

[Lcd4linux-devel] DOG-M via I2C on WRAP

[Stefan K. <ste...@cr...>]

Hi Folks,

yesterday my DOG-M awaked from death ...

There are 14 init-nibbles to send. Without them, the LCD keeps dark.
There are instructions for setting 5 bits of contrast-level, internal
bias, booster, amplifier and follower (what ever that means ...) and the
usual things like 'display on', 'cursor home', 'display clear', 'display
size' and so on. If you like to help me, take a look into the datasheets
at [1] and [2].

I managed to do a 8bit init via dip-switches ... and it awakes! Then I
wrote a shellscript to do the same with 4bit and it worked too.

After initialisation lcd4linux runs on the display. I made a few
pictures, view it at [3].

But ...

I2C _is_ slow. No way to have scrolling lines by now.
Luis, what about your 8bit (2x PCF8574) experiment? May I have your
details? Adressing, configuration, schematics?

The DOG-M seems to use a different way for adressing the positions on
the display. I've one with 3 lines / 16 characters and one with 2 lines
/ 16 characters. Maybe my init isn't correct by now. I'll keep trying more.

By the limits of the WRAP-Board, I'll try to plug the DOG-M on the
GPIO-header too. There are 7 gpio pins to use. I think, that I could use
parts of the "Routerboard" or "Soekris" code for that.

But how to integrate into lcd4linux? By now, I think I should add a new
'Model' to the HD44780 section. Is that the right way? I want to have
the init-sequence once for both wiring-variants. I want also to have the
contrast setting by configuration. Maybe one wants to plug a DOG-M via
parport or USB at 5V - it's possible and the init should work for that too.

[1] german: http://www.lcd-module.de/deu/pdf/doma/dog-m.pdf
[1] english: http://www.lcd-module.de/eng/pdf/doma/dog-me.pdf
[2] http://www.lcd-module.de/eng/pdf/zubehoer/st7036.pdf
[3] http://gallery.port23.de/v/bastard/wrap/lcd/

MfG

Stefan

Re: [Lcd4linux-devel] [PATCH] sync the parameter of i2c_transfer function

[Luis.F.Correia <Lui...@se...>]

Hi!

> -----Original Message-----
> From: Michael Reinelt [mailto:re...@eu...] 
> Sent: Thursday, August 03, 2006 12:00 PM
> To: Kevin Lo
> Cc: lcd4linux-devel
> Subject: Re: [Lcd4linux-devel] [PATCH] sync the parameter of 
> i2c_transfer function
> 
> Hi Kevin, Hi i2c-guys,
> 
> > Here is a patch for syncing i2c_transfer function in Linux 
> kernel 2.6, 
> > thanks.
> Thanks a lot for your contribution. I'm forwarding this to 
> the developer list so that the i2c guys can take care of this 
> (I don't use i2c myself)

Well, i doubt of the usefullness of this patch as for I2C HD44780
LCD access we 'talk' directly with the PCF8574 chip.

It may be used for other i2c lm sensors related stuff.

And i can't test anything with 2.6 kernels as LEAF still uses
the 2.4 kernel series.

Luis Correia

Re: [Lcd4linux-devel] [PATCH] sync the parameter of i2c_transfer function

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

Hi Kevin, Hi i2c-guys,

> Here is a patch for syncing i2c_transfer function in
> Linux kernel 2.6, thanks.
Thanks a lot for your contribution. I'm forwarding this to the developer
list so that the i2c guys can take care of this (I don't use i2c myself)


> --- lcd4linux_i2c.h.orig	2006-08-03 17:38:44.000000000 +0800
> +++ lcd4linux_i2c.h	2006-08-03 17:39:27.000000000 +0800
> @@ -78,7 +78,7 @@
>  
>  /* Transfer num messages.
>   */
> -extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[], int num);
> +extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num);
>  
>  /*
>   * Some adapter types (i.e. PCF 8584 based ones) may support slave behaviuor. 


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

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

[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

[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

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

[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

[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] display on WRAP-Board - how fast is i2c?

[Luis C. <lfc...@lf...>]

Michael Reinelt wrote:
> Hi Luis,
> 
>> You already wrote the function I need... it is inside plugin_sample.c
> 
> Oh.... I feel *so* sorry for writing a sample plugin that actually
> *makes sense* :-)
> 
>> I've already added the function and the relevant functions and will make
>> a commit to CVS.
>>
>> Some fixes to I2C handling will also be committed.
>> I'll do separate checkin's, to make things easier to track.
> 
> Thanks. I did some modifications to the string plugin (creating a new
> init() and exit() function for struppper isn't necessary, just use the
> exisiting ones), but I cannot commit at the moment, because of other
> heavy modifications not yet finished (hint: virtual rows, scrolling, ...)

I see what you mean and will do a commit to fix those. Only one init 
function is needed and we'll just register the function inside.

> But there's a problem with your patch: I get a linker error about an
> undefined function 'drv_generic_i2c_close()' in drv_HD44780.c. That's
> correct, such a function is called, is present in drv_generic_i2c.h, but
> is missing in drv_generic_i2c.c

That is the result of not being able to compile current CVS version and 
working on an older file, 0.10.0 release actually.

Nevertheless, I've already commit the fix for it.

Still unable to compile it due to some errors in "drv_HD44780.c, 
drv_LPH7508.c and drv_generic_keypad.c".

Will you need any help on those?

> 
> bye, Michael
> 

Btw, why the need for autoconf 2.59e? I pretty much remove those checks 
to be able to use autoconf 2.59 and it still compiled all the same...


Luis Correia

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.