i2c Bus speed

  • Hello,


    take a look at the kernel sources; <drivers/i2c/busses>
    i think, that it is similarly to the netdcu8-sources; the bus and max-frequency is hard coded in a platform-dependet source file (whole i2c initialisation). at the moment i can't look at the picocom1 sources, but i think, the name of this file is similarly to "i2c-at91xyz".

  • Hi,


    There is a hardware problem/error in the AT91SAM9260 regarding the integrated I2C hardware. In the PicoCOM1 Linux kernel, the hardware I2C driver is disabled and the GPIO-driven bitbanging driver is enabled. For adjusting the I2C speed, you have to look in the kernel (and recompile it).


    More information: http://www.at91.com/forum/viewtopic.php/f,9/p,31336/


    You can try to change the file

    Code
    1. drivers/i2c/busses/i2c-gpio.c

    at line 132. However, because this is a software-only driver, changing the speed may slow down your system.


    Simon

  • Thanks for information.


    Is it an Atmel problem or a Linux problem with the TWI/irq 'bug'?


    But I think Atmels world is SPI, and TWI owns NXP.


    And the speed-issue, how is the delay-time between a falling and rising edge realized in the kernels driver?
    Using timer/interrupts than I beleave that increasing speed increase cpu-time.


    On the other hand I need the hardware information by scanning the i2c chips and control their outpout pins.
    That's an important part of the application.


    best regards
    Günter

  • Hello Günter,


    Quote from "GKollmann"

    Is it an Atmel problem or a Linux problem with the TWI/irq 'bug'?


    It is definitely an Atmel problem. I have read about the different efforts about circumventing that bug in the I2C-Atmel driver, but in the AT91SAM9260, it ist not possible. However, the 'bitbanging'-GPIO-driver works good.


    Quote from "GKollmann"

    And the speed-issue, how is the delay-time between a falling and rising edge realized in the kernels driver?
    Using timer/interrupts than I beleave that increasing speed increase cpu-time.


    I don't know how the change of the parameter will change the timing. I have tried it for slowing down the speed, but the parameter is not linear (i think because of the overhead of the code compared to the delay). I think they use something like a delay loop ('udelay()').
    But if you want to control this with an interrupt (both rising and falling edge), you will need an interrupt with 2 x I2C frequency (for 400 kbps a 800 kHz timer). This is quite fast for a 200 MHz CPU. As far as i know, the Fast-Interrupt (FIQ) is not used in the linux kernel and the ARM cpu. With a little bit assembler, i think it should be possible to program a quite nice I2C routine, if you have too much time left :-)


    Quote from "GKollmann"

    On the other hand I need the hardware information by scanning the i2c chips and control their outpout pins.
    That's an important part of the application.


    We use massively the I2C bitbanging driver without any problems since 1.5 years... with hotplugging and automatic scanning for new devices!


    Simon

  • Thanks Simon


    may be it's why Atmel prefered the SPI.. TWI is the domain from NXP :)


    I used irq-driven i2c with Arm7 LPC2xxx, a lot of chips connected over 4way multiplexer and it woks perfekt.


    The SCL-speed now is at 200kHz and seams to be ok.


    best regards
    Günter