| View previous topic :: View next topic |
| Author |
Message |
agpccosta
Joined: 07 Jul 2006
Posts: 5
|
 Posted: Sun Nov 07, 2010 11:43 pm Post subject: Linux 'i2c-parport' module & JP1. How? |
 |
|
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: |
# 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:
| Quote: | ...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/01/i2c-remote-evilness.html
|
I gather from the above quote that the 'eeprom' module is also involved, but it's not obvious how that's done.
Last edited by agpccosta on Mon Nov 15, 2010 7:53 pm; edited 1 time in total |
|
| Back to top |
|
 |
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
|
| Back to top |
|
|
agpccosta
Joined: 07 Jul 2006
Posts: 5
|
| Posted: Tue Nov 09, 2010 5:22 pm Post subject: More than one way to do it |
|
|
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. |
|
| Back to top |
|
|
binky123
Expert
Joined: 14 Feb 2004
Posts: 1292
|
| Posted: Tue Nov 09, 2010 6:39 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
agpccosta
Joined: 07 Jul 2006
Posts: 5
|
| Posted: Wed Nov 10, 2010 5:16 am Post subject: |
|
|
No success yet, but here's what I have so far, taking binky123's advice.
Given:
| Code: | 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: | [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: | % 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... |
|
| Back to top |
|
|
classicsat
Joined: 20 Feb 2004
Posts: 279
|
| Posted: Sun Nov 14, 2010 9:22 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
agpccosta
Joined: 07 Jul 2006
Posts: 5
|
| Posted: Mon Nov 15, 2010 7:52 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
