Menu
▾
▴
lcd4linux-devel
|
From: Bill P. <goa...@ya...> - 2004-01-30 22:54:07
|
Hi. I have a question on how things that slightly deviate from standard should be done. For example the CU series VFDs from Noritake/Itron. They are HD44780 compatible but contrast doesn't exist - Pin 3 goes nowhere. It's a brightness setting in software. The relevant bits are R/W low, RS high, and put 0x00h-0x03h on the pins for 4 levels of brightness. Add a cfg_number "VFDBrightness" (or whatever) entry, the sprintf and the HD_write call and that's it. It seems redundant duplicating the HD44780 driver for a slight variant. Thoughts? -BP __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ |
|
From: Michael R. <re...@eu...> - 2004-01-31 05:55:28
|
Hi Bill, > I have a question on how things that slightly deviate from standard should be done. > For example the CU series VFDs from Noritake/Itron. They are HD44780 compatible but > contrast doesn't exist - Pin 3 goes nowhere. It's a brightness setting in software. Never heard of these displays. Do you own such a thing? > The relevant bits are R/W low, RS high, and put 0x00h-0x03h on the pins for 4 levels of > brightness. Add a cfg_number "VFDBrightness" (or whatever) entry, the sprintf and the > HD_write call and that's it. Should be easy to implement, indeed. > It seems redundant duplicating the HD44780 driver for a slight variant. Of course not, you are right. As things like "Contrast", "Brightness" and so on are generally implemented as "plugins" and not hardcoded, we can register any function we want to. If you have access to such a display, would you be willing to implement this feature? bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Bill P. <goa...@ya...> - 2004-01-31 12:07:58
|
Hi again, Yes I much prefer them to LCDs but they are very expensive. That is changing, though. These specific modules you can see at: http://www.noritake-elec.com/uversion.htm Sure thing. Already done. Easy as you say. I was asking because it does deviate from 'normal' HD44780 if you preferred having another driver or just sticking this function into the stock one. Here is snippet against v1.50 from yesterday: --- HD44780.c.original +++ HD44780.c @@ -573,4 +573,16 @@ HD_clear(1); + +// Change Noritake CU series VFD brightness level + char tmpbuffer[2]; + int cu_vfd_brightness; + if (cfg_number("CU_VFD_Brightness", 0, 0, 3, &cu_vfd_brightness)<0) return -1; + if (cu_vfd_brightness) { + snprintf (tmpbuffer, 2, "\%o", cu_vfd_brightness); + HD_command (0x03, 0x38, T_EXEC); // enable function + HD_write (0x03, tmpbuffer, 1, T_WRCG); // set brightness + info ("HD44780: Noritake CU VFD detected. Brightness = %d (0-3)", cu_vfd_brightness); + info (" Settings: 0=100\%, 1=75\%, 2=50\%, 3=25\%"); + } return 0; ### snip ### I just stuck it at the end of HD_init, feel free to do whatever. Thanks, -BP PS: I edited your banner logo to emulate a character VFD. I've seen .sigs this big so I don't feel guilty. :-) begin-base64 640 vfdlcd4linuxlogo31.png iVBORw0KGgoAAAANSUhEUgAAAN0AAAApBAMAAABD6TEmAAAAD1BMVEUAAAAA /+EBPzVSIT9SRFywh+ewAAAA5ElEQVR4nO1W0QnFIAzUbpAVOkGLHaH7z/QI R4haFS08nzzN/RzhSjgT0hizYkVTWNp2wJhtt8RgLgx5huR9PbKqKXNjnDvp ugHnrvskBnNhyDMk7+uRVU2ZH939/bZ/wi0JhyewtL8WPkO9EfoXe4XPlD+d YcxzqNF3Ap+h3oj982c1t19ynvy3ifdnip8kvLw/n3pwKPBtvD+/72/U/gne +FPNDPVG6F/q/9A+n3iPeD7/vV7//uns1d1nOX24U+Aq/j/IncmovT9z+nBn YmuG+aO7v/4h0/bm3mrlM9RbsaI6PsjBsvOqrlHaAAAAAElFTkSuQmCC ==== --- Michael Reinelt <re...@eu...> wrote: > Hi Bill, > > > I have a question on how things that slightly deviate from standard should be done. > > For example the CU series VFDs from Noritake/Itron. They are HD44780 compatible but > > contrast doesn't exist - Pin 3 goes nowhere. It's a brightness setting in software. > Never heard of these displays. Do you own such a thing? > > > The relevant bits are R/W low, RS high, and put 0x00h-0x03h on the pins for 4 levels of > > brightness. Add a cfg_number "VFDBrightness" (or whatever) entry, the sprintf and the > > HD_write call and that's it. > Should be easy to implement, indeed. > > > It seems redundant duplicating the HD44780 driver for a slight variant. > Of course not, you are right. As things like "Contrast", "Brightness" > and so on are generally implemented as "plugins" and not hardcoded, we > can register any function we want to. > > If you have access to such a display, would you be willing to implement > this feature? > > bye, Michael > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ |
|
From: Michael R. <re...@eu...> - 2004-01-31 20:27:04
|
Hi Bill, > http://www.noritake-elec.com/uversion.htm They look cool! > Sure thing. Already done. Easy as you say. I was asking because it does deviate > from 'normal' HD44780 if you preferred having another driver or just sticking this > function into the stock one. Here is snippet against v1.50 from yesterday: I'll try to integrate it, but not into HD44780.c, but drv_HD44780.c (note the drv_ at the beginning). these are the "NextGeneration" drivers, but only in CVS > PS: I edited your banner logo to emulate a character VFD. > I've seen .sigs this big so I don't feel guilty. :-) Looks cool, too! I wondered about these three fine vertical lines, but I suppose this are the "heating" or "anode" (kathode?) wires, right? bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Bill P. <goa...@ya...> - 2004-01-31 22:50:25
|
Hey again. Excellent. This is why I asked in the first place. RE: getting it into distro, no worries. I can always patch my own. I just felt like sharing. Someone more lazy (gasp!) might enjoy a dimmed display. So, the 'NextGen' conf could go something like: Display HD44780 Model CU4002 CUBrightness 2 ...etc? Then perhaps a switch (model); with case blocks for each one? It would keep them separate and managable. HD44780_toppings_and_flavorings.c ? > I wondered about these three fine vertical lines Exactly, filament lines. Think audio valves. Same deal. BTW: Is anyone working on asserting SEL for backlight control of HD44780 modules like lcdproc and lcdmod? I guess it could be any of the available outputs pins. I was just doing it for SEL. AFAIK everyone wired the transistor to SEL. The question is, do they want to control it just at HD_init and HD_quit, or be able via codes or time of day or event trigger, etc? I was about to say just force them to go with a 4-bit mode so there's free pins, but if you can get them to solder at all, you can get them to add a $0.50 latch IC. -BP __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ |
|
From: Michael R. <re...@eu...> - 2004-02-01 08:23:56
|
Hi Bill, Hi List (especially Martin and Xavier),
I just commitet a new HD44780 driver, with some major changes:
- we now support a "Models" table with "Capabilities"
- I added a Model "Soekris" with the Capability "BUSY4BIT". Martin,
please check the functiuonality, and rename the Model according to your
wishes
- I integrated Bill's Noritake Brightness level patch; I added a Model
"Noritake" with the Capability "BRIGHTNESS".
Bill, I didn't really understand your code here:
snprintf (tmpbuffer, 2, "\%o", cu_vfd_brightness);
What the heck is "\%o"? Is it octal? Why the backslash? What does the
resulting string look like?
It gets even more strange:
HD_write (0x03, tmpbuffer, 1, T_WRCG);
If the abofe format string is correct, the brightness would be in the
second character. But you're sending only one byte (the backslash).
I suppose the backslash was a typo. But please double-check the code in
drv_HD44780.c Thanks!
> So, the 'NextGen' conf could go something like:
>
> Display HD44780
> Model CU4002
> CUBrightness 2
it would be
Model Noritake
Brightness 2
>>I wondered about these three fine vertical lines
> Exactly, filament lines. Think audio valves. Same deal.
Great! Really Great!
Should we implement this in the X11 driver?
> BTW: Is anyone working on asserting SEL for backlight
> control of HD44780 modules like lcdproc and lcdmod?
> I guess it could be any of the available outputs pins.
> I was just doing it for SEL. AFAIK everyone wired the
> transistor to SEL.
This is on my ToDo-List (at least on the ony in my head)
> The question is, do they want to control it just at
> HD_init and HD_quit, or be able via codes or time
> of day or event trigger, etc?
Both. I finally decided how to handle all this Contrast, Backlight and
so on features:
- a value will be read from the config at init time, if there is one,
the function will be called
- the feature should register as a plugin, and there will be something
like "events" or "timers" which you can individually define from the config
There's something special about these plugins: They do not just return a
value, but actively change something: for example a Contrast() function
would return the current contrast, but set it, too.
Finallly, sometime it will look like this:
Handler "Backlight" {
Type Timer
Update 1000
Action 'backlight(2*loadavg(1))'
}
Which means that every 1 second the backlight will be set accordingly to
the current load.
bye, Michael
--
Michael Reinelt Tel: +43 676 3079941
Geisslergasse 4 Fax: +43 316 692343
A-8045 Graz, Austria e-mail: re...@eu...
|
|
From: Bill P. <goa...@ya...> - 2004-02-02 05:07:43
|
re: the F*CK problem, glad to know you're human. ;) > snprintf (tmpbuffer, 2, "\%o", cu_vfd_brightness); > What the heck is "\%o"? Is it octal? Why the backslash? What does the > resulting string look like? I suppose the backslash was a typo. ach yes backslash is a leftover. I was trying to pass the function set along with the hd_write. Which didn't work. and octal is... whoops. > It gets even more strange: > HD_write (0x03, tmpbuffer, 1, T_WRCG); > If the abofe format string is correct, the brightness would be in the > second character. But you're sending only one byte (the backslash). > That IS strange. Strange that it actually changes the brightness anyway. It worked or I'd have spotted that (I hope, anyway). No clue why it works. > But please double-check the code in > drv_HD44780.c Thanks! Yep! It works like you knew it would. CLEAN too. Look at those sleek lines. See what purpose crappy coding is for? It motivates real programmers. ;) -BP __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ |
|
From: Xavier V. <xav...@fr...> - 2004-01-31 14:00:15
|
Hello list ! I don't know either these displays, but my opinion slightly differ from yours. Other drivers like MatrixOrbital implement a sort of "models" while HD44780 just knows a "any" model. There should be different entries, like "genric" - "vfd" - "soft contrast", ... and then register relevant functions depending on the model specified on the conf. I don't think there's a sort of model autodetection with HD controller. This would be proper, IMHO. Bye ! -- Xavier VELLO <xav...@fr... PS: for the guys who didn't manage to see the png Bill sent, lauch uudecode and parse the text (with the "begin" line), and then newline, control-D and the image is in the curent dir ;) |
|
From: Michael R. <re...@eu...> - 2004-01-31 20:01:22
|
Hi Xavier, > I don't know either these displays, but my opinion slightly differ from > yours. Other drivers like MatrixOrbital implement a sort of "models" > while HD44780 just knows a "any" model. There should be different > entries, like "genric" - "vfd" - "soft contrast", ... and then register > relevant functions depending on the model specified on the conf. I > don't think there's a sort of model autodetection with HD controller. As always, you are very right! And this is a very very very good idea, as it solves another problem we are facing: (Martin, are you listening?) Martin's special gpio-parport-soekris-whatever-it-is-called-today implementation that is capable of using 4 bits as input and 4 for output can be handled exactly this way! So the user has to specify a "Model" in the config, if he specifies "gpio" (or however you want to call it, Martin), we suppose the user knows what he's doing, and allow 4-bit-busyflag. With all other models, we permit it. Now that's what I call a clean solution! bye, Michael -- Michael Reinelt Tel: +43 676 3079941 Geisslergasse 4 Fax: +43 316 692343 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Martin H. <ma...@he...> - 2004-01-31 20:20:50
|
Hi Michael, Michael Reinelt wrote: > (Martin, are you listening?) I am :-) > Martin's special gpio-parport-soekris-whatever-it-is-called-today > implementation that is capable of using 4 bits as input and 4 for output > can be handled exactly this way! > > So the user has to specify a "Model" in the config, if he specifies > "gpio" (or however you want to call it, Martin), we suppose the user > knows what he's doing, and allow 4-bit-busyflag. With all other models, > we permit it. > > Now that's what I call a clean solution! Sounds like a good idea to me. Right now, I don't really have a clue about how that would be implemented cleanly (since everything would be shared except the init-function (where the driver doesn't bail out with an error message, if 4-bit-mode and busy-flag is requested) and the actual "query_busy_flag" function itself. In both functions, the code that differs is only a couple of lines (so duplicating all the other code would not be desirable). But as I said - I like the idea a lot (even if I don't share your view that the user knows what [s]he's doing :-)) Martin |
|
From: Xavier V. <xav...@fr...> - 2004-02-01 09:49:13
|
Hi list. > In both functions, the code that differs is only a couple of lines (so > duplicating all the other code would not be desirable). Maybe add a if - else statement in the init to switch between the two lines for 'generic' and the two ones for the special model. We don't request there are different functions for it, but we must keep it clear ! For example your patch breaks the ppdev init for 'generic' HD like mine ! I have to use old raw handling. As it's not a special feature, don't write a function, but keep it within if() statements. > But as I said - I like the idea a lot (even if I don't share your view > that the user knows what [s]he's doing :-)) Martin, please remember we're not writing a KDE app ;) This is a daemon for 'advanced users' who know (especially for HD) what (and why) they are doing. I think the lcd4linux users population is more than half geeks (like me ;) and the others are embedded systems where people know exactly their job. bye ! -- Xavier VELLO <xav...@fr...> |
|
From: Martin H. <ma...@he...> - 2004-02-01 10:28:33
|
Hi Xavier, > For example your patch breaks the ppdev init for 'generic' HD like mine > ! I have to use old raw handling. It doesn't really - it's just that my patch had a bug. I hope I'll get to fixing it today. The busyflag feature is meant (and tested) to work on e generic parallel port as well as my "GPIO parport emulation". > As it's not a special feature, don't write a function, but keep it > within if() statements. Ok, I get it. Makes sense. And this way, one could nicely add some sanity checks based on the "Model". I like it. >>But as I said - I like the idea a lot (even if I don't share your view >>that the user knows what [s]he's doing :-)) > > Martin, please remember we're not writing a KDE app ;) This is a daemon > for 'advanced users' who know (especially for HD) what (and why) they > are doing. I think the lcd4linux users population is more than half > geeks (like me ;) and the others are embedded systems where people know > exactly their job. I don't really know the lcd4linux user-base - but I'm always weary when assuming that the user knows what he's doing. Maybe I'm overly paranoid (or I've been spending too much time doing support :-)) Martin -- You think that's tough? Try herding cats! |
|
From: Martin H. <ma...@he...> - 2004-02-01 12:34:07
|
Hi again, > For example your patch breaks the ppdev init for 'generic' HD like mine > ! I have to use old raw handling. Sorry - I missed that you were using the "old raw handling". Can you check if it's still broken (I just committed my changes to CVS)? If it's still broken, I'll have to look into it - I'm not really sure how it could break things, unless if the "set_direction" call doesn't work with raw port access. Martin |
|
From: Xavier V. <xav...@fr...> - 2004-02-01 17:41:58
|
Le dim 01/02/2004 =C3=A0 13:34, Martin Hejl a =C3=A9crit : > Hi again, >=20 > > For example your patch breaks the ppdev init for 'generic' HD like mi= ne > > ! I have to use old raw handling. > Sorry - I missed that you were using the "old raw handling". I'm curently using the raw way because the new ppdev was broken by your p= atch. > Can you check if it's still broken (I just committed my changes to CVS)= ?=20 > If it's still broken, I'll have to look into it - I'm not really sure= =20 > how it could break things, unless if the "set_direction" call doesn't=20 > work with raw port access. I'll look as soon as possible if it works now with the "models" rework Bye ! --=20 Xavier VELLO <xav...@fr...> |
|
From: Martin H. <ma...@he...> - 2004-02-01 18:22:25
|
Hi Xavier, >>>For example your patch breaks the ppdev init for 'generic' HD like mine >>>! I have to use old raw handling. >> >>Sorry - I missed that you were using the "old raw handling". > > I'm curently using the raw way because the new ppdev was broken by your patch. > > >>Can you check if it's still broken (I just committed my changes to CVS)? >> If it's still broken, I'll have to look into it - I'm not really sure >>how it could break things, unless if the "set_direction" call doesn't >>work with raw port access. > > I'll look as soon as possible if it works now with the "models" rework Ok - let me (or best, all of us) know how it turns out. I'm still confused as to what "broke" - since none of the changes should have changed anything, unless you had a "UseBusy 1" in your config. Martin -- You think that's tough? Try herding cats! |
Thanks for helping keep SourceForge clean.
X