Linux 'i2c-parport' module & JP1. How?

[agpccosta]

I'm interested in having a non-emulator Linux hardware interface to my JP1 remotes. There's a kernel module that seems as though it might be right for the job, but I haven't yet found any docs online (even here) that explain how to hook things up, just some leads and clues. So here's some of the clues for other Linux users:

Code: Select all

# from the shell, print usage info about 'i2c-parport'
%/sbin/modinfo i2c-parport
filename:       /lib/modules/2.6.32-5-686/kernel/drivers/i2c/busses/i2c-parport.ko
license:        GPL
description:    I2C bus over parallel port
author:         Jean Delvare <khali@linux-fr.org>
depends:        parport,i2c-algo-bit,i2c-core
vermagic:       2.6.32-5-686 SMP mod_unload modversions 686 
parm:           type:Type of adapter:
 0 = Philips adapter
 1 = home brew teletext adapter
 2 = Velleman K8000 adapter
 3 = ELV adapter
 4 = ADM1032 evaluation board
 5 = ADM1025, ADM1030 and ADM1031 evaluation boards
 6 = Barco LPT->DVI (K5800236) adapter
 7 = One For All JP1 parallel port adapter
 (int)

Elsewhere J. McDowell's 2007 blog claims he's done it:

...I found a couple of old Linux tools, but then I had a thought: it's just i2c. Why not tie it into the proper i2c subsystem? Turns out the i2c-parport driver makes this sort of thing easy; all you add is a single entry defining the appropriate parallel port lines to wiggle and it all magically works.

So now I can talk to my remote using the eeprom driver talking to the i2c subsystem which talks to the remote over the parallel port adaptor I built. Which feels wonderfully sick. :) Now I need to actually have a closer look at getting all the buttons working for my new TV...
http://www.earth.li/~noodles/blog/2007/ ... lness.html

I gather from the above quote that the 'eeprom' module is also involved, but it's not obvious how that's done.

[gfb107]

No need for that.

See https://www.hifi-remote.com/forums/viewt ... 0884#p60884 ,
https://www.hifi-remote.com/forums/viewtopic.php?t=6741 and
https://www.hifi-remote.com/forums/viewtopic.php?t=12557

[agpccosta]

Thanks for those links; while RM is useful and worthwhile, (NB: I haven't yet tried it in Linux), it sounds a bit high level, (Java as opposed to C), and as such is beyond the intended scope of this thread. Plus it's good policy to have several ways to do something, so that if "Plan A" fails, we can fall back on "Plan B". Also I want to see how the kernel module method works, the better to compare it to other methods; and if nothing else, to have a public thread document the comparison -- surely I'm not the only one intrigued by 'i2c-parport' .

Speculative: Better still would be a psuedo file system ('fuse' perhaps) on top of a low level driver, so we could use 'mc' to move indivdual ROM files around.

[binky123]

I think you first load the i2c-parport module(modprobe i2c-parport type=7) and then run a EEPROM reader program like eeprog ( http://codesink.org/eeprog.html ) to use the device /dev/i2c created by the i2c-parport module.

The I2C subroutines are currently built into RMIR and IR.exe. You would replace those routines with calls to use the i2c-parport interface if you wanted to integrate this method into RMIR/IR. Another way is to convert the EEPROM data(read out by whatever reader/writer program you use) into the .IR format used by RMIR and IR.

[agpccosta]

No success yet, but here's what I have so far, taking binky123's advice.

Given:

Code: Select all

modprobe -v i2c-parport type=7

It's necessary to unload any parallel port modules (e.g. 'modprobe -rv lp parport'), otherwise an error pops up in 'dmesg':

Code: Select all

[461489.579278] parport0: cannot grant exclusive access for device i2c-parport
[461489.579283] i2c-parport: Unable to register with parport

It's necessary to load 'i2c-dev' to create the device files. If loading order matters, probably 'i2c-dev' needs to be loaded before 'i2c-parport'.

Loading 'i2c-dev' looks like this:

Code: Select all

% modprobe -v i2c-dev
insmod /lib/modules/2.6.32-5-686/kernel/drivers/i2c/i2c-dev.ko 
# show the devices
% ls -l /dev/i2c*
crw-rw---- 1 root i2c 89, 0 Nov 10 04:46 /dev/i2c-0
crw-rw---- 1 root i2c 89, 1 Nov 10 04:46 /dev/i2c-1
crw-rw---- 1 root i2c 89, 2 Nov 10 04:46 /dev/i2c-2

After which, 'modprobe -v i2c-parport type=7' runs without error. There's no error even if no remote is plugged into the parallel port JP1 connector.

Short term goal: to read some data from a remote.

Other related puzzles...

Whether a software method exists for checking correct cable orientation.

When it's advisable to plug/unplug things.

How to tell which of the three '/dev/i2c-?' devices is a JP1.

The syntax of 'eeprog' with a URC-8810B00 remote.

More soon...

[classicsat]

Well, for the JP1 remotes, you have to assert (lower) the Reset line on the remote to read them. It can be assumed, when Reset is not asserted, that it is safe to unplug the remote.

As for orientation, of it doesn't read correctly, then it can be assumed it is incorrectly connected.

Maybe /var/messages will say which device was loaded by the i2cdev module.

[agpccosta]

Still experimenting with 'i2c-parport', but no nothin' yet. Modules are loaded, but there's no feedback in 'dmesg' that anything was discovered, or not discovered. Perhaps it's time to email some upstream module authors.