lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] Little Patch for debug.h

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

Hi Michael,
>
> > -void message(const int level, const char *format, ...);
> > +void message(const int level, const char *format, ...)
> > __attribute__((format (__printf__, 2, 3) ));
>
> Great, thanks a lot! I applied it, and corrected a really lot of format
> mismatches in various source files!

Ugh, and most of those mismatches were in my USBHUB driver, it seems. 
*blushes*

Looks like I spend too much time with c++...


/Ernst

Re: [Lcd4linux-devel] Little Patch for debug.h

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

Hi Ernst,

> -void message(const int level, const char *format, ...);
> +void message(const int level, const char *format, ...) __attribute__((format 
> (__printf__, 2, 3) ));

Great, thanks a lot! I applied it, and corrected a really lot of format
mismatches in various source files!

Committed to CVS.

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

[Lcd4linux-devel] Little Patch for debug.h

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

Hi list,

A little one-line patch to debug.h:

-------------------- snip ---------------
 extern int running_background;
 extern int verbose_level;

-void message(const int level, const char *format, ...);
+void message(const int level, const char *format, ...) __attribute__((format 
(__printf__, 2, 3) ));

 #define debug(args...) message (2, __FILE__ ": " args)
 #define info(args...)  message (1, args)
----------------- snip -------------------

It tells gcc that "message" takes a printf-like format string, so gcc can 
check if the varargs match.
Saved me a lot of bug-hunting time for spurious segfaults caused by wrong 
debug statements.

Should work with gcc 3.3.1 or later, probably earlier versions of gcc, too.

One could add some gcc version-check #ifdefs arround it, but since other parts 
of the code already use __attribute__(( unused )) and the like, its probably 
not neccessary.

/Ernst

Re: [Lcd4linux-devel] [lcd4linux] Sharp LM40001G LCD

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

On Wednesday 06 September 2006 06:52, Michael Reinelt wrote:
> Hi there,
>
> >>> Interfacing it seems a bit of troublesome, as it doesn't contain a
> >>> framebuffer, so all data has to be sent continuosly.
> >>
> >> So does the ledmatrix display, so you might be able to do something
> >> similar to its driver. 400 x  64 is 25600 pixels which in turn is 3200
> >> bytes. This does not fit into the memory of any of the small avrs,
> >> so you either use a mega128 (with 4k ram) or use an external ram.
> >
> > Yeah, probably some sram chip from an old '286 Mainboard, got plenty of
> > those left.
> > Then probably a pic18f4550, maybe ATMega16.
>
> Well, I'm afraid this won't work that easy... from a quick glance over
> the datasheet, it looks like the display consists of row and column
> controllers only, but no real lcd controller.
>
> These row/column drivers are controlled using a serial protocol, which
> is a) high frequency and b) very timing critical. Thats what a lcd
> controller is for.
>
> If you really plan to build an interface, you should really consider
> using a SED1550 or similar controller.

Hrmm. The original controller board has a Z80 CPU, a Z80 UART, Ram, EPROM with 
Os, an "Character Generator" EPROM, more Ram, a 7.3728 crystal, and a larger 
TTL graveyard.

I think it generates its pixel data with dual 74166 shift registers, and does 
all the character generation stuff in TTL. Hard to say more about it without 
schematic.

And since the pixel clock is only at about 500kHz (800uS for a line, 2uS for a 
pixel, 1/(2*10^-6)=500kHz, it should be possible to implement in an uC, maybe 
with help of two external shift registers.

Gotta test if shifting in software can be fast enough, unfortunatly those uCs 
only have one USI/MSSP that could help here.


> Wolfgang, are you listening? Your opinion?
>
> > With enough ram it would also be possible to implement two different
> > greys. Keep two framebuffers, display them alternating, keep one "on
> > screen" a little longer than the other (If the display timings allow
> > that)
>
> Again, I'm afraid this won't work, probably because of the "slowness" of
> the LCD display.

