Why don't you use the gpio function?
Well, I tried to use them but that lead to same result.
void at91sam9260_i2c_init(void) { at91_set_GPIO_periph(AT91_PIN_PA23, 0); at91_set_multi_drive(AT91_PIN_PA23, 1);
at91_set_A_periph(AT91_PIN_PA24, 0);
Why?
at91_set_multi_drive(AT91_PIN_PA24, 1); }
void at91sam9260_i2c_scl(unsigned long bit) { at91_set_gpio_value(AT91_PIN_PA24, bit); }
void at91sam9260_i2c_sda(unsigned long bit) { at91_set_gpio_value(AT91_PIN_PA23, bit) } int at91sam9260_i2c_read(void) { retrun at91_get_gpio_value(AT91_PIN_PA23); } void at91sam9260_i2c_active() { gpio_direction_output(AT91_PIN_PA23, 0); }
void at91sam9260_i2c_tristate() { gpio_direction_input(AT91_PIN_PA23); }
Thanks a lot for your help, but this did not work either. iprobe returns full 0x0 - 0x7f range as devices. Linux i2c-gpio works properly and returns proper set of devices (0x68, 0x50). Is it me or there's bug somewhere? I can see output values with oscilloscope. I wonder what happens.
I sync it will be better to use the hardware stack which is not too complicate to implement
As commented in Linux kernel about i2c_at91, it is very buggy, and I was afraid that it could not work for me at all. i2c-gpio works in Linux. What prevents soft i2c from working ont the same CPU? This stuff is a mystery for me :(