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...> - 2005-03-02 22:15:07
|
Hi everyone, Finally found the time to have a look at the I2C display. Let's start with the good news: I HAVE GOT IT WORKING!!!! :-) Turned out there where several issues. Some of them are in the parallel port part too. So that is a bit weird. On of the things that surprised me was that the commands where send using the send_byte command that actually tried to set the RS signal. (which should only be done for data) This is the strange thing. parallel port code does the same. I guess it has to do with the copy of the source code that I got from the web-site. The second problem was that the SIGNAL_ENABLE, SIGNAL_RS and SIGNAL_RW were never set correctly. I did it manually now. But how should it be done? And that's it! Good work Luis! You were nearly there! So, if anyone can tell me what I should do to get this stuff in the official code? cheers, Paul |
|
From: Michael R. <re...@eu...> - 2005-02-26 09:58:30
|
Hi andre, > i think i have my first prototype of my drv_SED133x.c ready, > but i can not integrate it into the lcd4linux stuff. I think i'm doing > something wrong with the makefiles. > Makefile:502: *** missing separator. Schluss. Well, maybe you should send me the patch (per PM, not to the list, please). I will have a look at it. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Andre A. <an...@ro...> - 2005-02-25 22:05:52
|
Hi,
i think i have my first prototype of my drv_SED133x.c ready,
but i can not integrate it into the lcd4linux stuff. I think i'm doing
something wrong with the makefiles.
I've added the references to my driver into drv.c, into drivers.m4,
into configure, into config.h.in, into Makefile.am and into Makefile.in
./configure seems to produce no errors, but make stops with
configure: creating ./config.status
cd . \
&& CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status
config.status: creating Makefile
config.status: executing default-1 commands
Makefile:502: *** missing separator. Schluss.
I think i did the same as Michael did adding the SimpleLCD Driver.
I have no problem with a clean CSV Checkout, only after adding my driver
make won't run.
What am i making wrong? Sorry for the dumb questions, but i'm new to
Linux Software development.
Bye,
Andre
|
|
From: Francisco P. A. <fra...@di...> - 2005-02-25 09:49:45
|
...
Michael Reinelt wrote:
> Hi Francisco,
>
>
>>I'm poking around with the new RC1 version.. so.. first of all i had
>>some confusion betwen old .conf format and the new.. i supose the old .9
>>conf files are not interpreted as well.. right?
>
>
> Yes, the config file format did change a lot.
;)
>
>>i have an HD44780 lcd
>>now my troubles are:
>>
>>I didn't get how to use virtual rows and cols (a virtually bigger
>>screen, scrolling around my real one..i think) maybe i didn't get in
>>which section this rows, scroll, etc params go..
>
> Well, the answer is simple: there are no "virtual rows" at the moment :-)
>
> This will be solved as soon lcd4linux got it's "event" subsystem, which
> will drive the "moving window" of the display against the layout
> framebuffer.
ok..
>
>>I didn't get to work my sensors.. they seem not to be detected well..
>>altough my lmsensors is working ok.. i tried kernel modules and compiled
>>in.. i have a via mini-itx board.. with "vt1211-isa-6000" chip.. anyway
>>i get this:
>>Feb 23 18:50:32 scarpiera LCD4Linux[2364]: i2c_sensors: unable to
>>autodetect i2c sensors!
>>uhm.. how does he autedetect this??
>
> Xavier? Are you listening?
ok Xavier aswered with the solution!
I hadn't temp1_input (i also have the number inverted i.e. i have
tempNUMBER_input instead of temp_inputNUMBER.. dunno why ;)) maybe this
helps someone else too..
and so.. not having temp1_input in my sensors dir in sysfs I forced it
with i2c_sensors-path '/sys/bus/i2c/devices/1-6000/'
and everything went well..
I put also a expression (i2c_sensors('temp3_input')*71)/73-72.41
line in my .conf and now the temperature gets read..
I think some doc of the .conf file would really help ;)
for instance i also dunno how to read for instance the cpu freq from
/proc/cpuinfo with the function instead of doing a stupid system call to
cat and grep it.. ;)
It would also be super if it would be possible to read smart tags from
hard drives!! for instance I use now a small soft called hddtemp to read
my temp of the hard drive via smart.. but also in this case i need to do
a system call forking to ask temperature every when..
>
>>Another strange behaviour of my HD44780 is that it is not able to
>>visualize personalized icons and bars that are not either North nor East
>>oriented.. is this normal (i'm not trying to display all this things in
>>the SAME time.. just separately)? maybe it should redefine the icons in
>>function of the free character it has, right?
>
> Did you reserve some chars using the 'Icons' parameter in the display
> section?
actually not.. I tried to get aout of the conf all this icon definitions
because I thought they could redefine my chars off.. but it didn't
help.. if I have a conf with also just one bar defined.. this bar can go
either est or north no way to having it west or south.. even if it is
the only bar defined.. uhm...
>
>>Finally I was also arguing what was the msr.h support for lcd4linux used
>>for? i get this:
>>Feb 23 18:50:32 scarpiera LCD4Linux[2365]: udelay: The file
>>'include/asm/msr.h' was missing at compile time.
>>What would the benefits be.. and why is the ./configure not detecting
>>this .h in my system? i have it in /asm altough.. and of course my
>>/proc/cpuinfo says i have msr support.. ;)
>
> Maybe you need to have kernel sources installed. The configure script
> looks for /usr/include/asm/msr.h; and if this file cannot be found, TSC
> delay loops will be deactivated. The benefit of TSC delays is that it
> will be more precise and takes less CPU time (well, at least I hope so :-)
interesting feature! so i will try to recompile and see the difference
in cpu usage.. just cant understand why i didn't have the .h file in the
/usr/include/asm/ dir.. uhm.. and i have sources installed.. maybe it is
just a link some script didn't put in place.. uhm...
>
>>Ok i also have a feature suggestion if it would be not too complicated:
>>since the bar indicators are automagically scaling according to the
>>maximum value they register.. after a while and after for instance a big
>>download burst, the eth indicator is almost invisible on the bar.. is it
>>possible to set some sort of timeout which resets the peak maximum scale
>>value? it would realy be visually more appealing..
>
> I've been thinking about this. some kind of "slow reduction of the
> maximum value".... Would you care to open a ticket for this?
ok, sure i will =)
maybe by holding the maximum value for some milliseconds after which it
gets recaluclated from scratch.. uhm..
anyway real cool job with this program!
maybe if i have some time i would gladly help to contribute.. maybe with
this thing about smart tag reading.. I'll look in the plugin creation
instructions.. ;)
tent:wq
--
Dr. Francisco Peralta Aguaron SysAdmin DSY.it
Dipartimento di Scienze dell'Informazione Forum Studenti
fra...@di... te...@ds...
http://www.10t8or.com http://www.dsy.it
PGP-FP: BE5C 0DCA DDB2 3729 B348 4FF3 3BD6 BD7A 1AD6 FA95
|
|
From: Xavier V. <xav...@fr...> - 2005-02-24 20:35:22
|
Hello Francisco ! Just answering de i2c-stuff 'cause I'm in a hurry by now ... > I didn't get to work my sensors.. they seem not to be detected well.. > altough my lmsensors is working ok.. i tried kernel modules and compiled > in.. i have a via mini-itx board.. with "vt1211-isa-6000" chip.. anyway > i get this: > Feb 23 18:50:32 scarpiera LCD4Linux[2364]: i2c_sensors: unable to > autodetect i2c sensors! > uhm.. how does he autedetect this?? You should read the doc on the wiki (lcd4linux.bulix.org) : - if you have a 2.4.x kernel, L4L looks in /proc/sys/dev/sensors/ and hopes to find a link to the sensors. Be sure to have /proc mounted and i2c-proc loaded (if I recall well) - if you have a 2.6.x kernel, L4L looks in /sys/bus/i2c/devices/ and tries to find an entry with a temp_input1. The only reason for it to fail is not to have a temp_input1 provided by your driver. Browse /sys/bus/i2c/devices/ directories to guess. Oh ! And if you don't have /sys mounted, it'll fail :) If you find your sensors via procfs or sysfs and L4L fails, you can force the detection with the i2c_sensors-path configuration token, for example: * for sysfs: i2c_sensors-path '/sys/bus/i2c/devices/0-6000/' * for procfs: i2c_sensors-path '/proc/sys/dev/sensors/via686a-isa-6000' Bye ! -- Xavier VELLO <xav...@fr...> |
|
From: Michael R. <re...@eu...> - 2005-02-24 19:50:17
|
Hi Andre, > just wanna ask if somebody is working on a driver > for the SED1335? If not, i would give it a try. It would be great If you could start writing a driver. I own such a display, but I just can't find the time to write the driver (well, honestly, I can't find the time to build an interface board :-) If you need any help, please let me know! bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2005-02-24 19:47:32
|
Hi Francisco, > I'm poking around with the new RC1 version.. so.. first of all i had > some confusion betwen old .conf format and the new.. i supose the old .9 > conf files are not interpreted as well.. right? Yes, the config file format did change a lot. > i have an HD44780 lcd > now my troubles are: > > I didn't get how to use virtual rows and cols (a virtually bigger > screen, scrolling around my real one..i think) maybe i didn't get in > which section this rows, scroll, etc params go.. Well, the answer is simple: there are no "virtual rows" at the moment :-) This will be solved as soon lcd4linux got it's "event" subsystem, which will drive the "moving window" of the display against the layout framebuffer. > I didn't get to work my sensors.. they seem not to be detected well.. > altough my lmsensors is working ok.. i tried kernel modules and compiled > in.. i have a via mini-itx board.. with "vt1211-isa-6000" chip.. anyway > i get this: > Feb 23 18:50:32 scarpiera LCD4Linux[2364]: i2c_sensors: unable to > autodetect i2c sensors! > uhm.. how does he autedetect this?? Xavier? Are you listening? > Another strange behaviour of my HD44780 is that it is not able to > visualize personalized icons and bars that are not either North nor East > oriented.. is this normal (i'm not trying to display all this things in > the SAME time.. just separately)? maybe it should redefine the icons in > function of the free character it has, right? Did you reserve some chars using the 'Icons' parameter in the display section? > Finally I was also arguing what was the msr.h support for lcd4linux used > for? i get this: > Feb 23 18:50:32 scarpiera LCD4Linux[2365]: udelay: The file > 'include/asm/msr.h' was missing at compile time. > What would the benefits be.. and why is the ./configure not detecting > this .h in my system? i have it in /asm altough.. and of course my > /proc/cpuinfo says i have msr support.. ;) Maybe you need to have kernel sources installed. The configure script looks for /usr/include/asm/msr.h; and if this file cannot be found, TSC delay loops will be deactivated. The benefit of TSC delays is that it will be more precise and takes less CPU time (well, at least I hope so :-) > Ok i also have a feature suggestion if it would be not too complicated: > since the bar indicators are automagically scaling according to the > maximum value they register.. after a while and after for instance a big > download burst, the eth indicator is almost invisible on the bar.. is it > possible to set some sort of timeout which resets the peak maximum scale > value? it would realy be visually more appealing.. I've been thinking about this. some kind of "slow reduction of the maximum value".... Would you care to open a ticket for this? bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2005-02-24 19:41:12
|
Hi Julien, > I've just made a little driver I called "SimpleLCD". Looks fine! I commited your patch (with some cosmetic modifications) into CVS. Thanks a lot! > It's a kind of preliminary work for training myself for more evolved > drivers. I have in mind a driver for a Noritake GU 128x32 in text-mode, > and a SED1335 (crystalfontz) in text-mode too. Great! I love to have new drivers! > I think the parrallel port is just too slow for the graphic mode, so I > plan to build a USB-to-LCD board, only after that I would try graphic > mode on thoses screens. Well, I don't thinks so. There's already a driver (T6963) for graphics displays, which works fine, and is fast enough. LCD4Linux does already do lots of double-buffering, so speed should not be an issue.... > Please feel free to include this little driver if you think it is worth > it into the distribution, I will maintain it (its GPL of course). If you > do, I will post a message on the devel mailing-list concerning this > driver and my other projects. You're very welcom to do so! Do you have a SF account? I'd add you to the developers list, giving you write access to the CVS. bye, Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Michael R. <re...@eu...> - 2005-02-24 19:36:43
|
I'm forwarding this to the list.... -------- Original-Nachricht -------- Betreff: lcd4linux new SimpleLCD driver Datum: Thu, 24 Feb 2005 01:22:48 -0500 Von: Julien Aube <ja...@ni...> Firma: National Institute of Standards and Technologies An: re...@eu... Hello, I've just made a little driver I called "SimpleLCD". It is a very simple serial driver for a display that has no commands at all (no clearscreen, no custom characters), just raw ascii. I use it for different purposes : - On a back-to-back serial console, - As a test for some microcontroller project, - With a 2x20 controller that come from a Bull POS and which emulate the codepage 437. (it react correctly to CR and LF, but that's all the "special codes" it knows.) The "Option" field in the config file I've added is used to pass options to the serial open function, through the "flag" parameter. (Useful 'cause my LCD requiere an odd parity) Most of this driver is a simplified version of the LCDTerm one, I just removed some code specific to the HD44780, and I says so in the header of drv_SimpleLCD.c. It's a kind of preliminary work for training myself for more evolved drivers. I have in mind a driver for a Noritake GU 128x32 in text-mode, and a SED1335 (crystalfontz) in text-mode too. I think the parrallel port is just too slow for the graphic mode, so I plan to build a USB-to-LCD board, only after that I would try graphic mode on thoses screens. Another solution would be to create a USB-LCD framebuffer into linux and then make a drv_FrameBuffer for lcd4linux to write on it. Please feel free to include this little driver if you think it is worth it into the distribution, I will maintain it (its GPL of course). If you do, I will post a message on the devel mailing-list concerning this driver and my other projects. The patch applies against the latest cvs checkout. Thanks, Julien (ja...@ni...) -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: Francisco P. A. <fra...@di...> - 2005-02-23 17:59:42
|
I'm poking around with the new RC1 version.. so.. first of all i had some confusion betwen old .conf format and the new.. i supose the old .9 conf files are not interpreted as well.. right? i have an HD44780 lcd now my troubles are: I didn't get how to use virtual rows and cols (a virtually bigger screen, scrolling around my real one..i think) maybe i didn't get in which section this rows, scroll, etc params go.. I didn't get to work my sensors.. they seem not to be detected well.. altough my lmsensors is working ok.. i tried kernel modules and compiled in.. i have a via mini-itx board.. with "vt1211-isa-6000" chip.. anyway i get this: Feb 23 18:50:32 scarpiera LCD4Linux[2364]: i2c_sensors: unable to autodetect i2c sensors! uhm.. how does he autedetect this?? Another strange behaviour of my HD44780 is that it is not able to visualize personalized icons and bars that are not either North nor East oriented.. is this normal (i'm not trying to display all this things in the SAME time.. just separately)? maybe it should redefine the icons in function of the free character it has, right? Finally I was also arguing what was the msr.h support for lcd4linux used for? i get this: Feb 23 18:50:32 scarpiera LCD4Linux[2365]: udelay: The file 'include/asm/msr.h' was missing at compile time. What would the benefits be.. and why is the ./configure not detecting this .h in my system? i have it in /asm altough.. and of course my /proc/cpuinfo says i have msr support.. ;) Ok i also have a feature suggestion if it would be not too complicated: since the bar indicators are automagically scaling according to the maximum value they register.. after a while and after for instance a big download burst, the eth indicator is almost invisible on the bar.. is it possible to set some sort of timeout which resets the peak maximum scale value? it would realy be visually more appealing.. thanks for attention and sorry for the too many questions i flowed in with.. =) hope someone has time for them, anyway thanks for this great sw! tent:wq -- Dr. Francisco Peralta Aguaron SysAdmin DSY.it Dipartimento di Scienze dell'Informazione Forum Studenti fra...@di... te...@ds... http://www.10t8or.com http://www.dsy.it PGP-FP: BE5C 0DCA DDB2 3729 B348 4FF3 3BD6 BD7A 1AD6 FA95 |
|
From: paul k. <pau...@xs...> - 2005-02-23 10:23:52
|
Hi, Sorry for the delay. I had some other things to care of. (work.. :-) ) >Ok then, did you found out which header files to include? >It should be something like <i2c.h> and not <linux/12c.h> as I had >before. It was even commented out because it did not really compile... > > > No i did include <linux/i2c.h> and <linux/i2c-dev.h>. I have no other i2c.h header files available. You need to include <linux/compiler.h> before them to make them compile correctly. But it is no longer possible to use the i2c_smbus functions. You need that ioctrl function for that now. >Anyway, from my experiences, you must create a very static >lcd4linux.conf file, just as a test. No bars, no scrollers no >moving icons, just something like showing the Linux kernel version. > > > I'll have to check on how to create such a config file. Is only a display configuration sufficient? >About the display connections, how did you wired it? In my driver >I used the same type of connections that Martin Hejl uses in his >GPIO driver for Soekris boards (http://soekris.hejl.de/wiring.gif) > > > No, I use a different wiring. I use a display unit from a project I did 2 years ago. It is from an ergometer (http://www.relitech.nl/nl/PAG16.HTM, it is in dutch from our 'old' company website. The new site is almost ready) It has to PCF8574 devices connected to the i2c bus. One for the display and the other for a Led-bar graph and 3 input control keys. I checked that I could control the PCF8574 by using the led-bar graph. The display is connected like this: PCF8574 Display P0 DB4 P1 DB5 P2 DB6 P3 DB7 P4 R/W P5 RS P6 E P7 - The display is powered by 5 V and and the PCF8574 by 3.3V (from the i2c interface on my VIA EPIA board). It could be that this is part of the problem. In the original design the PCF8574 was powered by 5 V. So the output might be to low voltage for the display to see it correctly. I verified the initialisation/command sequence in lcd4linux. It is nearly the same as I used on the original project. cheers, Paul |
|
From: Xavier V. <xav...@fr...> - 2005-02-20 14:53:36
|
Hello Andre ! > just wanna ask if somebody is working on a driver > for the SED1335? If not, i would give it a try. As far as I know, there's no driver for this display in the nextgen lcd4linux (aka 0.10). I know Michael has one, so he may help you in the process of writing one. Bye ! -- Xavier VELLO <xav...@fr...> |
|
From: S.Trautvetter <st...@tr...> - 2005-02-20 11:37:02
|
Hallo Herr Reinelt, =20 in meiner Firma werden unter anderem auch verschiedene Display-Module mit USB-Schnittstelle entwickelt und produziert. Bisher ist deren Ansteuerung unter Windows mit jaLCDs und teilweise mit LCDHype = m=F6glich. Eine Einbindung in eigene Anwendungen ist mittels ActiveX m=F6glich. Die Anwendungsm=F6glichkeiten sind aber bisher auf Windows-Systeme beschr=E4nkt. In letzter Zeit h=E4ufen sich jedoch die Anfragen nach = einer Unterst=FCtzung f=FCr Linux und Mac. Bei der Suche nach geeigenten M=F6glichkeiten zur Ansteuerung auf = anderen Plattformen als Windows, bin ich auf lcd4linux gesto=DFen. Ihrem News-Ticker konnte ich entnehmen, dass einige Displays mittels libusb angesteuert werden, wof=FCr es ja sogar eine Mac-Implementierung geben soll. Zur Zeit bin ich mit der Entwicklung eines SDK in C++ besch=E4ftigt, welches bereits unter Windows und Suse Linux 9.1 bedingt ausf=FChrbar = ist. Das Ziel dabei soll die einfache und anschauliche M=F6glichkeit zur Integration von TREFON USB-Displays in Anwendungen auf verschiedensten Plattformen sein. Wenn das SDK in den n=E4chsten Wochen nutzbar ist, w=E4re das n=E4chste = Ziel die Integration in lcd4linux. Daf=FCr m=F6chte ich gern von Ihnen = erfahren, welche Vorgensweise angebracht ist. =20 =20 Mit freundlichen Gr=FC=DFen Stephan Trautvetter =20 ------------------------------------------------------------------------ ----------------------------- TREFON electronic GmbH Fichtenweg 4 99198 Erfurt-Kerspleben Germany Fon: 036203/576-30 Fax: 036203/576-50 <http://www.trefon-electronic.de/> http://www.trefon-electronic.de =20 |
|
From: Andre A. <an...@ro...> - 2005-02-19 12:28:24
|
Hi there, just wanna ask if somebody is working on a driver for the SED1335? If not, i would give it a try. Andre |
|
From: Luis.F.Correia <Lui...@se...> - 2005-02-15 08:50:42
|
Hi!
(yes, i'm still reading)
> -----Original Message-----
> From: paul kamphuis [mailto:pau...@xs...]
[snip]
>
> Now to the way on how to do it. (Luis are you still reading,
> here comes your I2C API :-) )
>
> file = open("/dev/i2c-0",O_RDWR); // open i2c bus
> ioctl(file,I2C_SLAVE,0x26); // select device
> struct i2c_smbus_ioctl_data args;
> args.read_write = I2C_SMBUS_WRITE;
> args.size = I2C_SMBUS_BYTE;
> args.command = 0x03; // <- this is the byte to write!!
> ioctl(file,I2C_SMBUS,&args); // write byte to selected device
Ok then, did you found out which header files to include?
It should be something like <i2c.h> and not <linux/12c.h> as I had
before. It was even commented out because it did not really compile...
Anyway, from my experiences, you must create a very static
lcd4linux.conf file, just as a test. No bars, no scrollers no
moving icons, just something like showing the Linux kernel version.
This is necessary in order to reduce the amount of information that
lcd4linux will force on the driver.
At first I just got the .conf file from my router and the result
was a very big mess... :)
So please feel free to adapt my code to whatever you think doable.
About the display connections, how did you wired it? In my driver
I used the same type of connections that Martin Hejl uses in his
GPIO driver for Soekris boards (http://soekris.hejl.de/wiring.gif)
> There is hardly any documentation on this and it required
> some digging in kernel source code to find that 'command'
> should contain the byte write. But it does work, to write a
> byte to the port.
>
> Now for the sad news. The display doesn't start yet. Of
> course this can have several reasons, that I still have to
> look into. It might even require bringing an oscilloscope
> home from work.
>
> Luis, thanks for your feedback!
>
> Paul
>
Have fun!
Luis Correia
|
|
From: paul k. <pau...@xs...> - 2005-02-15 08:34:18
|
I contacted the person (sorry the e-mail is currently unavailable so I
am not sure about his name) responsible for the port of the pcf8574
module to kernel 2.6. He was so kind to answer my questions.
first this code:
char buf[1];
buf[0] = 4;
file = open("\sys\bus\i2c\devices\0-0020\write",O_WRONLY);
write(file,buf,1);
Is correct, except that this file only accepts asci strings. So it
should be something like this;
char buf[1];
buf[0] = '4';
file = open("\sys\bus\i2c\devices\0-0020\write",O_WRONLY);
write(file,buf,1);
To send a byte to the I2C bus.
Now to the way on how to do it. (Luis are you still reading, here comes your I2C API :-) )
file = open("/dev/i2c-0",O_RDWR); // open i2c bus
ioctl(file,I2C_SLAVE,0x26); // select device
struct i2c_smbus_ioctl_data args;
args.read_write = I2C_SMBUS_WRITE;
args.size = I2C_SMBUS_BYTE;
args.command = 0x03; // <- this is the byte to write!!
ioctl(file,I2C_SMBUS,&args); // write byte to selected device
There is hardly any documentation on this and it required some digging in kernel source code to find that 'command' should contain the byte write. But it does work, to write a byte to the port.
Now for the sad news. The display doesn't start yet. Of course this can have several reasons, that I still have to look into. It might even require bringing an oscilloscope home from work.
Luis, thanks for your feedback!
Paul
Luis.F.Correia wrote:
>Hi!
>
>
>
>>-----Original Message-----
>>From: paul kamphuis [mailto:pau...@xs...]
>>Sent: Monday, February 14, 2005 7:51 AM
>>To: lcd...@li...
>>Subject: [Lcd4linux-devel] connecting i2c lcd
>>
>>Hi,
>>
>>First things first, my quick test last friday didn't work! Besides it
>>would have been to easy if it worked just like this.
>>
>>To investigate it a little further, I also did a test with a pcf8574
>>driving some led's. (Sometimes you are just lucky to have
>>something like
>>that available). I used the following piece of C code to test it.
>>
>>char buf[1];
>>buf[0] = 4;
>>file = open("\sys\bus\i2c\devices\0-0020\write",O_WRONLY);
>>write(file,buf,1)
>>
>>At power up the leds outputs are clearly in an undefined
>>state (some on,
>>some off) After running the above code all led's go off. So there is
>>activity, but not the desired. (note the strange code of 4 to
>>turn on a
>>led. There are 19 led's connected so it is encoded.)
>>
>>There is a different way to access a device, and it goes like this
>>through the command line:
>>
>>$ echo 4 > \sys\bus\i2c\devices\0-0020\write
>>This correctly turns on the desired led.
>>
>>
>
>For all that I know, this is the best way to drive something connected to a
>/sys/bus interface.
>
>All other methods should be used programatically.
>
>
>
>>Is there anyone who has an idea of the difference between the
>>C code and
>>the command line?
>>
>>
>
>Try to write some C code using the I2C api.
>
>
>
>>Paul
>>
>>
>>
>
>Luis
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Lcd4linux-devel mailing list
>Lcd...@li...
>https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
>
>
>
>
|
|
From: Luis.F.Correia <Lui...@se...> - 2005-02-14 09:07:21
|
Hi!
> -----Original Message-----
> From: paul kamphuis [mailto:pau...@xs...]
> Sent: Monday, February 14, 2005 7:51 AM
> To: lcd...@li...
> Subject: [Lcd4linux-devel] connecting i2c lcd
>
> Hi,
>
> First things first, my quick test last friday didn't work! Besides it
> would have been to easy if it worked just like this.
>
> To investigate it a little further, I also did a test with a pcf8574
> driving some led's. (Sometimes you are just lucky to have
> something like
> that available). I used the following piece of C code to test it.
>
> char buf[1];
> buf[0] = 4;
> file = open("\sys\bus\i2c\devices\0-0020\write",O_WRONLY);
> write(file,buf,1)
>
> At power up the leds outputs are clearly in an undefined
> state (some on,
> some off) After running the above code all led's go off. So there is
> activity, but not the desired. (note the strange code of 4 to
> turn on a
> led. There are 19 led's connected so it is encoded.)
>
> There is a different way to access a device, and it goes like this
> through the command line:
>
> $ echo 4 > \sys\bus\i2c\devices\0-0020\write
> This correctly turns on the desired led.
For all that I know, this is the best way to drive something connected to a
/sys/bus interface.
All other methods should be used programatically.
> Is there anyone who has an idea of the difference between the
> C code and
> the command line?
Try to write some C code using the I2C api.
>
> Paul
>
Luis
|
|
From: paul k. <pau...@xs...> - 2005-02-14 07:51:57
|
Hi,
First things first, my quick test last friday didn't work! Besides it
would have been to easy if it worked just like this.
To investigate it a little further, I also did a test with a pcf8574
driving some led's. (Sometimes you are just lucky to have something like
that available). I used the following piece of C code to test it.
char buf[1];
buf[0] = 4;
file = open("\sys\bus\i2c\devices\0-0020\write",O_WRONLY);
write(file,buf,1)
At power up the leds outputs are clearly in an undefined state (some on,
some off) After running the above code all led's go off. So there is
activity, but not the desired. (note the strange code of 4 to turn on a
led. There are 19 led's connected so it is encoded.)
There is a different way to access a device, and it goes like this
through the command line:
$ echo 4 > \sys\bus\i2c\devices\0-0020\write
This correctly turns on the desired led.
Is there anyone who has an idea of the difference between the C code and
the command line?
Paul
|
|
From: Luis.F.Correia <Lui...@se...> - 2005-02-11 16:57:59
|
Hi! We'll wait for your return home :) p.s. i'll be away for the weekend, so I'll probably not be able to produce any help. Luis > -----Original Message----- > From: paul kamphuis [mailto:pau...@xs...] > Sent: Friday, February 11, 2005 3:17 PM > To: lcd...@li... > Subject: Re: [Lcd4linux-devel] RE: [lcd4linux] problem with > i2c connected LCD display > > Yes, I have seen that one. Good you bring it up. > Isn't the diagram exactly showing where the problem is? > In the 'past' a User-space Program could talk directly to > i2c-dev using > the i2c_smb functions. > Now it should go through a client. > The question now is: is the pcf8574 kernel module the client > or a driver? > > Paul > > PS: I did a quick test. Changing the i2c_smb_write functions to an > ordinary write function and > opening /sys/bus/i2c/0-0026/write as the device file. > lcd4linux starts normal (starting main loop) > The big question remains. Do I have a working display? I > wouldn't know. > I am at work, and the display is at home. So it is going to be a > surprise for me later today. :-) > > > > > Luis.F.Correia wrote: > > >Hi! > > > >Just a small sidenote : > > > >This diagram explains how it can be implemented. > >http://secure.netroedge.com/~lm78/docs.html > > > >Luis > > > > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Lcd4linux-devel mailing list > Lcd...@li... > https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel > |
|
From: paul k. <pau...@xs...> - 2005-02-11 15:17:23
|
Yes, I have seen that one. Good you bring it up. Isn't the diagram exactly showing where the problem is? In the 'past' a User-space Program could talk directly to i2c-dev using the i2c_smb functions. Now it should go through a client. The question now is: is the pcf8574 kernel module the client or a driver? Paul PS: I did a quick test. Changing the i2c_smb_write functions to an ordinary write function and opening /sys/bus/i2c/0-0026/write as the device file. lcd4linux starts normal (starting main loop) The big question remains. Do I have a working display? I wouldn't know. I am at work, and the display is at home. So it is going to be a surprise for me later today. :-) Luis.F.Correia wrote: >Hi! > >Just a small sidenote : > >This diagram explains how it can be implemented. >http://secure.netroedge.com/~lm78/docs.html > >Luis > > > |
|
From: Luis.F.Correia <Lui...@se...> - 2005-02-11 14:49:06
|
Hi! Just a small sidenote : This diagram explains how it can be implemented. http://secure.netroedge.com/~lm78/docs.html Luis > -----Original Message----- > From: Luis.F.Correia [mailto:Lui...@se...] > Sent: Friday, February 11, 2005 12:10 PM > To: lcd...@li... > Subject: RE: [Lcd4linux-devel] RE: [lcd4linux] problem with > i2c connected LCD display > > Hi! > > Please do not post HTML or Rich-Text to this mailing list. It > is annoying! > > > >From: paul kamphuis [mailto:pau...@xs...] > >Sent: Friday, February 11, 2005 11:39 AM > >To: lcd...@li... > >Subject: Re: [Lcd4linux-devel] RE: [lcd4linux] problem with > i2c connected > LCD display > > > > Thanks for the answers. > > > > If I understand correctly there is no longer a > userspace layer for > the i2c > > interface. (or at least not supposed to be) > > > > Wrong, there is a userspace layer!!! What is not suppose to > happen is we > communicate > with the hardware directly. (kernel space) > > You must use the I2C infrastructure as is provided by the i2c project. > Start here: http://secure.netroedge.com/~lm78/download.html > > If you are using any 2.6 kernel you will not need the > i2c-2.9.0 package. > > Now try to compile i2c against your kernel sources, but > without patching the > kernel. > Then load the appropriate i2c modules that support your bus > type. Load the > PCF7584 > module and try to access it (read/write via /sys interface). > > If you can access it, try to write some values and see if the > chip pins > reflect those > values. > > If all goes ok, then start to investigate how to access it > programaticly > from the i2c > API. > > > > If I understand the pcf8574 kernel module correctly. Is > this no more > then a wrapper > > around these i2c_smb functions. So it can't be much slower then > calling them directly. > > The main advantage of this concept it that all (byte) > devices have > these read and > > write files. So you could use any device available. > > > > So for a start, I give the pcf8574 a try. Shouldn't > take to long to > test. > > Lets see if you are right that it is too slow. ;-) > > > > Paul > > > Best of luck! > > Luis > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from > real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Lcd4linux-devel mailing list > Lcd...@li... > https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel > |
|
From: Luis.F.Correia <Lui...@se...> - 2005-02-11 12:10:35
|
Hi! Please do not post HTML or Rich-Text to this mailing list. It is annoying! >From: paul kamphuis [mailto:pau...@xs...] >Sent: Friday, February 11, 2005 11:39 AM >To: lcd...@li... >Subject: Re: [Lcd4linux-devel] RE: [lcd4linux] problem with i2c connected LCD display > > Thanks for the answers. > > If I understand correctly there is no longer a userspace layer for the i2c > interface. (or at least not supposed to be) > Wrong, there is a userspace layer!!! What is not suppose to happen is we communicate with the hardware directly. (kernel space) You must use the I2C infrastructure as is provided by the i2c project. Start here: http://secure.netroedge.com/~lm78/download.html If you are using any 2.6 kernel you will not need the i2c-2.9.0 package. Now try to compile i2c against your kernel sources, but without patching the kernel. Then load the appropriate i2c modules that support your bus type. Load the PCF7584 module and try to access it (read/write via /sys interface). If you can access it, try to write some values and see if the chip pins reflect those values. If all goes ok, then start to investigate how to access it programaticly from the i2c API. > If I understand the pcf8574 kernel module correctly. Is this no more then a wrapper > around these i2c_smb functions. So it can't be much slower then calling them directly. > The main advantage of this concept it that all (byte) devices have these read and > write files. So you could use any device available. > > So for a start, I give the pcf8574 a try. Shouldn't take to long to test. > Lets see if you are right that it is too slow. ;-) > > Paul Best of luck! Luis |
|
From: paul k. <pau...@xs...> - 2005-02-11 11:39:37
|
Thanks for the answers. If I understand correctly there is no longer a userspace layer for the i2c interface. (or at least not supposed to be) If I understand the pcf8574 kernel module correctly. Is this no more then a wrapper around these i2c_smb functions. So it can't be much slower then calling them directly. The main advantage of this concept it that all (byte) devices have these read and write files. So you could use any device available. So for a start, I give the pcf8574 a try. Shouldn't take to long to test. Lets see if you are right that it is too slow. ;-) Paul Luis.F.Correia wrote: >Ok, i'll try to give as much info as I can... > > > >>-----Original Message----- >>From: paul kamphuis [mailto:pau...@xs...] >>Sent: Friday, February 11, 2005 10:39 AM >>To: lcd...@li... >>Subject: Re: [Lcd4linux-devel] RE: [lcd4linux] problem with >>i2c connected LCD display >> >>Hi there, >> >>Thanks for inviting me in! I already gave the 0.10 source >>code a quick >>look (just a download from the sources on the website, no CVS >>access yet) >>Compiles nicely for me, so no problem there. >> >>I agree with Luis his code, it looks nice and usable. But it doesn't >>compile :'( >>I spend some time looking for a solution on the internet, and it is a >>bit of a horror story. >> >> > >Calm down :) it is now as bad as that... > > > >>First Luis, did you ever get this code working? Right now I assume it >>could have worked with a 2.4.x kernel. >> >> > >Yes, it was tested with 2.4.26, but I'm using a very non standard thing >that is, not using external I2C things, but the included linux i2c >'extensions'. > >Then I used the i2c driver for the WRAP platform (which is what I was >working >on back then). (http://www.pcengines.ch/wrap.htm) > >I did not use any kind of modules at all, I did plain old direct access >to the chip via the i2c_smbus commands. > > > >>The thing is, the kernel team decided that user space (application) >>access to /dev/.. should not be done. For that reason most kernel >>includes are no longer available. Only exception the i2c includes. >><linux/i2c.h> etc, but including them results in compile errors. (As >>Michael noted) >>The reason is an undefined __user__ macro. Which is part of the >>kernel teams effort to change the user space behaviour (if I >>understand >>correctly). Only found a single note on how to solve it; add #include >><linux/compiler.h>. And yes, it compiles nicely. Unfortunatly >>it doesn't >>link. The i2c_smbus functions are unresolved. So far I found >>no solution >>for this :'( >> >> > >Yes, that was the issue I was trying to solve when I finally gave up. >We should not do direct kernel mode calls, but use the userspace layer >the i2c project provides. I could not make it work with my WRAP device. > > > >>So how does the kernel team wants us to access devices? If I >>understand >>it correctly it is supposed to go through dedicated kernel >>modules like >>pcf8574 (part of the 2.6 kernel) which are supposed to show up as >>devices in /sys (sysfs). I am using the Gentoo 2.6.10-r6 kernel and a >> >> modprobe pcf8574 >> >> > >That combined with the correct bus driver for your hardware should make >it work OK. > > > >>results in a /sys/bus/i2c/devices/0-0020 device. This contains (among >>some other files) a read and write file. Apperently writing >>to the write >>file should write data to the connected pcf8574. (I haven't >>tested it yet) >> >>So my question is. Would going for the /sys device be the >>right solution >>for lcd4linux? >> >> > >Well, it 'may' work, but it is probably very slow to access. > >You should use the I2C API to access the device (if there is one) > > > >>Paul >> >> >> > >Luis Correia > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >_______________________________________________ >Lcd4linux-devel mailing list >Lcd...@li... >https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel > > > > |
|
From: Luis.F.Correia <Lui...@se...> - 2005-02-11 10:59:37
|
Ok, i'll try to give as much info as I can... > -----Original Message----- > From: paul kamphuis [mailto:pau...@xs...] > Sent: Friday, February 11, 2005 10:39 AM > To: lcd...@li... > Subject: Re: [Lcd4linux-devel] RE: [lcd4linux] problem with > i2c connected LCD display > > Hi there, > > Thanks for inviting me in! I already gave the 0.10 source > code a quick > look (just a download from the sources on the website, no CVS > access yet) > Compiles nicely for me, so no problem there. > > I agree with Luis his code, it looks nice and usable. But it doesn't > compile :'( > I spend some time looking for a solution on the internet, and it is a > bit of a horror story. Calm down :) it is now as bad as that... > > First Luis, did you ever get this code working? Right now I assume it > could have worked with a 2.4.x kernel. Yes, it was tested with 2.4.26, but I'm using a very non standard thing that is, not using external I2C things, but the included linux i2c 'extensions'. Then I used the i2c driver for the WRAP platform (which is what I was working on back then). (http://www.pcengines.ch/wrap.htm) I did not use any kind of modules at all, I did plain old direct access to the chip via the i2c_smbus commands. > > The thing is, the kernel team decided that user space (application) > access to /dev/.. should not be done. For that reason most kernel > includes are no longer available. Only exception the i2c includes. > <linux/i2c.h> etc, but including them results in compile errors. (As > Michael noted) > The reason is an undefined __user__ macro. Which is part of the > kernel teams effort to change the user space behaviour (if I > understand > correctly). Only found a single note on how to solve it; add #include > <linux/compiler.h>. And yes, it compiles nicely. Unfortunatly > it doesn't > link. The i2c_smbus functions are unresolved. So far I found > no solution > for this :'( Yes, that was the issue I was trying to solve when I finally gave up. We should not do direct kernel mode calls, but use the userspace layer the i2c project provides. I could not make it work with my WRAP device. > > So how does the kernel team wants us to access devices? If I > understand > it correctly it is supposed to go through dedicated kernel > modules like > pcf8574 (part of the 2.6 kernel) which are supposed to show up as > devices in /sys (sysfs). I am using the Gentoo 2.6.10-r6 kernel and a > > modprobe pcf8574 That combined with the correct bus driver for your hardware should make it work OK. > > results in a /sys/bus/i2c/devices/0-0020 device. This contains (among > some other files) a read and write file. Apperently writing > to the write > file should write data to the connected pcf8574. (I haven't > tested it yet) > > So my question is. Would going for the /sys device be the > right solution > for lcd4linux? Well, it 'may' work, but it is probably very slow to access. You should use the I2C API to access the device (if there is one) > > Paul > Luis Correia |
|
From: paul k. <pau...@xs...> - 2005-02-11 10:39:27
|
Hi there, Thanks for inviting me in! I already gave the 0.10 source code a quick look (just a download from the sources on the website, no CVS access yet) Compiles nicely for me, so no problem there. I agree with Luis his code, it looks nice and usable. But it doesn't compile :'( I spend some time looking for a solution on the internet, and it is a bit of a horror story. First Luis, did you ever get this code working? Right now I assume it could have worked with a 2.4.x kernel. The thing is, the kernel team decided that user space (application) access to /dev/.. should not be done. For that reason most kernel includes are no longer available. Only exception the i2c includes. <linux/i2c.h> etc, but including them results in compile errors. (As Michael noted) The reason is an undefined __user__ macro. Which is part of the kernel teams effort to change the user space behaviour (if I understand correctly). Only found a single note on how to solve it; add #include <linux/compiler.h>. And yes, it compiles nicely. Unfortunatly it doesn't link. The i2c_smbus functions are unresolved. So far I found no solution for this :'( So how does the kernel team wants us to access devices? If I understand it correctly it is supposed to go through dedicated kernel modules like pcf8574 (part of the 2.6 kernel) which are supposed to show up as devices in /sys (sysfs). I am using the Gentoo 2.6.10-r6 kernel and a modprobe pcf8574 results in a /sys/bus/i2c/devices/0-0020 device. This contains (among some other files) a read and write file. Apperently writing to the write file should write data to the connected pcf8574. (I haven't tested it yet) So my question is. Would going for the /sys device be the right solution for lcd4linux? Paul Michael Reinelt wrote: > Hi there, > >>> I am willing to give it a shot, if you are prepared to provide me >>> with some assistance on where to start and how to start. It would be >>> my first effort on writing code on linux. >> >> >> >> No problem, I'm not really a C expert but at least I can help you >> to follow the 'good line'. :) > > > Hey, would be great if someone would work on this part! I can't be of > any help, because I don't have neither an I2C port on my notebook, nor > an I2c Interface. But I like the code from Luis, and I think we've got > a good framework for using HD44780 over two different busses. > > The main reason for the i2c code not working is that most of the code > is #ifdef'ed out because I can't get it to compile. maybe some header > or something is missing.... I don't know. > > Paul, the first thing you'll have to do is getting anonymous CVS > access, so you can work on the latest version of the source. If you > need assistance with CVS or anything other, please let me know. > > > bye, Michael > |
163 messages has been excluded from this view by a project administrator.
){kind=link}