What value of pullup resistor are you using? 5K is probably about right. Definitely not less than 1K. I note that doc/i2c-pport doesn't make a recommendation. Fred Labrosse wrote: > Jean Delvare writes: > > > > > pcffl root # i2cdetect 0 > > > (...) > > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > > > 00: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f > > > 10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f > > > 20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f > > > 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f > > > 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f > > > 50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f > > > 60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f > > > 70: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f > > > > This is bad. Only 60 should answer, other addresses should show "XX". > > > > This is solved. Somebody (and I did not verify before hand) had configured > the parallel port to be on some silly address. It is now back to normal. > > > > > > One additional bit: > > > > > > pcffl root # cat /proc/sys/dev/parport/parport0/modes > > > PCSPP,TRISTATE > > > > That may be a problem. I think I remember the i2c-pport doc stating that > > the i2c-pport.c driver takes benefit of the features of modern parallel > > ports (usually known as EPP or ECP, as opposed to SPP). Looks like your > > parallel port doesn't support these modes, which may be why i2c-pport > > doesn't work. Maybe you need to enable it through the BIOS setup > > screen? > > > > Second, i2c-pport.c doesn't use the standard parport interface, i.e. it > > doesn't depend on the parport module - and is not even compatible with > > it AFAIK. This means that you should *not* load the parport module when > > using i2c-pport, because both modules will try to access the same I/O > > ports and that may be the problem. > > I indeed had to unload parport to make it work. Now i2cdetect doesn't > detect anything. I have been playing with a scope during the last hour or > 2 to try to see what was happening. It seems that the ACK signal is not > pulled down enough by the CMPS03 to be detected as such (I read 1V which is > probably a bit high for a 0V). This is confirmed in the messages: > > Apr 5 17:32:49 pcffl i2c-algo-bit.o: Used 4 tries to write client at 0x60 : no ack > Apr 5 17:32:49 pcffl i2c-algo-bit.o: NAK from device addr 60 msg #0 > > > > > > You may consider using i2c-philips-par (or i2c-parport in the 2.6 kernel > > tree) instead, but the electronics needed to interface with your chip > > are slighly different in this case, so you would have to change that. > > > > Yes, but that indeed involves a bit more of hardware, thus time and money > ;-). I wanted to try a fast quick and dirty way. It proves to be not that > fast. ;-). > > > > I hope someone can help me with that. Sorry for the long message. > > > > No problem, I hope you'll find a solution. Let us know! > > > > So any input as to why the device is not pulling down enough would be much > appreciated. Note however that I'm yet not sure this is indeed the > problem. I'll do more experiments tomorrow with a better scope. > > Thanks anyway. > > Fred > >
