XC161CJ and I2C

Hi Matthias,

yes you are right. I will provide this link next time again too.
Unfortunately I discovered this nice XC167 example, just few a days before.

Thanks, for remember this,
Stefan

Hi Stefan,

could you please send me your sources too. I'm working on a project with the C161pi and looking for suggestions how to handle i2c communication. German comments are very welcome.
Please send it to bazoon@arcor.de

Thank you very much.

Hi Martin,

I sent it. Stefan

Hello,
I was just casually reading this thread because I have recently been writing some interrupt driven functions for the System management bus(similiar to I2C). I see requests for routines which "work" but no discussion of the root problem (in the hardware module?). Why does an extra read operation fix things up?

Hello Barry,

Why does an extra read operation fix things up?

This is a good question and I agree that it would be indeed more helpfull to know the root problem, but I do not know about any problems in the HW-modul as far as concerning XC166 family.
As I found the DAvE bugs and that we need some times a dummy read I contacted the Infineon guys for this stuff.
They gave me the low level driver and told me....
( sorry for some mistakes in following translation )

" ...that an extra read is not so unusual, if one is looking to the I2C protocoll.
One will see that only the master suplies the bus with a clock signal.
If one is setting the slave into the read mode, this does not mean that at same moment
valid datas are in the receive buffer.
It (the slave) can only write datas onto the bus, if it get a clock from the master.
That is why we need the dummy-read, to read after that the first valid data from the buffer." .... 

Hello Stefan,
Thanks for your informative post. Again I've just been working with SMB and don't know I2C at all but I've read they're quite similiar. At first I was confused by the 28 different sources for the interrupt vector but after sorting things out two things were apparent. The fardware modules have a state machine which manages the idle-address-data transfer-idle changes and that the ACK/NACK at the end of each transfer drove the interrupt requests. The most time critical part of the code was during a master read of a slave. You're right the master generates the clock and the slave hardware module shifts out whatever happens to be in the buffer at the time, so the slave had to have data ready in the buffer when the shifting starts! I rolled my own handler which uses dynamically sized packets, a dedicated isr packet buffer, and input and output circular buffers with interrupt protected read and write functions. NACK response includes a retry scheme with timeout error handler, this tolerates delay due to interrupt activity in the receiver module. It's set up for a multimaster connection and I'm still working on the arbitration scheme.
Cheers,
Barry

Hallo Stefan,
I have also big trouble with the i2c-module on the xc161. It will help me a lot if you send me your i2c routines.

Thank you very much.

Ralf

e-mail: winkelmann@eus.de

Hello Ralf,

sorry for the delay. I sent it.
Best regards Stefan

Hello Stefan,

I have the same problem of all other people. Can you send me the i2c routines al lunizzi(at)tin(dot)it ?

Thank you !

Hello Luciano,

no matter. Sent it to you.

Stefan

Yes, Neil. I agree with you. Sorry for forgetting it. Mehboob once you insert your code in between #pragma asm ... #pragma endasm directive, you need to set 2 options for that perticular file, which are:
1. Generate Assembler SRC file
2. Assemble SRC file

Thanks.
Pankaj

Yes, Neil. I agree with you. Sorry for forgetting it. Mehboob once you insert your code in between #pragma asm ... #pragma endasm directive, you need to set 2 options for that perticular file, which are:
1. Generate Assembler SRC file
2. Assemble SRC file

Thanks.
Pankaj

Hello Stefan,
could you send me the IIC Routines also to
erik.vischer@siemens.com
Thank you.
Best Regards
Erik

Does anyone have a copy of Stefans I2C code?
If so, could you please send it to: kgott@sciton.com.
Thanks!