Menu
▾
▴
lcd4linux-devel
|
From: Julien A. <ja...@ni...> - 2005-04-28 22:46:43
|
Hello, I just want to tell you that I finally got my Noritake GU128x32-311 working ! It is used as a text-mode display by now, even if it's a graphical display (The display itself has 2 modes: one text and one graphic). The problem with the graphic mode are, first, I'm worried about the bandwidth needed on the parallel port to refresh all the display, and also, the microcontroller uses a very very weird way to pack the data, and I could not find (yet) an efficient way to do it in C. Also, I did not put the "bars" widget support on this version, I will do it quickly through. There is still a few bugs on this version, because my test computer is a network appliance. It has the following problems : - The power supply is weak, so the voltage of the lines are not stable (I take the power fro the computer, and the display use ~1Amp fully lighted) - There is no TSC inside the MediaGX processor : Linux rely on a less accurate timer, and it is sensitive to the load of the machine. (I measured that with an oscilloscope) The consequences is that, sometime, some characters are wrong, misplaced or not present. I plan to correct that. Anyway, I'm ready for inclusion into the CVS, as a beta version. The only think that make me hesitate is that I don't know how to *exactly* modify these #%!$#!@ autoconf/automake files in the CVS, to avoid messing up everything. On my own repository I have made some scripts and stuff to not use them, but for inclusion it will become necessary. Michael, would it be possible for you to update the README.driver to explain that as much as you can ? I don't want to mess up the repository. Thanks ! Anybody that have such a display, and the cable from this schematics: http://liquid-mp3.schijf.org/schematics/noritake_gu128x32-311.gif is welcome to try and send feedbacks. Next projects in the pipeline : - A driver for a SED1335 on USB display [ a so-called cPad on a Toshiba laptop, see http://www.janerob.com/rob/ts5100/cPad/index.shtml ] - A driver for a framebuffer display, because I want to map any graphical display on a framebuffer, if the bandwidth to the display is sufficent. Cheers ! OB On Sat, 2005-04-23 at 21:18, fr...@gu... wrote: > > > I'll start the tests in windows as soon as I can, and if/when I get it > > > to work there I'll get back to you .... > > but, at least, it was useful to verify that the wiring was correct and > > the display answered. > > It works like a charm, I grabbed the latest alpha and simply renamed the corresponding noritake311 xml file to liquid-mp3.xml and got it to work instantly. > > > I have much more time now to work on the driver for the noritake, count > > 1 or 2 weeks at most before I can push a beta to the CVS. > > No rush here, I still have to figure out to make this thing fit my HTPC box, in worst case I'll have to unsolder all the 198 connectors between the PCB and the VFD, to attach extra cables in between :D > > > Do you have any programming experience ? > > None really worth mentioning, I've been working with C, but I've never really done any advanced programming in it, and when it comes to C++ I'm totally lost :D > > ___________________________________ > Sent from www.guldnallen.com > > |
|
From: Michael R. <re...@eu...> - 2005-04-29 06:03:23
|
Hi Julien, > I just want to tell you that I finally got my Noritake GU128x32-311 > working ! Well, that's great news! > It is used as a text-mode display by now, even if it's a graphical > display (The display itself has 2 modes: one text and one graphic). > The problem with the graphic mode are, first, I'm worried about the > bandwidth needed on the parallel port to refresh all the display, and > also, the microcontroller uses a very very weird way to pack the > data, and I could not find (yet) an efficient way to do it in C. Could you send mo a description of the packed format? There#s no need to worry about bandwidth issues, lcd4linux uses a very sophisticated double-buffering, so the data transfers are reduced to a minimum. > Also, I did not put the "bars" widget support on this version, I will > do it quickly through. Don't care about it too much. As it's a graphical display, we should use it's graphical mode only, and the bar rendering for graphic LCD's is ready to use. > - There is no TSC inside the MediaGX processor : Linux rely on a less > accurate timer, and it is sensitive to the load of the machine. (I > measured that with an oscilloscope) That's not that good, but it should not matter: just include some reserve in your timing values. > The only think that make me hesitate is that I don't know how to > *exactly* modify these #%!$#!@ autoconf/automake files in the CVS, to > avoid messing up everything. > Michael, would it be possible for you to update the README.driver to > explain that as much as you can ? I don't want to mess up the > repository. Thanks ! Hmm... as this is quite complicated stuff, I don't see too much sense in trying to document that. Could you send me a patch (cvs -z9 diff -u) and I'll integrate it into the autojunk stuff. > Next projects in the pipeline : - A driver for a SED1335 on USB > display Great! > - A driver for a framebuffer display, because I want to map any > graphical display on a framebuffer, if the bandwidth to the display > is sufficent. Well, that's already done. drv_generic_graphic.c Take a look at the T6963 driver, it uses this interface. It's that easy... you only have to write sort of a 'blit' function, the generic graphic driver takes care of the rest. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2005-05-04 05:48:59
|
Hi Julien, are you subscribed to lcd4linux-devel? >>Do you think it would make sense to call the driver "Noritake" and give >>it a "Model" called "GU311"? So other models could follow, and the file >>would be called "drv_Noritake.c > Okay ! Lets'go for that solution. > I will send you a drv_Noritake.c file shorlty. > (I'm glad I did not make the commit !) Got it, looks fine, checkd it into CVS. Just a few comments on the driver: - includeing linux/parport.h sould be removed. All parport stuff should be handled by the generic parport driver. I saw that you need some status lines. I will add some wire_status() calls to the parport driver. - you should not use hardwire_*. This is for displays which will *always* be wired the same way (i.e. internal devices which are connected directly to the motherboard). - you should store your "Models" in a array. Have a look at drv_Cwlinux.c for an example (but you can modify the struct MODEL to fulfill your needs) > Thing is, the Noritake company have a lot of displays, and not all of > them uses this protocol. Actually, this display is the only one I know > from Noritake to use that protocol (hitachi microcontroler) > So, If we add another display later, the protocol will likely be > completely different, and so we will need to add other functions to this > file, not at all related to this display. Thats no problem, this is the case with other displays, too (Cwlinux, MatrixOrbital, CrystalFontz) bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2005-05-04 06:30:27
|
Hi Julien, >>- includeing linux/parport.h sould be removed. All parport stuff should >>be handled by the generic parport driver. I saw that you need some >>status lines. I will add some wire_status() calls to the parport driver. > Cool. Actually it's not needed anymore since I've changed my mind, and I > use a timed wait rather than a busy line polling method. > It's still a good idea to add some function to get the status lines of > the parallel port. I just wrote the wire_status() stuff and commited. I think it would be a good idea to support both methods: busy-line checking and a fixed delay. We've encountered situations in the past, where waiting caused lcd4linux to eat up too much CPU cycles (especially on slower systems). Maybe you want to detect it by checking if there's a "Wire.Busyline" entry in the config, and/or by using a config entry "UseBusy" (as in the HD44780 driver). bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: OB <ja...@ni...> - 2005-05-04 07:35:43
|
> > I think it would be a good idea to support both methods: busy-line > checking and a fixed delay. We've encountered situations in the past, > where waiting caused lcd4linux to eat up too much CPU cycles (especially > on slower systems). Funny ! It's precisely because of that reason I reverted to the fixed delay method : The busy-line checking was eating too much CPU.... But it might come from my crappy MediaGX-based test box. > Maybe you want to detect it by checking if there's a > "Wire.Busyline" entry in the config, and/or by using a config entry > "UseBusy" (as in the HD44780 driver). Ok, I'll do that on my next commit. (I've just commited the changes you asked me previously, and btw the driver now compile without warnings). Julien |
|
From: Michael R. <re...@eu...> - 2005-05-04 10:33:40
|
Hi Julien, >>I think it would be a good idea to support both methods: busy-line >>checking and a fixed delay. We've encountered situations in the past, >>where waiting caused lcd4linux to eat up too much CPU cycles (especially >>on slower systems). > Funny ! It's precisely because of that reason I reverted to the fixed > delay method : The busy-line checking was eating too much CPU.... > But it might come from my crappy MediaGX-based test box. Strange, but may come from the ndelay(200) in the busy-checking loop. You should anyway implement some fallback mechanisms (like, do not wait forever, fall back to normal delay if a certain amount of busy-checks failed, and so on). Take a look at the HD44780 driver, you'll find a very sophisticated busy-checking there. 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