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.
The KEIL header file for the XC167 microcontroller has the below entry:
#define IIC_ID (*((unsigned int volatile sdata *)0xE60C)) // IIC Module Identification Register
However, I can find no reference to any such register in any of the XC167 doc's I have. Can anyone tell me what this register is and how to use it?
Thanks, Dave.
Thanks for the response. I thought it must be something like that. I stumbled across that register definition while trying to figure out an IIC problem I was having with the XC167.
I got that peripheral to work, but thought it odd that it seems to require one more read cycle than the number of reads you want to do, to get valid results from the "read results" register. Seems like reading the "read results" register is what actually causes the IIC peripheral to clock in the read data, requiring you to read the "read results" register again to actually get the data, which has the unusual side effect of apparently clocking in another byte of data (that gets thrown away in my app).
I don't like having to waste the time associated with doing the "dummy read" (i.e., the extra SCL cycles), and it looks funny on my oscilloscope to see the extra SCL cycles, but, oh well... it does work. I don't know if there are any IIC devices where doing the extra "dummy read" would have an adverse effect on the IIC device. This "undocumented feature" smells like a chip bug to me; or at least, a design deficiency.
As far as I know the XC167 is basically too fast (so to speak) for the IIC peripheral and you only need to add nop's when you need to look for a action (read after a write to a particular register). The IIC module (state machine) needs extra clocks to update the its registers.
I was not aware that you need to add extra SCL clocks.
I wrote some code that adds the NOP's to the IIC in polled mode and as far as I know there aren't any extra SCL clocks.
Hmmm... something doesn't sound right...
It seems to me that what generates the SCL clocks is the act of reading either IIC_RTBL or IIC_RTBH. Then, after the SCL clocks, you must read the register again to get the results of shifting in that data.
But... reading that register the 2nd time causes the SCL clocks to come out again. That's what I'd like to get rid of... those extra SCL clocks. But, I can't find any other way to start the cycle of SCL clocks besides reading the IIC_RTBL or IIC_RTBH registers. Kind of like a catch-22 situation.