Menu
▾
▴
lcd4linux-devel
|
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-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: 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: 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: 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: 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X