Menu
▾
▴
lcd4linux-devel
|
From: Michael R. <re...@eu...> - 2007-01-15 06:13:53
|
Hi Hans, > Im involved in a project running related to running systems onuClinux on > Blackfin. Recently i got the task to implement the hardware and software > needed for a HD44780 LCD via I2C for the blackfin. Doing that i got the ide > to try to port either lcdproc or lcd4linux. Lcdproc failed on some shared > library build(may persue that later) but i made a successful build of > lcd4linux and i have also made a uClinux patch for HD44780 over i2c(via > pfc8574). Has this been done? Tried to search for any other LCD-uClinux > projects but with no luck. Instructions on how to set it up, and also notes > on the patch at: > > http://www.vpx.nu/dokuwiki/doku.php?id=displays Look nice! > Also, note that i did(in function rep_nop for the delays) > - __asm__ __volatile__("rep; nop"); > + __asm__ __volatile__("nop"); > > since i think rep is IA32 specific. Dont know if this is a good final solution > for all platforms. This has already been fixed in CVS/SVN. > Im sure some developer can use the patch and incorporate it to a future > release in a sweet mannner, a configure switch of --with-uclinux would be > nice:). Im not a make guru so i did not do it so fancy. Hope anyone else can > try it out on their embedded system. I had a look at your patch. I can't accept it as it is, because it would cause lots of problems with people needing the parpott driver :-( But I got another idea: I will duplicate the HD44780 driver entry in drivers.m4, providing kind of a "sub-driver" called "HD44780-I2C", which doesnt use parport at all. Are you willing to do some testing? You would have to use the SVN version... Another question: Why did you use vfork()? From what I've read in the manpage, this is dangerous.... bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Luis C. <lfc...@lf...> - 2007-01-15 07:53:24
|
Luis Correia wrote: > Michael Reinelt wrote: >> Hi Hans, >> >> >>> Im involved in a project running related to running systems >>> onuClinux on Blackfin. Recently i got the task to implement the >>> hardware and software needed for a HD44780 LCD via I2C for the >>> blackfin. Doing that i got the ide to try to port either lcdproc or >>> lcd4linux. Lcdproc failed on some shared library build(may persue >>> that later) but i made a successful build of lcd4linux and i have >>> also made a uClinux patch for HD44780 over i2c(via pfc8574). Has >>> this been done? Tried to search for any other LCD-uClinux projects >>> but with no luck. Instructions on how to set it up, and also notes >>> on the patch at: >>> >>> http://www.vpx.nu/dokuwiki/doku.php?id=displays >>> >> >> Look nice! >> >> >>> Also, note that i did(in function rep_nop for the delays) >>> - __asm__ __volatile__("rep; nop"); >>> + __asm__ __volatile__("nop"); >>> >>> since i think rep is IA32 specific. Dont know if this is a good >>> final solution for all platforms. >>> >> This has already been fixed in CVS/SVN. >> >> >>> Im sure some developer can use the patch and incorporate it to a >>> future release in a sweet mannner, a configure switch of >>> --with-uclinux would be nice:). Im not a make guru so i did not do >>> it so fancy. Hope anyone else can try it out on their embedded system. >>> >> >> I had a look at your patch. I can't accept it as it is, because it would >> cause lots of problems with people needing the parpott driver :-( >> >> But I got another idea: I will duplicate the HD44780 driver entry in >> drivers.m4, providing kind of a "sub-driver" called "HD44780-I2C", which >> doesnt use parport at all. >> > > I can help debugging this one, as I half wrote the first implementation. > > Have you checked the way we have done it? > >> Are you willing to do some testing? You would have to use the SVN >> version... >> >> Another question: Why did you use vfork()? From what I've read in the >> manpage, this is dangerous.... >> >> >> bye, Michael >> >> > > Luis > Sorry, the first one got caught in some spam filter, don't know why... -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Michael R. <re...@eu...> - 2007-01-15 08:03:26
|
Hi Luis, >> I can help debugging this one, as I half wrote the first implementation. Great! Did you already switch to SVN? :-) >> Have you checked the way we have done it? Sorry, I don't know what you mean... I thinke the OP's problem is that he does not want any parport stuff get compiled/linked. -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Luis C. <lfc...@lf...> - 2007-01-15 08:07:10
|
Michael Reinelt wrote: > Hi Luis, > > >>> I can help debugging this one, as I half wrote the first implementation. >>> > Great! > > Did you already switch to SVN? :-) > > I did a test checkout yesterday, but no compile tests were done >>> Have you checked the way we have done it? >>> > Sorry, I don't know what you mean... I thinke the OP's problem is that > he does not want any parport stuff get compiled/linked. > > I meant the way we talked to the PCF chip, and the question was meant for the uClinux developer, not you, sorry for the confusion. I plan to put myself back into lcd4linux development, to finally finish the HD44780-I2C driver, if you split it into it's own file, it would surely make things better :) Luis p.s. no need to CC me -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |
|
From: Michael R. <re...@eu...> - 2007-01-15 21:30:09
|
Hi Luis, > I plan to put myself back into lcd4linux development, to finally finish > the HD44780-I2C driver, if you split it into it's own file, it would > surely make things better :) Oh, I don't plan to duplicate the whole HD44780 driver, but only the driver entry in drivers.m4, so one can select "--with-drivers=HD44780-I2C" and don't get the parport stuff linked in (ifdef'ed out by #ifdef WITH_PARPORT or something) OTOH, if you like to have your 'own' driver, we could do so; but they would share some common code... maybe we could backport your changes later... just let me know what you prefer. > p.s. no need to CC me sorry... got used to hit "reply all" :-) bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Robert B. <rb...@ge...> - 2007-01-15 22:10:05
Attachments:
signature.asc
|
Michael Reinelt wrote: >> I plan to put myself back into lcd4linux development, to finally finis= h=20 >> the HD44780-I2C driver, if you split it into it's own file, it would=20 >> surely make things better :) >=20 > Oh, I don't plan to duplicate the whole HD44780 driver, but only the > driver entry in drivers.m4, so one can select > "--with-drivers=3DHD44780-I2C" and don't get the parport stuff linked i= n > (ifdef'ed out by #ifdef WITH_PARPORT or something) Will this disable the possibility to compile both drivers at the same tim= e? Regards, Robert |
|
From: Michael R. <re...@eu...> - 2007-01-16 06:22:36
|
Robert Buchholz wrote: > Michael Reinelt wrote: >>> I plan to put myself back into lcd4linux development, to finally finish >>> the HD44780-I2C driver, if you split it into it's own file, it would >>> surely make things better :) >> Oh, I don't plan to duplicate the whole HD44780 driver, but only the >> driver entry in drivers.m4, so one can select >> "--with-drivers=HD44780-I2C" and don't get the parport stuff linked in >> (ifdef'ed out by #ifdef WITH_PARPORT or something) > > Will this disable the possibility to compile both drivers at the same time? Yes and no :-) The "normal" HD44780 driver will contain both parport and i2c stuff, but the new "HD44780-I2C" driver will contain i2c *only*. Default behaviour (--with-drivers=all) will compile the standard HD44780 driver with i2c support. Note that there's no seperate HD44780 driver, nor a 2nd drv_HD44780.c driver source. -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Luis.F.Correia <Lui...@se...> - 2007-01-16 08:41:12
|
Hi Michael, > -----Original Message----- > From: lcd...@li... > [mailto:lcd...@li...] On > Behalf Of Michael Reinelt > Sent: Monday, January 15, 2007 9:29 PM > Cc: lcd4linux-devel > Subject: Re: [Lcd4linux-devel] [lcd4linux] uClinux patch. > > Hi Luis, > > > I plan to put myself back into lcd4linux development, to finally > > finish the HD44780-I2C driver, if you split it into it's > own file, it > > would surely make things better :) > > Oh, I don't plan to duplicate the whole HD44780 driver, but > only the driver entry in drivers.m4, so one can select > "--with-drivers=HD44780-I2C" and don't get the parport stuff > linked in (ifdef'ed out by #ifdef WITH_PARPORT or something) > > OTOH, if you like to have your 'own' driver, we could do so; > but they would share some common code... maybe we could > backport your changes later... just let me know what you prefer. what I had in mind was something even less stressfull but maybe hard to make. and it is split the HD44780 driver even further so that the actual 'bus' connection is fully separated from the HD44780 core. which would make things like supporting different connections even simpler from memory there are some major HD44780 connections: -parport -i2c -serial-to-paralell (obsolete by now) -gpio (from Martin Hejl's, although it uses a parport emulation) -some other that I can't recall > > > > p.s. no need to CC me > sorry... got used to hit "reply all" :-) > eheh > bye, Michael > Luis Correia |
|
From: Michael R. <re...@eu...> - 2007-01-16 20:06:41
|
Hi Luis, >> OTOH, if you like to have your 'own' driver, we could do so; >> but they would share some common code... maybe we could >> backport your changes later... just let me know what you prefer. > > what I had in mind was something even less stressfull but maybe hard > to make. and it is split the HD44780 driver even further so that > the actual 'bus' connection is fully separated from the HD44780 core. > > which would make things like supporting different connections even simpler You are right, I've been thinking about such a solution, too. But let's do this after a 0.10.1 (or 0.11) has been released :-) OTOH, different HD44780 drivers do not share that much code.. If I think about the various USB2HD44780 adapters, the only thing in common is the display ram addressing scheme, and some CGRAM stuff. But with USB you don't care about 4/8 bit, timings, wirings, and all that stuff that makes the current HD44780.c *that* complicated. Probably it would be easiest just to split the driver into bus-dependant parts, and don't care about the common code. As a second step, take the HD44780 drivers that are already extra files into account, and look for common code, and try to find a clean and simple way to unify it. For the time being, I'll implement the "HD44780-I2C" configure option; which may be removed again. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2007-01-16 20:25:55
|
Hi Hans, I hope you don't mind the CC'ing to lcd4linux-devel.... > Meaning we would really want a simple button/LCD interface for an operator to > handle, something very simple and easy to set up and use. Ideas involving > menu hierarchy in a XML or XML-like format for example(or something very more > light weight, a simple intentaion format may do well). Would it be > possible/suitable to add such functionality to lcd4linux? Oh, I read the evil word "Buttons" here :-) > Saw there was a > button plug-in for example. Im more of a hardware/kernel guy than > userland/sysadmin so im not well oriented in all the aspects of user > interaction in uclinux, maybe/probably this has been done before. Any ideas? Well, I am thinking about Buttons/keypads for years now. As I'm thinking about dynamic layouts.... > I should have checked out the SVN version instead, but no problem of making a > new patch since it was no major changes. In short i just wanted to achieve a > compile with no referencs to parport related functions, there were a few > references to it in drv_HD44780.c/.h even though not allways needed when > display sits on i2c (or maybe other hardware as well). I will provide a special configure target "--with-drivers=HD44780-I2C" which will compile the HD44780 driver withaout any parport references. Please test & give feedback! > And i also needed to > change fork() to vfork() since uClinux does not support fork(). erm... are you really sure? From what I know, vfork just saves a few cycles if fork() is immediately followed by exec(), but the caller blocks until the exec() is successful (so it's dangerous because if exec() fails, the behaviour is undefined) is there any *reliable* preporcessor constant I could use? > I think embedded linux is comming strong > now so it would be cool for lcd4linux to be the lcd software of choice such > systems. 1000% agree :-) 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