Linux device drivers for Rapberry Pi on-board I/O

Ok.

No joy here

Code: Select all

root@berry:~# ls /dev/i2c*
ls: cannot access /dev/i2c*: No such file or directory
root@berry:~# modprobe i2c
root@berry:~# ls /dev/i2c*
/dev/i2c
root@berry:~# i2cdetect -l


Any thoughts ?

i2cdetect doesn't work for this driver, bootc from #raspberrypi is working on integrating the driver in Linux, because it is similar to the work he has done already with his SPI driver. Watch this repository for updates: https://github.com/bootc/linux/commits/rpi-spi

Time for an update.

bootc has completed his driver, and I can confirm it works with my test case of 3 off 1-wire i2c bus masters.

Code: Select all

root@...# time /opt/owfs/bin/owread /uncached/bus.0/28.5B8A57030000/type
DS18B20
real   0m0.023s

root@...# time /opt/owfs/bin/owread /uncached/bus.0/28.5B8A57030000/temperature
     18.8125
real   0m1.404s


bootc has created a Debian package to install the new Linux kernel with the I2C driver, now integrated in the Linux I2C framework, so all tools like i2cdetect etc. are working as expected. I had problems with my SD card and the latest SD card driver, but after restoring the first version of the SD card driver and recompiling the kernel, it worked with my IO Expander board with a PCA9555. See

http://www.bootc.net/archives/2012/05/1 ... pberry-pi/

and

http://www.bootc.net/archives/2012/05/2 ... pi-kernel/

There is even a version 3.2.18 of it in his latest blog post, but I didn't tried it so far.

My test:

Code: Select all

root@raspberrypi:~# modprobe i2c-dev
root@raspberrypi:~# i2cdetect -l
i2c-0   i2c          bcm2708_i2c.0                      I2C adapter
i2c-1   i2c          bcm2708_i2c.1                      I2C adapter
root@raspberrypi:~# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --                         


Playing a bit with the driver: looks like activating the 3rd BSC module for the HDMI interface works. HDMI cable connected:

Code: Select all

    root@raspberrypi:~# i2cdetect 2
    WARNING! This program can confuse your I2C bus, cause data loss and worse!
    I will probe file /dev/i2c-2.
    I will probe address range 0x03-0x77.
    Continue? [Y/n] y
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
    00:          -- -- -- -- -- -- -- -- -- -- -- -- --
    10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    30: -- -- -- -- -- -- -- 37 -- -- 3a -- -- -- -- --
    40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
    60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    70: -- -- -- -- -- -- -- --


Otherwise all "--". I don't know, if there can be a conflict with the GPU or if it can damage something, so I'm not sure about if this should be included in the kernel, but maybe still fun to play with it. The patch to the kernel version from bootc:

http://pastebin.com/cnxsusJD

Hi - could frank's I2C kernel object be incorporated into a bare metal control program for a headless robot project and run without the kernel? What additional code would also be required? If this is not possible could the kernel be easily adapted to run the control program instead of full Linux?

pygmy_giant: would be difficult to use my code without Linux, because first you would need to implement a multitasking system for wait_event_interruptible_timeout/wake_up_interruptible. And then all the other things related to request_irq with interrupt handling etc. But the rest of the code should work then without much changes.
But depending on your realtime requirements, you can use Linux for controlling robots. For hard realtime you need something like http://en.wikipedia.org/wiki/RTLinux . I don't know, if this runs on ARM computers and I guess would need some work to port it to the Raspberry Pi. But if you can live with some milliseconds latency from time to time, and below a millisecond latency most of the time, you can use the standard Linux, even from user space programs. With your own drivers and interrupts it can be even better, if the network and USB drivers don't block interrupts too long.

mabrowning: Python can be used to communicate with the I2C bus on the Raspberry Pi. With the Debian image all you need to do is "sudo apt-get install python-smbus" and then you can use e.g. http://www.frank-buss.de/io-expander/i2c-test.py with "python i2c-test.py". I've tested it and works like a charm.

Thanks Frank - valuable info. There is some discussion on other threads around a 'bare metal' solution as many projects only require output via GPIO pins. I don't have the understanding to build a driver or kernel from scratch so will try with a full linux solution to begin with. I may experiment with trimming away unwanted parts of the OS if this is not fast enough.

I could knock up a GPIO pins bare metal example in arm asm, but i have no R-PI to test it on, is there anyone that would test it at there own risk ?.
Has its a wast of my time, if no one will test it.

I could knock up a GPIO pins bare metal example in arm asm, but i have no R-PI to test it on, is there anyone that would test it at there own risk ?.
Has its a wast of my time, if no one will test it.

I'll test it

Cool, give a day or two and i will knock a bare metal test GPIO in asm.
I may even convert it to FBasic to make its easier to understand.

Cool, give a day or two and i will knock a bare metal test GPIO in asm.
I may even convert it to FBasic to make its easier to understand.

Someone did this already, it might help with your projects:

https://github.com/raspberrypi/firmware ... nt-5362664

Cool, give a day or two and i will knock a bare metal test GPIO in asm.
I may even convert it to FBasic to make its easier to understand.

Someone did this already, it might help with your projects:

https://github.com/raspberrypi/firmware ... nt-5362664

Thanks for the link Frank.

I've enabled 1-wire, too. For testing I've uploaded my pre-compiled kernel, if you don't want to compile your own kernel. See viewtopic.php?f=44&t=6649 , it contains the I2C driver, too.

I have tried to change the i2c bus speed with a reg write but it defaults back when the i2c function is called.
Running Debian with Frank's W1-test update. Using C with i2c-dev.h, Ive cloned the gpio setup_io() function with the address for the BSC0_BASE at 0x205000 and can read the default clock div register at *(bsc0+5) (not bsc0+0x14) .This value is 0x9c4 (2500) with the i2c-dev module installed and the BCM default 5dc(1500) when not installed.
But when i write the clk_div , it is set but always re-set to 0x9c4 after an i2c call, write(fd,buf,count) , ive only used pic's before so im in deep water .
Im guessing this is applicable to many drivers, but is there a way to get around this . Could i over-write the non-BCM default value of 0x9c4 in its origional location ?
I was wanting to slow the I2C bus to experiment with long wires.
Many thanks

I have tried to change the i2c bus speed with a reg write but it defaults back when the i2c function is called.

You can't easily do that. If you use the kernel driver, then the driver 'owns' all of the i2c registers and will over write anything you do.

So you have two choices:

1. find out where/how the driver sets the bus speed, modify that and recompile the kernel/driver to do what you want.

2. use a kernel that doesn't have an i2c driver, then you need to re-implement the whole driver as a userspace program (this way nothing else will overwrite your configuration)

For an example of how the driver does it, look here https://github.com/bootc/linux/blob/rpi ... -bcm2708.c and find static inline void bcm2708_bsc_setup at line 132. That function calculates and then sets the clock divisor to get the required speed. From there you find on line 69 #define I2C_CLOCK_HZ 100000. So you can change the define to whatever you like within the limits of the divisor, rebuild the module and get the desired effect.

Just a link to my latest post, if you are watching this thread: now it works for Raspbian, too: viewtopic.php?p=149799#p149799

Hi,
After changing the original kernel.img to the i2c version build by Frank Buss the mouse stops working in
de graphical environment.
Does anyone knows a solution?

marcus

I didn't had problems with the mouse. But you can just install the latest Raspbian “wheezy” ( 2012-09-18-wheezy-raspbian.zip), the new I2C and one-wire driver is already included in it, no need to install my kernel anymore. For I2C you can use it like this:

Code: Select all

modprobe i2c-bcm2708
modprobe i2c-dev


You can do "apt-get install i2c-tools" to test it with i2cdetect: "i2cdetect -l" should print the two I2C device driver instances, i2c-0 and i2c-1 and "i2cdetect -y 0" should detect all attached I2C devices.

Dont forget to change raspi-blacklist.conf and add the
two # in front of the blacklist entries

Code: Select all

sudo nano /etc/modprobe.d/raspi-blacklist.conf
# blacklist spi and i2c by default (many users don't need them)
#blacklist spi-bcm2708
#blacklist i2c-bcm2708


God bless you boffins – there is a debate on another thread about whether linux + I2C gyros/accellerometers could handle balancing a robot on 2 wheels. I for one am following your progress with interest – you are doing valuabe work…

I find your post encouraging.

I seem to have i2c in some capacity installed. Nothing in dmesg as far as interrupts go.

i2cdetect -y 0 reports 54. I can't look at /dev/i2c-0 for some reason, even as root. *shrugs* Has anyone gotten this accelerometer working in ANY way on the RPi?

Can someone tell me what bcm2708_i2c is? I see it everywhere in dmesg and other places.

For example...
bcm2708_i2c bcm2708_i2c .0: BSC0 Controller at 0x20205000 (irq 79)
bcm2708_i2c bcm2708_sp1 .0: SPI Controller at 0x20204000 (irq 80)
bcm2708_i2c bcm2708_i2c .1: BSC1 Controller at 0x20804000 (irq 79)
Am I getting CLOSE even?
Thanks muchly. I sincerely look forward to the day I can be of some service in here, besides asking questions.

I've created a short howto:

http://www.frank-buss.de/raspberrypi/index.html

I hope it is easy to understand and there is no error in it.

Hello,
I am trying to read the temperature from a MLX90614 over the I2C bus. The device needs the following I2C transaction:
| START | WR ADR | REG | REP_START | RD ADR | BYTE | STOP |

The REG is the register's address (inside the slave device) you want to read the value from.

Is the BSC able to generate a REPEATED START between the WRITE and READ operations? There are a lot of discussions on the forum on this issue but no clear answers. The spec is also very unclear on this matter.

Best regards,
Dan.