Yeah, probably. Since it would be "just" software, it can't hurt to try. If it 
doesn`t work, nothing lost.

/Ernst

Re: [Lcd4linux-devel] Introducing myself

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

Hi there,

> These commits are a bit critical, but I don't expect any breakage. If
> I broke something, I apologize, just blame me and tell what got
> broken.

They look fine here. smoketest was successful.

Thanks, Michael

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

Re: [Lcd4linux-devel] [lcd4linux] Sharp LM40001G LCD

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

Hi there,

>>> Interfacing it seems a bit of troublesome, as it doesn't contain a
>>> framebuffer, so all data has to be sent continuosly.
>> So does the ledmatrix display, so you might be able to do something
>> similar to its driver. 400 x  64 is 25600 pixels which in turn is 3200
>> bytes. This does not fit into the memory of any of the small avrs,
>> so you either use a mega128 (with 4k ram) or use an external ram.
> 
> Yeah, probably some sram chip from an old '286 Mainboard, got plenty of those 
> left.
> Then probably a pic18f4550, maybe ATMega16.

Well, I'm afraid this won't work that easy... from a quick glance over
the datasheet, it looks like the display consists of row and column
controllers only, but no real lcd controller.

These row/column drivers are controlled using a serial protocol, which
is a) high frequency and b) very timing critical. Thats what a lcd
controller is for.

If you really plan to build an interface, you should really consider
using a SED1550 or similar controller.

Wolfgang, are you listening? Your opinion?

> With enough ram it would also be possible to implement two different greys.
> Keep two framebuffers, display them alternating, keep one "on screen" a little 
> longer than the other (If the display timings allow that)
Again, I'm afraid this won't work, probably because of the "slowness" of
the LCD display.


bye, Michael

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

Re: [Lcd4linux-devel] [lcd4linux] Sharp LM40001G LCD

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

On Tuesday 05 September 2006 23:35, Till Harbaum wrote:
> Hi,
>
> 400*64 pixels is quite nice. Under lcd4linux this would basically
> be a 66*8 character display.
>
> > Maybe some of you also have interrest in a cheap size-DOES-matter Graphic
> > LCD, so we could share some of the development work.
>
> Don't get me wrong, but 22*3,5 cm this is not THAT big :-)

Well, sure, it doesn't compare to your LEDMatrix, but to be correct:
it has a 22.6x4.3 cm viewing area, which still beats the usual case-modders 
4x20 lcd hands down.

> > Interfacing it seems a bit of troublesome, as it doesn't contain a
> > framebuffer, so all data has to be sent continuosly.
>
> So does the ledmatrix display, so you might be able to do something
> similar to its driver. 400 x  64 is 25600 pixels which in turn is 3200
> bytes. This does not fit into the memory of any of the small avrs,
> so you either use a mega128 (with 4k ram) or use an external ram.

Yeah, probably some sram chip from an old '286 Mainboard, got plenty of those 
left.
Then probably a pic18f4550, maybe ATMega16.

With enough ram it would also be possible to implement two different greys.
Keep two framebuffers, display them alternating, keep one "on screen" a little 
longer than the other (If the display timings allow that)


> Ciao,
>   Till
>
> I just returned from the IFA fair and LG as well as the german Telekom
> hat some very funny presents: Small fans that have 7 leds on one of
> the two wings and display some text while running. I'd really love to
> build one of those and make a lcd4linux driver for them. DIY instructions
> for similar devices can easily be found with google when searching for
> led rotor display or similar. E.g.:
> http://hackedgadgets.com/2006/06/13/top-5-spinning-led-displays/

That "sounds" like a cool hack. Will probably be the loudest display ever 
connected to lcd4linux ;)


/Ernst

Re: [Lcd4linux-devel] [lcd4linux] Sharp LM40001G LCD

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

Hi,

400*64 pixels is quite nice. Under lcd4linux this would basically
be a 66*8 character display.

> Maybe some of you also have interrest in a cheap size-DOES-matter Graphic
> LCD, so we could share some of the development work.
Don't get me wrong, but 22*3,5 cm this is not THAT big :-)

> Interfacing it seems a bit of troublesome, as it doesn't contain a
> framebuffer, so all data has to be sent continuosly.
So does the ledmatrix display, so you might be able to do something
similar to its driver. 400 x  64 is 25600 pixels which in turn is 3200
bytes. This does not fit into the memory of any of the small avrs,
so you either use a mega128 (with 4k ram) or use an external ram.

Ciao,
  Till

I just returned from the IFA fair and LG as well as the german Telekom
hat some very funny presents: Small fans that have 7 leds on one of
the two wings and display some text while running. I'd really love to
build one of those and make a lcd4linux driver for them. DIY instructions
for similar devices can easily be found with google when searching for
led rotor display or similar. E.g.:
http://hackedgadgets.com/2006/06/13/top-5-spinning-led-displays/

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

[Lcd4linux-devel] Introducing myself

[Reinhard T. <sir...@ta...>]

Hello fellow lcd4linux hackers,

I'd like to introduce myself: Reinhard Tartler, I'm a student of
computer science in Germany, Erlangen. I've started to work at teamix, a
company in Nuernberg, where we use lcd4linux for a loadbalancer
appliance.

In the past, the debian packages for lcd4linux were maintained by
Norbert. Thanks for your work so far, Nobse! I'm taking over the
packages now, and try to integrate my patches upstream , which I needed
to apply to current cvs in order to get lcd4linux build in debian.

Michael kindly granted my CVS access, and I already started committing,
as you may have noticed ;)

First, I dropped the debian/ dir, see the cvs changelog for
rationale. In short: I use completely different debian scripts, and the
old files in the package do cause some problems (see
http://bugs.debian.org/385152 for details). If someone has problems with
that, please contact me to find a solution we can all live with.

Second, I edited drivers.m4 and configure.m4, and updated python.m4 to
ac_python_devel.m4. These patches were needed to build on my debian
system, but I'm sure they are also needed on other distributions. In
order to make them 'active', I needed to rerun bootstrap and trigger the
autotools toolchain.

These commits are a bit critical, but I don't expect any breakage. If
I broke something, I apologize, just blame me and tell what got
broken.

So keep on happy hacking! :)

=2D-=20
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Re: [Lcd4linux-devel] [lcd4linux] Inappropriate ioctl for device (?)

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

Hi Till,

> BTW: Michi, the display arrived today and i am still
> working on my part of our deal!

fine, but take your time. I've been at Conrad on saturday, and guess
what: I got none of the components I need.... and I don't know how to
wind the inductor.... luckily I've got a customer who deals with such
stuff, which I'm going to visit this week.


bye, Michael

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

Re: [Lcd4linux-devel] [lcd4linux] Inappropriate ioctl for device (?)

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

Hi,

On Monday 28 August 2006 09:09, tasos wrote:
> Any ideas please?i have to make it work!
> > [KVV] Using station 89

I really don't know anything about your LCD, but i 
really like the fact that you seem to be using the KVV
plugin. Are you from Karlsruhe?

Till

BTW: Michi, the display arrived today and i am still
working on my part of our deal!

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

Re: [Lcd4linux-devel] [lcd4linux] timer-Widget

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

Hi there,

> On Friday 18 August 2006 22:51, Michael Reinelt wrote:
>> It will work the following way: You can have a layout larger than your
>> display (e.g. 6 rows for a 4x20 displays), and you can somehow "scroll"
>> some of the rows.

> Hey, cool. That's exactly what i'd like to have for the input buttons on
> my display since it enables me to switch between different views
> automatically.
> 
> Why didn't your do it with multiple Display sections and the possibility
> to switch between them? This would be more intuitive, i think ...

You are talking about "Layout" sections, don't you?

This will be another possibility. I'm planning a plugin whioch can
change the current layout to another one. But this will be not that
easy, because the current code wasn't designed to "close" a layout. I'm
afraid there will be lots of unwanted side-effects (orphaned timers,
memory leaks, ...)

Another idea is to use the layers. This would solve the "normal display
interrupted by a phone call" issue.

One would use the normal layout on layer 1, and place the ISDN widgets
on layer 2, but make layer 2 invisible. Whenever a call happens, layer 2
will be made visible for some time (and will overlay layer 1, hiding the
widgets placed there)


bye, Michael

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

Re: [Lcd4linux-devel] [lcd4linux] timer-Widget

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

Hi,

On Friday 18 August 2006 22:51, Michael Reinelt wrote:
> It will work the following way: You can have a layout larger than your
> display (e.g. 6 rows for a 4x20 displays), and you can somehow "scroll"
> some of the rows.
Hey, cool. That's exactly what i'd like to have for the input buttons on
my display since it enables me to switch between different views
automatically.

Why didn't your do it with multiple Display sections and the possibility
to switch between them? This would be more intuitive, i think ...

Till

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

Re: [Lcd4linux-devel] WRAP platform and LCD4Linux

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

Hi,

On Thursday 17 August 2006 01:10, Luis Correia wrote:
> This performance comes with a price... a 6% price to be accurate.
> While my I2C approach takes about 0.0% of CPU time (analysed with top),
> the USB variant eats something from 5 to 6.4% of CPU time.
>
> This doesn't seem much for a server, but it is a lot to a 266Mhz router.

I wonder why this is. The usb on modern systems is nearly completely done 
in hardware and shouldn't have a significant impact on cpu load. How are you 
doing the i2c stuff? Bitbanging on the printer port is usually way more cpu 
stressing than usb. The cpu bandwidth consumed will probably relate to the 
number of LCD screen accesses you do. You might e.g. try to reduce some of 
your update settings in the lcd4linux.conf to slow down redraws etc.

Ciao,
  Till

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

Re: [Lcd4linux-devel] WRAP platform and LCD4Linux

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

Hi! 

> -----Original Message-----
> From: Stefan Krister [mailto:ste...@cr...] 
> Sent: Thursday, August 17, 2006 12:47 PM
> To: lcd4linux devel
> Subject: Re: [Lcd4linux-devel] WRAP platform and LCD4Linux
> 
> Hi Luis,
> 
> Luis.F.Correia schrieb am 17.08.2006 11:07:
> >
> > It reports 74mA to the USB hub.
> 
> That seems to be O.K.
> 
> > Ok, this would be a good project, I think. I can help you with the 
> > GPIO think, but only for 2.4 kernels. Still interested?
> 
> Fine! *eg*
> 
> Yes sure I am. To my knowledge for now - there are only 
> outb() neccesary to put data on the GPIOs. And before using 
> the GPIO there has a) to switch off the "LPC" behaviour of 
> the J2 and to b) set in- or out-direction of the GPIO pins. 
> All that is done by outb().
> 
> I found 2 examples from other WRAP users doing some stuff 
> (switches and some optocoupled relais):
> 
> http://wiki.voyage.hk/dokuwiki/doku.php?id=wrap_switches
> http://list.voyage.hk/pipermail/voyage-linux/2006-June/000969.html
> 
> I found there code is handy for the a) part. And there is no 
> special kernel issue.

Yes it is, an outb() must be done by root and in systems with the
grsecurity patches (Bering uClibc) it won't work from a userspace
application.

Even so, a simple kernel module mimicing the parport behaviuor
should be more then enough.

I'm going to explian in further detail what this means, from lcd4linux
point of view, there is a parport device. But instead of loading 
parport, you load the wrap-gpio module. This solves the hardware issue
of using those pins as GPIO.

Then the LCD module itself is another issue. But one step at a time.

> 
> MfG
> 
> Stefan

Thanks for the links, they will help me building the required kernel module.


Luis Correia   
Bering uClibc Team Member

PGP Fingerprint: BC44 D7DA 5A17 F92A CA21 9ABE DFF0 3540 2322 21F6 
Key Server: http://pgp.mit.edu

Re: [Lcd4linux-devel] WRAP platform and LCD4Linux

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

Hi Luis,

Luis.F.Correia schrieb am 17.08.2006 11:07:
>
> It reports 74mA to the USB hub.

That seems to be O.K.

> Ok, this would be a good project, I think. I can help you with the
> GPIO think, but only for 2.4 kernels. Still interested?

Fine! *eg*

Yes sure I am. To my knowledge for now - there are only outb() neccesary
to put data on the GPIOs. And before using the GPIO there has a) to switc=
h
off the "LPC" behaviour of the J2 and to b) set in- or out-direction of
the GPIO pins. All that is done by outb().

I found 2 examples from other WRAP users doing some stuff (switches and
some optocoupled relais):

http://wiki.voyage.hk/dokuwiki/doku.php?id=3Dwrap_switches
http://list.voyage.hk/pipermail/voyage-linux/2006-June/000969.html

I found there code is handy for the a) part. And there is no special
kernel issue.

MfG

Stefan

Re: [Lcd4linux-devel] WRAP platform and LCD4Linux

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

Hi, 

> -----Original Message-----
> From: Stefan Krister [mailto:ste...@cr...] 
> > Everything is powered via the USB port and the LCD does have a LCD 
> > backlight.
> 
> O.K. - how much current does it consume?

It reports 74mA to the USB hub.

> > If you want my advice do this, get a standard 7805 voltage 
> regulator, 
> > remove the SMD one (near the power supply behind the minipci socket 
> > card and solder there the wires. Then get a good heatsink 
> and away you go.
> 
> I do not want to directly solder on the WRAP. Nor do the 
> other WRAP users in the fli4l community want to directly 
> solder on the WRAP. The most of them don't have the USB 
> expansion - as a consequence not wanting to solder ...

Ok, while i do not advise the community to change the SMD 7805, the
USB port is a good addition.

But I do understand your concerns.

> I'm trying all the possibillities - I2C, USB and GPIO for the 
> community, not for myself alone. And I'll publish my 
> experiences to give everybody out there the chance to take 
> the best option for themself.
> 
> I'm dreaming on a small PCB, plugged head-over onto the J2 
> (LPC-Expansion), having all needed datalines, a 
> contrast-potentiometer and a (5V) voltage-booster connected 
> to the front-lcd in my enclosure. I wish this dream comes 
> true. And this would be the easiest way to have a LCD 
> connected to a (unsoldered) WRAP - and maybe there are 
> solderers out there which sell ready made PCBs for the community.

Ok, this would be a good project, I think. I can help you with the
GPIO think, but only for 2.4 kernels. Still interested?

> >> 1st - programming the Atmel is a problem for anybody out there who 
> >> hasn't to do anything with Atmels before.
> >
> > It isn't if you can get them already programmed.
> 
> Yes. I hope, Till helps me out of this problem.
> 
> >> 2nd - using GPIO on WRAP enables the possibility to put the LCD in 
> >> the WRAP enclosure. O.K. not into the original one - but 
> my enclosure 
> >> has enough room on the front to put a 16x2 LCD in.
> >
> > Not really, although i've chosen to have mine externally, 
> it would fit 
> > in any enclosure that is bigger then the original (which to 
> me is kind 
> > of useless since you can't even remove the CF card without 
> having to 
> > unscrew the board...)
> 
> I've a Powertip PC1602-E (measures 66mm x 23mm, datasheet:
> http://www.powertipusa.com/pdf/pc1602e.pdf ) - it will fit 
> into my front panel. Stay tuned, this week I'll order new 
> panels with cutouts for that LCD.
> 
> > As you wish, Lcd4linux is working perfectly with LCD2USB 
> and I2C, no 
> > need to make any further programming.
> 
> Sorry Luis, as mentioned weeks before, the DOG-M modules need 
> special initializing. And they have software controlled 
> contrast-settings. I want to make this modules usable by 
> lcd4linux - not for I2C alone.

Well, i can't really help, as I don't have any DOG-M module.
Send me a PM about this, please.

Luis

Re: [Lcd4linux-devel] WRAP platform and LCD4Linux

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

Hi Luis,

Luis.F.Correia schrieb am 17.08.2006 09:59:
>
>> Fine! You are driving the PCB and the LCD from USB? Or do you
>> have a seperate voltage feed?
>
> Everything is powered via the USB port and the LCD does have a LCD
> backlight.

O.K. - how much current does it consume?

> If you want my advice do this, get a standard 7805 voltage regulator,
> remove the SMD one (near the power supply behind the minipci socket
> card and solder there the wires. Then get a good heatsink and away you =
go.

I do not want to directly solder on the WRAP. Nor do the other WRAP users
in the fli4l community want to directly solder on the WRAP. The most of
them don't have the USB expansion - as a consequence not wanting to solde=
r
...

I'm trying all the possibillities - I2C, USB and GPIO for the community,
not for myself alone. And I'll publish my experiences to give everybody
out there the chance to take the best option for themself.

I'm dreaming on a small PCB, plugged head-over onto the J2
(LPC-Expansion), having all needed datalines, a contrast-potentiometer an=
d
a (5V) voltage-booster connected to the front-lcd in my enclosure. I wish
this dream comes true. And this would be the easiest way to have a LCD
connected to a (unsoldered) WRAP - and maybe there are solderers out ther=
e
which sell ready made PCBs for the community.

> How are you powering your WRAP? I mean how much voltage you are supplyi=
ng?

Don't know exactly ... 7.5V or 9V.

>> 1st - programming the Atmel is a problem for anybody out
>> there who hasn't to do anything with Atmels before.
>
> It isn't if you can get them already programmed.

Yes. I hope, Till helps me out of this problem.

>> 2nd - using GPIO on WRAP enables the possibility to put the
>> LCD in the WRAP enclosure. O.K. not into the original one -
>> but my enclosure has enough room on the front to put a 16x2 LCD in.
>
> Not really, although i've chosen to have mine externally, it would
> fit in any enclosure that is bigger then the original (which to me
> is kind of useless since you can't even remove the CF card without
> having to unscrew the board...)

I've a Powertip PC1602-E (measures 66mm x 23mm, datasheet:
http://www.powertipusa.com/pdf/pc1602e.pdf ) - it will fit into my front
panel. Stay tuned, this week I'll order new panels with cutouts for that
LCD.

> As you wish, Lcd4linux is working perfectly with LCD2USB and I2C,
> no need to make any further programming.

Sorry Luis, as mentioned weeks before, the DOG-M modules need special
initializing. And they have software controlled contrast-settings. I want
to make this modules usable by lcd4linux - not for I2C alone.

MfG

Stefan

Re: [Lcd4linux-devel] WRAP platform and LCD4Linux

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

Hi there Stefan,

> -----Original Message-----
> From: Stefan Krister [mailto:ste...@cr...] 
> Sent: Thursday, August 17, 2006 8:08 AM
> To: lcd4linux devel
> Subject: Re: [Lcd4linux-devel] WRAP platform and LCD4Linux
> 
> Hi Luis,
> 
> Luis Correia schrieb am 17.08.2006 01:10:
> >
> > For the newer kernels, things were a lot easier, and there was a 
> > scx200_acb driver which seems to work perfectly ok with it 
> (i haven't 
> > tested it myself).
> 
> My prototype is finished and I start working on the code 
> today. I'm also using uclibc and kernel 2.6 with fli4l.
> 
> > This was all fine until Till Harbaum released his LCD2USB.
> 
> Yes cool work! I would have ordered such a PCB if there is a 
> possibility not to upload the firmware by myself. I do not 
> want to order or solder a programmer for this one-time job. 
> Or are there changes in the firmware expected?
> 
> @Till - is it possible to order both a PCB and an already 
> programmed Atmega? If so, please tell me the details (price, 
> bank account ...) and i will transfer the money asap to you.

I can answer this one, if Till still has PCB's maybe he can get you 
an already programmed AVR. I had the same problem as you did,
although for other reasons i will now make my own programmer as well.

> 
> > After having assembled the components in the PCB (while 
> almost frying 
> > an LCD module), I was absolutely amazed of how well it is 
> working with 
> > the same WRAP board. The same lcd4linux.conf file produced such an 
> > incredible different results, with this new interface!!! Light years
> faster!
> 
> Fine! You are driving the PCB and the LCD from USB? Or do you 
> have a seperate voltage feed?

Everything is powered via the USB port and the LCD does have a LCD
backlight.

If need be, you could hack the WRUSB.1A and provide external +5v
though it. http://www.pcengines.ch/wrusb.htm

I have this voltage available in my own enclosure (an external
tape drive case) but it doesn't seem necessary for now. It will be however
when I assemble my two LCD's (20x2) enclosure, so that I can closely
monitor whatever happens on the router.

> 
> For my GPIO experiments I ordered some MAX619/MAX1682/MAX1683.

If you want my advice do this, get a standard 7805 voltage regulator,
remove the SMD one (near the power supply behind the minipci socket
card and solder there the wires. Then get a good heatsink and away you go.

How are you powering your WRAP? I mean how much voltage you are supplying?
 
> > I do however strongly recommend the LCD2USB interface for 
> those that 
> > still want to invest some time with WRAP. (no Stefan, don't waste 
> > anytime reprogramming the GPIO pins, it's worthless)
> 
> I don't tink so.
> 1st - programming the Atmel is a problem for anybody out 
> there who hasn't to do anything with Atmels before.

It isn't if you can get them already programmed.

> 2nd - using GPIO on WRAP enables the possibility to put the 
> LCD in the WRAP enclosure. O.K. not into the original one - 
> but my enclosure has enough room on the front to put a 16x2 LCD in.

Not really, although i've chosen to have mine externally, it would
fit in any enclosure that is bigger then the original (which to me 
is kind of useless since you can't even remove the CF card without
having to unscrew the board...)

> 3rd - my programming skills arn't as good as they should be. 
> It's a good project to increase them.

This is a good reason :

> 4th - there is our own fli4l-lcd package (much older than 
> lcd4linux I think). I think that implementing GPIO into that 
> tiny thing is much easier for me than starting to do that 
> with lcd4linux.

As you wish, Lcd4linux is working perfectly with LCD2USB and I2C,
no need to make any further programming.

But if you insist, i must point you again to Martin Hejl's driver
for the GPIO's on a Soekris board. (http://soekris.helj.de)

> 
> So please let me try.
> 
> MfG
> 
> Stefan

Knock yourself out.



Luis Correia   
Bering uClibc Team Member

PGP Fingerprint: BC44 D7DA 5A17 F92A CA21 9ABE DFF0 3540 2322 21F6 
Key Server: http://pgp.mit.edu

Re: [Lcd4linux-devel] WRAP platform and LCD4Linux

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

Hi Luis,

Luis Correia schrieb am 17.08.2006 01:10:
>
> For the newer kernels, things were a lot easier, and there was a
> scx200_acb driver which seems to work perfectly ok with it (i haven't
> tested it myself).

My prototype is finished and I start working on the code today. I'm also
using uclibc and kernel 2.6 with fli4l.

> This was all fine until Till Harbaum released his LCD2USB.

Yes cool work! I would have ordered such a PCB if there is a possibility
not to upload the firmware by myself. I do not want to order or solder a=20
programmer for this one-time job. Or are there changes in the firmware
expected?

@Till - is it possible to order both a PCB and an already programmed
Atmega? If so, please tell me the details (price, bank account ...) and i
will transfer the money asap to you.

> After having assembled the components in the PCB (while almost frying a=
n
> LCD module), I was absolutely amazed of how well it is working with the
> same WRAP board. The same lcd4linux.conf file produced such an
> incredible different results, with this new interface!!! Light years
faster!

Fine! You are driving the PCB and the LCD from USB? Or do you have a
seperate voltage feed?

For my GPIO experiments I ordered some MAX619/MAX1682/MAX1683.

> I do however strongly recommend the LCD2USB interface for those that
> still want to invest some time with WRAP. (no Stefan, don't waste
> anytime reprogramming the GPIO pins, it's worthless)

I don't tink so.
1st - programming the Atmel is a problem for anybody out there who hasn't
to do anything with Atmels before.
2nd - using GPIO on WRAP enables the possibility to put the LCD in the
WRAP enclosure. O.K. not into the original one - but my enclosure has
enough room on the front to put a 16x2 LCD in.
3rd - my programming skills arn't as good as they should be. It's a good=20
project to increase them.
4th - there is our own fli4l-lcd package (much older than lcd4linux I
think). I think that implementing GPIO into that tiny thing is much easie=
r
for me than starting to do that with lcd4linux.

So please let me try.

MfG

Stefan

Re: [Lcd4linux-devel] New display: LEDMATRIX

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

> These functions are missing:
> 
> drv_LCD2USB.c:
> 476: undefined reference to `drv_generic_keypad_press'
> 632: undefined reference to `drv_generic_keypad_real_press'
> 660: undefined reference to `drv_generic_keypad_init'
> 693: undefined reference to `drv_generic_keypad_quit'
> 780: undefined reference to `thread_destroy'

