We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi Everybody, I'm experimenting with Infineon's XC161CJ-controller on an Infineon SK-XC16x starter kit. Most of my routines work now, except the I2C-routines. Sending of data works OK, but the errors occur when I want to receive data. Has anybody on this forum written I2C-routines for this controller? And if so, are you willing to share them? Thanks in advance. :) Kind Regards, Dennis Ebben
Hallo Stefan, Könntest Du mir den Low-Level-Treiber von Infineon auch zukommen lassen. Habe auch Probleme den I2C-Bus ans laufen zu bekommen. Email: m.stahl@moba.de Danke im vorraus. Dear Stefan could you share your code. I have also some problems with the i2c-routines. email: m.stahl@moba.de Best regards
Hi Michael, I sent it. With german remarks ;-). Check your account. Stefan
hello, i'm working with xc167 an also had many problems with i2c. is it possible to share your code an send it to me? thanks a lot. e-mail: mo@mimot.de michael
Hi Michael, done.
Hi Stefan, although this thread is over 18 months old now, today I experienced exactly the same problems while implementing a serial eeprom driver. So, may I humbly ask you for your routines too? Thank you very much in advance. My email is uwe.roth@web.de Uwe
Hi Uwe, the routines are based on the hardware implemented I2C module of XC16x devices. So I am not sure, whether they would be usefull to you. If you want them still, however, I see no problem to mail them to you. Let me know Stefan
Yes, of course. I'm using (i.e. I'm trying to use) the IIC of a XC161CJ (in polling mode). Using the Pins of P9 with a software emulated I2C Bus would be an alternative, but I'd like to avoid this. Uwe
Hi Uwe, sorry for delay, I will mail it in some minutes. Good luck, Stefan
You may also find this useful: http://www.keil.com/download/docs/xc16x_i2c_ex.zip.asp
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