Good news, I've finished a first version of the driver for the BSC module, with interrupts. For faster turnaround cycles, I have written it as an external modul:http://pastebin.com/hLCmdkb5
For rebuilding, you'll need a kernel cross compilation environment, as described at http://elinux.org/Rpi_kernel_compilation
. Then you can install the modules on the host machine:
- Code: Select all
make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- modules_install
This makes the Makefile very easy:
- Code: Select all
obj-m += i2c.o
make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- -C /lib/modules/3.1.9+/build M=$(PWD) modules
make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- -C /lib/modules/3.1.9+/build M=$(PWD) clean
Now you can create the i2c.ko module with "make", copy it to the Raspberry Pi, and load it with "insmod i2c.ko", and unload it with "rmmod i2c.ko". Very useful for driver development, when the datasheet is not very clear. E.g. for the I2C driver it was not clear for me, if I can write to the FIFO before the transfer started (which is not possible), or the fact that the RXR bit was not set in the interrupt, but the RXD bit.
My Linux test program works with it, the device is /dev/i2c, for SDA0/SCL0. The next days I'll try to integrate it in my Linux kernel at https://github.com/FrankBuss/linux/
. The hardware part of the driver works, so this is just some Linux coding and should be finished until next weekend.
Some points to discuss:
- how should we set the bus speed? For most devices 100 kHz should be ok, but I like the Omap concept, that you can specify it as a kernel parameter: i2c_rate=bus_id,clkrate . bus_id could be from 0 to 2 and clkrate from 100 to 400. Another idea would be a special IOCTL command in the driver to set it at runtime, but I didn't found a standard for it.
- how do we set the alternative function of the GPIO pins? I've hardcoded it in the my first version, but I think it should be an exported function from the driver bcm2708_gpio.c
- do we need the other functions as well from the i2c-dev interface? E.g. 10 bit addresses and SMBus commands: http://www.mjmwired.net/kernel/Document ... -interface (I've never seen 10 bit addresses in real life systems)
- is the wait_event_interruptible_timeout concept clean, e.g. no race conditions, concept used as in other drivers?
When I integrate it in the Linux kernel, I'll clean up the resource handling, so that the GPIO pins are reserved from the kernel like with the current GPIO-I2C version, and the BSC IO areas will be defined as resources, too.