Thanks for the hint. A reference to drv_generic_keypad was missing in
drivers.m4 (I should run the smoketest.sh more often :-)

Fixed in CVS.

bye, Michael

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

[Lcd4linux-devel] WRAP platform and LCD4Linux

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

Hi!

as most of you know, i'm half of the team that brought a largely 
undocumented I2C-HD44780 driver to LCD4Linux (l4l).

Until now, my experiments were less then satisfactory, but up to some 
extent, I could honestly say that l4l did in fact work with the I2C driver.

With the 2.4 series kernel, a lot of tweaking was needed in order to 
make the special AccessBus driver to compile and load properly.

For the newer kernels, things were a lot easier, and there was a 
scx200_acb driver which seems to work perfectly ok with it (i haven't 
tested it myself).

But still, the results were less then perfect.

This was all fine until Till Harbaum released his LCD2USB.

After having assembled the components in the PCB (while almost frying an 
LCD module), I was absolutely amazed of how well it is working with the 
same WRAP board. The same lcd4linux.conf file produced such an 
incredible different results, with this new interface!!! Light years faster!

This performance comes with a price... a 6% price to be accurate.
While my I2C approach takes about 0.0% of CPU time (analysed with top), 
the USB variant eats something from 5 to 6.4% of CPU time.

This doesn't seem much for a server, but it is a lot to a 266Mhz router.


