Menu
▾
▴
lcd4linux-devel — lcd4linux development team
You can subscribe to this list here.
| 2004 |
Jan
(57) |
Feb
(71) |
Mar
(80) |
Apr
(40) |
May
(49) |
Jun
(20) |
Jul
(3) |
Aug
(9) |
Sep
(8) |
Oct
(2) |
Nov
|
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(10) |
Feb
(25) |
Mar
(24) |
Apr
(26) |
May
(71) |
Jun
(35) |
Jul
(5) |
Aug
(3) |
Sep
(18) |
Oct
(4) |
Nov
(5) |
Dec
(2) |
| 2006 |
Jan
(50) |
Feb
(12) |
Mar
(7) |
Apr
(24) |
May
(1) |
Jun
(17) |
Jul
(51) |
Aug
(38) |
Sep
(38) |
Oct
(33) |
Nov
(8) |
Dec
(13) |
| 2007 |
Jan
(44) |
Feb
(25) |
Mar
(21) |
Apr
(68) |
May
(52) |
Jun
(24) |
Jul
(17) |
Aug
(12) |
Sep
(4) |
Oct
(14) |
Nov
(1) |
Dec
(3) |
| 2008 |
Jan
(9) |
Feb
(1) |
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
(5) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(4) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(21) |
Jun
(5) |
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
| 2010 |
Jan
(15) |
Feb
(36) |
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(3) |
| 2011 |
Jan
(22) |
Feb
(2) |
Mar
(2) |
Apr
(1) |
May
(2) |
Jun
|
Jul
(25) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2012 |
Jan
(14) |
Feb
(6) |
Mar
(20) |
Apr
(12) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(1) |
May
(9) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(11) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Paul K. <pau...@xs...> - 2006-01-26 08:26:59
|
Good news Till! That is very nice of ftdi. In general their support is very good. We used to have issues with their virtual comport USB chips. But they provided lots of help on solving those. Paul Till Harbaum wrote: >Hi, > >i got a set of 8 pids (usb product ids) from ftdi. Very cool ... so the >lcd2usb will have its own product id 0x0403/0xc630 :-) > >Till > > > |
|
From: Till H. <ti...@ha...> - 2006-01-25 21:23:26
|
Hi, i got a set of 8 pids (usb product ids) from ftdi. Very cool ... so the lcd2usb will have its own product id 0x0403/0xc630 :-) Till -- Dr.Ing. Till Harbaum <ti...@ha...> http://www.harbaum.org/till |
|
From: Till H. <ti...@ha...> - 2006-01-24 21:39:31
|
Hi, the schematics are finished and the pcb layout as well. The device will be able to support two controllers (e.g. a 4*40 display), provides software controlled contrast and backlight, has two input buttons and supports the two most common connectors incl. the weird setup of the 4x40 displays (why do these have vcc and gnd exchanged?). I am currently trying to get a real usb vendor id. If someone of you is working for a company owning a usb vendor id, i'd love to get a device id for my device. I'll even add a link to your company to my web page ... The device is currently BWCT compatible, but i'll write a new protocol that supports all my additional features and is about four times faster. I am currently writing a new lcd4linux driver for it. Regards, Till -- Dr.Ing. Till Harbaum <ti...@ha...> http://www.harbaum.org/till |
|
From: Till H. <ti...@ha...> - 2006-01-21 17:36:32
|
Hi, i have started the project web page at http://www.harbaum.org/till/lcd2usb There's much there yet, but the prototype shot and the current schematic are already there. On Saturday 21 January 2006 16:44, Luis.F.Correia wrote: > > ?? You can buy the mega8 really everywhere ... > Do you really think so? at what price? The Atmega8 goes for around EUR 2.70 > From what i know here in Portugal, the situation regarding > local hardware parts shops for hobbyists is less then perfect. I usually order them online. Shipping may be expensive for a single mega8, but i ordered a nice blue 4*20 lcd as well ... with white backlight :-) > So is you could also provide them (optionally) I would be very > thankfull... This should be possible .. Regards, Till -- Dr.Ing. Till Harbaum, ti...@ha... http://www.harbaum.org/till |
|
From: Luis.F.Correia <Lui...@se...> - 2006-01-21 15:44:54
|
Hi!=20 > -----Original Message----- > From: Till Harbaum [mailto:ti...@ha...]=20 > Sent: Saturday, January 21, 2006 3:40 PM > To: lcd...@li... > Cc: Luis.F.Correia > Subject: Re: [Lcd4linux-devel] USB based hd44780 units ... >=20 > Hi, >=20 > On Saturday 21 January 2006 15:31, Luis.F.Correia wrote: > > But it is normally very hard to find those type of AVR=20 > microcontrollers. > > I wonder if you can also supply those 'hard-to-get' parts ;) > ?? You can buy the mega8 really everywhere ... Do you really think so? at what price? From what i know here in Portugal, the situation regarding local hardware parts shops for hobbyists is less then perfect. Microcontrollers are a hard beast to get... For example, when i went shopping for an AVR 8515, i had to almost force them to make a back order and it cost me 12=E2=82=AC (yes, twelve = euro). So is you could also provide them (optionally) I would be very thankfull... Cheers, Luis Correia =20 |
|
From: Till H. <ti...@ha...> - 2006-01-21 15:40:12
|
Hi, On Saturday 21 January 2006 15:31, Luis.F.Correia wrote: > But it is normally very hard to find those type of AVR microcontrollers. > I wonder if you can also supply those 'hard-to-get' parts ;) ?? You can buy the mega8 really everywhere ... Till -- Dr.Ing. Till Harbaum, ti...@ha... |
|
From: Luis.F.Correia <Lui...@se...> - 2006-01-21 14:31:49
|
Hi! > -----Original Message----- > From: Till Harbaum [mailto:ti...@ha...] > > I wonder if i'd produce a small set of industry quality pcbs. > They should be about $5 each. Is anyone interested? It sounds great and i'll be also interested. But it is normally very hard to find those type of AVR microcontrollers. I wonder if you can also supply those 'hard-to-get' parts ;) Luis Correia |
|
From: Nico W. <nic...@po...> - 2006-01-21 11:15:06
|
Hi Till, >> I wonder if i'd produce a small set of industry quality pcbs. They >> should be about $5 each. Is anyone interested? > I AM, I AM, I AM!! I am interested too ;-) Bye, Nico |
|
From: Michael R. <re...@eu...> - 2006-01-21 10:56:13
|
Hi Till, > the first prototype is working now: > > http://www.harbaum.org/till/prototyp.jpg Hey, great! > I wonder if i'd produce a small set of industry quality pcbs. They > should be about $5 each. Is anyone interested? I AM, I AM, I AM!! And I need a schematics, and, most important, a part list. I'm afraid I have to visit Conrad today :-( (I hope my girlfriend doesn't notice) bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2006-01-21 10:47:04
|
Hi, > There's a nice project to do software bit-banging usb with atmel avrs > (http://www.obdev.at/products/avrusb/index.html). I had a look at this stuff, sonds very interesting! I don't know much about USB and/or AVR, but I read that things are very timing-critical. Looks like the 12MHz of the AVR are very tight, one has to use every single available cycle just to read the bits from USB. I wonder how the AVR shoud handle the display, too? > I do understand, that the other usb adaptors are sold with few different > display types only. But i'd like to use as much different display as the > generic hd44780 driver does. I am still not convinced, that having a > seperate > usb driver doing much of the same things the generic driver does (e.g. > adopting the addressing scheme for 16 col displays) is a clever thing ... See my other mail. I agree with you. But I'm still unhappy with the complexity of drv_HD44780.c There are so many things which are used with the parport only (4/8 bit mode, busy-flag checking, all the timing stuff, ....) For the development of the hardware, I suggest using a seperate driver like the BWCT. If we know that the hardware and the driver work, we can integrate it into the HD44780 driver. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Till H. <ti...@ha...> - 2006-01-21 10:38:48
|
Hi, the first prototype is working now: http://www.harbaum.org/till/prototyp.jpg It can be used with the current bwct driver from lcd4linux. As you can see, i am using it with a 4*20 lcd. Software contrast works as well. I still have to add support for the backlight and a second controller, but despite that, the concept is working. I wonder if i'd produce a small set of industry quality pcbs. They should be about $5 each. Is anyone interested? Regards, Till -- Dr.Ing. Till Harbaum, ti...@ha... |
|
From: Michael R. <re...@eu...> - 2006-01-21 10:38:08
|
Hi Paul, >> Nice to hear from you again! > Alive and kicking :-) Just have been a bit busy in the last months. Mee too. With being father, 'busy' gets a new dimension :-) >> #1: I don't speak C++ > You know it is not too late. You can still learn C++ ;-) Hmmm.... or C-flat (or was it sharp? something with music :-) >> #2: embedded systems, ucLinux et al may lack a C++ runtime environment > Good point here. Although I am not sure how many embedded platforms are > with C++ environments these days. Don't know about ucLinux, but don't > these use GCC? So I am sure what would be missing. They to use gcc, but don't have the libstdc++ installed IIRC. > Well never mind. C is fine too I think so, too. > I'll see if I can dig up my button handling that I did in the past. That > worked well. Would be great! bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2006-01-21 10:38:08
|
Hi there, > I have to look into the BWCT driver, to see what makes > it special. But for the I2C interface we created additional support next > to the parallel port implementation. My guess would be that for USB > something similar would happen. Okay, guys, consider me being convinced :-) I agree there should be a 'drv_generic_usb' backend, which can be used in the HD44780 driver, too. But there will be some issues with the autoconf stuff again... (did I mention that I *love* autoconf?) Another possibility would be to create a generic HD44780 backend, which could be used by different drivers.... so there would be two (or three) HD44780 drivers: one for parport, one for i2c, and some for USB. What I really dislike is the complexity of the drv_HD44780.c file. And I suppose complexity will increase again if we add another bus type... One of the 'special' things with the BWCT driver is the strange display detection. The reason is that there are different BWCT interfaces, sometimes there's a different interface class or something.... I remember a discussion with Bernd from BWCT about this... bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Paul K. <pau...@xs...> - 2006-01-20 16:38:41
|
Hi Till, I had a very quick look at it. It looks like a very nice and simple solution indeed. I have to look into the BWCT driver, to see what makes it special. But for the I2C interface we created additional support next to the parallel port implementation. My guess would be that for USB something similar would happen. Looking forward to your results, Paul li...@ha... wrote: >Hi, > > --- Ursprüngliche Nachricht --- >Datum: 20.01.2006 16:43 >Von: Paul Kamphuis <pau...@xs...> > > >>Till, I really like the idea of a $5 DIY USB interface for a HD44780. >>What are you planning on using? >> >> >There's a nice project to do software bit-banging usb with atmel avrs >(http://www.obdev.at/products/avrusb/index.html). I flashed the sensor >example code onto one of my atmega8 demo boards and it was immediately >recognized by my pc. It should be quite simple to add 4 bit lcd interface >to this. The firmware doesn't need to know much about the display, since >the bwct driver sends the hd44780 commands via usb. I'll only have to do >some small tests to e.g. prevent the pc from switching the display into >8bit mode. Other than that i can just forward any command directly to the >display. I am planning to allow for two controllers and make contrast and >backlighting configurable via usb. Only few parts will be needed besides >the avr itself. Even the 40mA for the backlight leds may be driven >directly >by the avr. The whole device is meant to be open source/open hardware, so >you can start heating up the soldering irons ... > >The whole device will not be 100% usb compliant. The soft-usb >implementation >does not allow for all the necessary crc checks and the like and the >final >device will not meet the usb spec regarding power consumption etc. But it >should work good enough for most applications. > >I do understand, that the other usb adaptors are sold with few different >display types only. But i'd like to use as much different display as the >generic hd44780 driver does. I am still not convinced, that having a >seperate >usb driver doing much of the same things the generic driver does (e.g. >adopting the addressing scheme for 16 col displays) is a clever thing ... > >Ciao, > Till > > > > > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://sel.as-us.falkag.net/sel?cmd_______________________________________________ >Lcd4linux-devel mailing list >Lcd...@li... >https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel > > > > > |
|
From: Paul K. <pau...@xs...> - 2006-01-20 16:22:54
|
Michael Reinelt wrote: >Hi Paul, > >Nice to hear from you again! > > Alive and kicking :-) Just have been a bit busy in the last months. >There are two quite simple reasons: > >#1: I don't speak C++ > > You know it is not too late. You can still learn C++ ;-) >#2: embedded systems, ucLinux et al may lack a C++ runtime environment > > > Good point here. Although I am not sure how many embedded platforms are with C++ environments these days. Don't know about ucLinux, but don't these use GCC? So I am sure what would be missing. Well never mind. C is fine too >Hey, you're asking the Forbidden Question :-) >I'm currently finishing the GPO support (just one driver left), next >will be 'virtual rows' (scrolling, should be quite simple), and after >that I'm going to work on key support. > > Sounds good >The main problem is software design. I'm still not sure how keys should >be handled best. But any ideas are very welcome! > > > I'll see if I can dig up my button handling that I did in the past. That worked well. Bye, Paul |
|
From: <li...@ha...> - 2006-01-20 16:16:51
|
Hi, --- Urspr=FCngliche Nachricht --- Datum: 20.01.2006 16:43 Von: Paul Kamphuis <pau...@xs...> > Till, I really like the idea of a $5 DIY USB interface for a HD44780. > What are you planning on using? There's a nice project to do software bit-banging usb with atmel avrs (http://www.obdev.at/products/avrusb/index.html). I flashed the sensor example code onto one of my atmega8 demo boards and it was immediately recognized by my pc. It should be quite simple to add 4 bit lcd interface to this. The firmware doesn't need to know much about the display, since the bwct driver sends the hd44780 commands via usb. I'll only have to do some small tests to e.g. prevent the pc from switching the display into 8bit mode. Other than that i can just forward any command directly to the display. I am planning to allow for two controllers and make contrast and backlighting configurable via usb. Only few parts will be needed besides the avr itself. Even the 40mA for the backlight leds may be driven directly by the avr. The whole device is meant to be open source/open hardware, so you can start heating up the soldering irons ... The whole device will not be 100% usb compliant. The soft-usb implementation does not allow for all the necessary crc checks and the like and the final device will not meet the usb spec regarding power consumption etc. But it should work good enough for most applications. I do understand, that the other usb adaptors are sold with few different display types only. But i'd like to use as much different display as the generic hd44780 driver does. I am still not convinced, that having a seperate usb driver doing much of the same things the generic driver does (e.g. adopting the addressing scheme for 16 col displays) is a clever thing ... Ciao, Till |
|
From: Michael R. <re...@eu...> - 2006-01-20 16:09:27
|
Hi Paul, Nice to hear from you again! > This question did trigger something that was on the back of mind for a > long time already. Is there a reason why you don't use C++ for > lcd4linux? That could simplify some of the problems addressed here. > Besides the structure you created in lcd4linux would map wonderfully to > an object architecture, and C++ would simplify many coding problems. There are two quite simple reasons: #1: I don't speak C++ #2: embedded systems, ucLinux et al may lack a C++ runtime environment > Second, what is the current status of the button support in lcd4linux? I > know it is planned for a long time already. But what are the problems > with it? Hey, you're asking the Forbidden Question :-) I'm currently finishing the GPO support (just one driver left), next will be 'virtual rows' (scrolling, should be quite simple), and after that I'm going to work on key support. The main problem is software design. I'm still not sure how keys should be handled best. But any ideas are very welcome! bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2006-01-20 15:59:03
|
Hi Javi, >>Very good point! As nobody complained, I'm going to change this, remove >>query() and rename queryValue() to query. > As a suggestion, I'd rename current query() to queryNumRows() or similar. Another good point. Added again, and renamed to MySQL::count(). Checked into CVS. Thanks, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Paul K. <pau...@xs...> - 2006-01-20 15:43:28
|
Hi Michael, This question did trigger something that was on the back of mind for a long time already. Is there a reason why you don't use C++ for lcd4linux? That could simplify some of the problems addressed here. Besides the structure you created in lcd4linux would map wonderfully to an object architecture, and C++ would simplify many coding problems. Second, what is the current status of the button support in lcd4linux? I know it is planned for a long time already. But what are the problems with it? Till, I really like the idea of a $5 DIY USB interface for a HD44780. What are you planning on using? cheers, Paul Michael Reinelt wrote: >Hi Till, > > > >>i have a simple question regarding some of the supported usb devices >>and their drivers. I am currently building a small and cheap (about >>$5 easy to obtain standard parts) diy usb interface for the hd44780. >> >> > >Hey, sounds great! My soldering iron is already warming up :-) > > > >>I am now wondering why drivers for similar devices (e.g. the BWCT and >> USBLCD) aren't included into the hd44780. Is there any reason these >>devices are not included as interface drivers for the generic >>hd44780? This would have the advatage, that all those special case >>handlers from this driver would be available to the usb devices as >>well. >> >> > >Well, you may be right, maybe it would be better to make all HD44780 >stuff into one driver. On the other hand, the drv_HD44780.c file looks >already complex enough to me :-) > >As the "normal" HD4470 driver uses the parallel port (and/or i2c bus), >there are some other files and libs that have to be linked in (generic >parport support, ppdev, ...). All the USB-to-HD44780 drivers don't need >this stuff, but USB support. > >Another reason for not merging the drivers is the fact that some drivers >are maintained by people who own just this specific display and/or >interface. So modifications won't interfere with other drivers. > >If you think of our "embedded customers", who don't compile a 'generic >LCD4Linux' with all drivers, but prefer a as-small-as-possible >executable with just one (small) driver included, they would not benefit >from such a 'generic' driver. > >So I'd prefer the situation as it is, with every Interface having its >own small and simple driver (as long as the interfaces don't have too >much in common) > > > >>I am thinking of making my interface compatible to the bwct (and >>perhaps add some more features like e.g. adjustable backlight and one >>or two input buttons). >> >> > >you're right, the BWCT interface has a very nice protocol: it's very >simple, doesn't have too much own intelligence, but passes through the >features the HD44780 provides. > >adjustable backlight would be cool (but take care of power >consumption!), keys would be cool, too (although not supported by >lcd4linux at the moment). If your electronics has some spare outputs (to >connect a LED or something) or inputs, I'd appreciate that, too. > >Please keep me up to date with your electronic design, as I'm really >very curious :-) > > >bye, Michael > > > |
|
From: Javi <ja...@gs...> - 2006-01-20 15:41:07
|
=2D----- El Viernes, 20 de Enero de 2006 16:37, Michael Reinelt escribi=F3:= ------ > Hi there, >=20 > >>I think queryvalue() should be renamed to query(), and the current query > >>function to 'count()' or something.... > >=20 > > I think the function 'count' ist not necessarily, you can make the same= with > > an SQL-Query like this : > >=20 > > select count(*) from whos_online; > >=20 > > this will also return the number of rows from the SQL-query. >=20 >=20 > Very good point! As nobody complained, I'm going to change this, remove > query() and rename queryValue() to query. >=20 > bye, Michael >=20 As a suggestion, I'd rename current query() to queryNumRows() or similar. Rgrds. |
|
From: Michael R. <re...@eu...> - 2006-01-20 15:37:31
|
Hi there, >>I think queryvalue() should be renamed to query(), and the current query >>function to 'count()' or something.... > > I think the function 'count' ist not necessarily, you can make the same with > an SQL-Query like this : > > select count(*) from whos_online; > > this will also return the number of rows from the SQL-query. Very good point! As nobody complained, I'm going to change this, remove query() and rename queryValue() to query. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2006-01-20 14:55:47
|
Hi Till, > i have a simple question regarding some of the supported usb devices > and their drivers. I am currently building a small and cheap (about > $5 easy to obtain standard parts) diy usb interface for the hd44780. Hey, sounds great! My soldering iron is already warming up :-) > I am now wondering why drivers for similar devices (e.g. the BWCT and > USBLCD) aren't included into the hd44780. Is there any reason these > devices are not included as interface drivers for the generic > hd44780? This would have the advatage, that all those special case > handlers from this driver would be available to the usb devices as > well. Well, you may be right, maybe it would be better to make all HD44780 stuff into one driver. On the other hand, the drv_HD44780.c file looks already complex enough to me :-) As the "normal" HD4470 driver uses the parallel port (and/or i2c bus), there are some other files and libs that have to be linked in (generic parport support, ppdev, ...). All the USB-to-HD44780 drivers don't need this stuff, but USB support. Another reason for not merging the drivers is the fact that some drivers are maintained by people who own just this specific display and/or interface. So modifications won't interfere with other drivers. If you think of our "embedded customers", who don't compile a 'generic LCD4Linux' with all drivers, but prefer a as-small-as-possible executable with just one (small) driver included, they would not benefit from such a 'generic' driver. So I'd prefer the situation as it is, with every Interface having its own small and simple driver (as long as the interfaces don't have too much in common) > I am thinking of making my interface compatible to the bwct (and > perhaps add some more features like e.g. adjustable backlight and one > or two input buttons). you're right, the BWCT interface has a very nice protocol: it's very simple, doesn't have too much own intelligence, but passes through the features the HD44780 provides. adjustable backlight would be cool (but take care of power consumption!), keys would be cool, too (although not supported by lcd4linux at the moment). If your electronics has some spare outputs (to connect a LED or something) or inputs, I'd appreciate that, too. Please keep me up to date with your electronic design, as I'm really very curious :-) bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: <li...@ha...> - 2006-01-20 13:43:46
|
Hi list,
i have a simple question regarding some of the supported usb devices and
their drivers. I am currently building a small and cheap (about $5 easy
to
obtain standard parts) diy usb interface for the hd44780. I am now
wondering why
drivers for similar devices (e.g. the BWCT and USBLCD) aren't included
into the hd44780. Is there any reason these devices are not included as
interface drivers for the generic hd44780? This would have the advatage,
that all those special case handlers from this driver would be available
to the usb
devices as well.
I am thinking of making my interface compatible to the bwct (and perhaps
add some more features like e.g. adjustable backlight and one or two
input
buttons). I'd now rather have this supported by the hd44780 driver with
e.g. a setup like
this:
Display <name> {
Driver 'HD44780'
Model 'generic'
Bus 'USB'
Interface 'bwct'
Port 'VENDORID;DEVICEID'
..
The port setting is optional and the default is the vendor and device id
of
the bwct interface. But making it configurable would allow for compatible
devices with different vendor and device ids.
What do you think about this?
Regards,
Till
|
|
From: Michael R. <re...@eu...> - 2006-01-18 06:11:19
|
Hi David, > I've tried to get the code to work, and it compiles, but then LCD4Linux > segfaults! I'm not entirely sure where or why this happens, but when > run from the CVS source (from a few hours ago) directory as: too bad... > Evaluator: internal error: unhandled token <256> > Evaluator: internal error: unhandled token <0> Huh? > Any suggestions? Sorry to be awkward! I'll send you the driver code if > you want to look at it, but I don't think it's my code that's broken. I'm about 1000% sure that there's a buffor overflow or something similar. Somebody (probably your code) writes to memory where it better should not. Somebody overwrites (compiled) expressions for the evaluator, and later the evaluator complains about unknown tokens. So either double-check your code for bounds checking, or send me the patch (as described in my other mail), and I'll have a look at it. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: David I. <dm...@do...> - 2006-01-18 00:05:43
|
Michael,
I've tried to get the code to work, and it compiles, but then LCD4Linux
segfaults! I'm not entirely sure where or why this happens, but when run
from the CVS source (from a few hours ago) directory as:
$ ./lcd4linux -f ./lcd4linux.conf -vvF
This is what I get as output:
Version 0.10.1-CVS starting
plugin_cfg.c: Variable minute = '60000' (60000)
plugin_cfg.c: Variable tack = '100' (100)
plugin_cfg.c: Variable tick = '500' (500)
lcd4linux.c: initializing driver G-15
drv_G15.c: drv_G15_init(): entered
drv_G15.c: drv_G15_start(): entered
G-15: Scanning USB for G-15 keyboard...
drv_G15.c: drv_G15_start(): clearing display
drv_G15.c: drv_G15_update_img(): entered
drv_G15.c: drv_G15_update_img(): left
drv_G15.c: drv_G15_start(): done
drv_G15.c: drv_G15_start(): left
drv_G15.c: drv_G15_blit(): entered
drv_G15.c: drv_G15_blit(): updating image
drv_G15.c: drv_G15_update_img(): entered
drv_G15.c: drv_G15_update_img(): left
drv_G15.c: drv_G15_blit(): left
drv_G15.c: drv_G15_blit(): entered
drv_G15.c: drv_G15_blit(): updating image
drv_G15.c: drv_G15_update_img(): entered
drv_G15.c: drv_G15_update_img(): left
drv_G15.c: drv_G15_blit(): left
drv_G15.c: drv_G15_init(): left
initializing layout 'Default'
drv_G15.c: drv_G15_blit(): entered
drv_G15.c: drv_G15_blit(): updating image
drv_G15.c: drv_G15_update_img(): entered
drv_G15.c: drv_G15_update_img(): left
drv_G15.c: drv_G15_blit(): left
lcd4linux.c: starting main loop
Evaluator: internal error: unhandled token <256>
Evaluator: internal error: unhandled token <0>
uname: unknown field ''
drv_G15.c: drv_G15_blit(): entered
drv_G15.c: drv_G15_blit(): updating image
drv_G15.c: drv_G15_update_img(): entered
drv_G15.c: drv_G15_update_img(): left
drv_G15.c: drv_G15_blit(): left
Segmentation fault
I've snipped out much of my debugging output, just leaving enough to show
you when my functions begin and end.
I'm running on Gentoo Linux with a 2.6.14-gentoo-r5 kernel on an Intel P4
3GHz. I wasn't running LCD4Linux as root. My configure command was:
./configure --with-drivers=G15
because the X11 driver was complaining about not being able to find its
functions when linking, even though the includes seemed to be correct. My
config file is the lcd4linux default config, with all Display sections
removed and replaced with:
Display G15 {
Driver 'G-15'
Port 'libusb'
Size '160x43'
Icons 1
}
and only Layout 'default' enabled, although it doesn't seem to matter
which layout I choose.
Any suggestions? Sorry to be awkward! I'll send you the driver code if you
want to look at it, but I don't think it's my code that's broken. Can't
remember offhand how to create the complete patch though.
Dave
On Tue, 17 Jan 2006 08:08:33 -0000, Michael Reinelt <re...@eu...>
wrote:
> Hi Dave,
>
>> I've been working on getting the Logitech G-15 keyboard's graphical LCD
>> display to work under Linux, and I've recently been linked to your
>> page. It's a true USB display, and your site says to email you about
>> inclusion. I currently use libusb to access the display, and set
>> images.
> Sounds cool!
>
>> What needs to be done to include the driver in your code? I must admit
>> that I haven't written the base driver code yet, but I will do in the
>> near future.
>
> There's a page at the Wiki named "How to write new drivers", I think
> there's a quite good explanation.
>
> The most important point is that you do use the CVS version, otherwise
> it's hard for me to apply your patches.
>
> as you're using libusb, which requires special handling with the
> autoconf stuff, take a look at the BWCT section in drivers.m4 for how to
> test for libusb availability.
>
>
> If you have any further questions, feel free to ask!
>
>
> bye, Michael
>
|
163 messages has been excluded from this view by a project administrator.