Conclusions (this is getting toooo looooooong):

I will probable just write a WIKI page describing the I2C LCD interface. 
The code is probably not going to get much more additions, no 8bit 
interface, no other fancy stuff.

I do however strongly recommend the LCD2USB interface for those that 
still want to invest some time with WRAP. (no Stefan, don't waste 
anytime reprogramming the GPIO pins, it's worthless)

It costs a bit extra, as I recomment that you buy the USB extension 
board (it has some ESD protection for the CPU) and buy (or build) the 
LCD2USB circuit from Till Harbaum.


Be good to each other, be happy!

Luis Correia
Bering uClibc team member,
LCD4Linux developer

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

Re: [Lcd4linux-devel] New display: LEDMATRIX

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

Till Harbaum wrote:
> Hi,
> 
> lcd4linux now has a KVV plugin. It is inly useful to you if you live
> in Karlsruhe, Germany. But if you do you can now display the
> train departure times of any given train station in realtime just
> as displayed on the real displays at the stations.
> 
> Till
> 

Hi!

I've checked out CVS but it has some errors... maybe I done something 
wrong here?

drv_LCD2USB.o: In function `drv_L2U_timer':
/opt/buildtool/source/lcd4linux/lcd4linux-0.10.0/drv_LCD2USB.c:476: 
undefined reference to `drv_generic_keypad_press'
drv_LCD2USB.o: In function `drv_L2U_init':
/opt/buildtool/source/lcd4linux/lcd4linux-0.10.0/drv_LCD2USB.c:632: 
undefined reference to `drv_generic_keypad_real_press'
/opt/buildtool/source/lcd4linux/lcd4linux-0.10.0/drv_LCD2USB.c:660: 
undefined reference to `drv_generic_keypad_init'
drv_LCD2USB.o: In function `drv_L2U_quit':
/opt/buildtool/source/lcd4linux/lcd4linux-0.10.0/drv_LCD2USB.c:693: 
undefined reference to `drv_generic_keypad_quit'
plugin_kvv.o: In function `plugin_exit_kvv':
/opt/buildtool/source/lcd4linux/lcd4linux-0.10.0/plugin_kvv.c:780: 
undefined reference to `thread_destroy'
collect2: ld returned 1 exit status

These functions are missing:

drv_LCD2USB.c:
476: undefined reference to `drv_generic_keypad_press'
632: undefined reference to `drv_generic_keypad_real_press'
660: undefined reference to `drv_generic_keypad_init'
693: undefined reference to `drv_generic_keypad_quit'
780: undefined reference to `thread_destroy'

Since I really want to test my LCD2USB today, i'll just comment out 
these offending functions from my local copy.

Ah, as a reminder, i'm cross-compiling it for uClibc.

Luis




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

Re: [Lcd4linux-devel] [lcd4linux] LCD4linux with graphical display

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

Hi,

On Wednesday 16 August 2006 22:17, Harald Krummenauer wrote:
> one thing is that after a while there apears some pixels across the
> display. would be nice if you can fix this. or have only me this problem ?
Do you operate the display on your printer port? I know that these 
displays sometimes need an accurate timing and that you cannot
always guarantee this using the printerport with long cables and the
like. So perhaps it's just transmission errors you see on your screen.

Till

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

Re: [Lcd4linux-devel] New display: LEDMATRIX

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

Hi,

lcd4linux now has a KVV plugin. It is inly useful to you if you live
in Karlsruhe, Germany. But if you do you can now display the
train departure times of any given train station in realtime just
as displayed on the real displays at the stations.

Till

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