 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Chevy64
Joined: 05 Apr 2013
Posts: 7
|
| I2C How it works?? |
 Posted: Wed Oct 26, 2016 2:17 am |
 |
|
Hi Guys:
My question will not be a kind of trouble shooting question it is going to be to understand the rationale behind the I2C functions. I am trying to establish pic to pic communication via I2C bus. I have read related previous posts and run the scanner program (Tnx By the way) on both famous simulation program well as on silicon.
First, I thought that I could give any slave address to my slave however it turned out that not the case. By trial and error I found that number 0X10 worked and is acked by scanner. What/why that number worked but others?
| Code: | | #use i2c(Slave, SDA=PIN_C4, SCL=PIN_C3,Force_HW, ADDRESS=0x10) |
Second, I have problems to understand ex_slave.c codes, i.e. magic function
| Code: | | state = i2c_isr_state(); |
I can understand why function returns with zero but other numbers such as
| Code: | | if(state >= 0x80) //Master is requesting data |
intuitively feeling that some kind of window shifting left for 4 bits on buffer and sampling, because number 80 will be will be meaning full. Again intuitively kind of counter must counts how many packet of data arrived to such as:
| Code: | else if(state >= 2 && state != 0x80) //Received byte is data
// buffer[address++] = incoming;
readBuffer[state - 1] = i2c_read(); //LSB first and MSB second
if (state==2){
Counter=make16(readBuffer[1],readBuffer[0]); |
Because [state-1] puts correct place in an array.
I will appreciate it if you guys either explain or direct me to any source that I can read too. Tnx |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19366
|
|
| Posted: Wed Oct 26, 2016 3:04 am |
|
|
The manual does cover a lot of this. However it is not exactly well described. Also some needs you to read the I2C specification:
| Code: |
state meaning
0 Address has been received with write bit set
1..07F Counts up for each subsequent byte
0x80 Address has been received with read bit set
0x81..FF Again counts up for each subsequent byte required
|
Now key things then are what 'must' happen:
Values 0 to 0x7F all imply there is a byte waiting to be read. The code must read it. Simply increments for each byte in turn. Normally just throw away the address byte (0).
Then 0x80, also says a byte is waiting to be read (again the address). The code must read this. It also though says that the _next_ transaction will be a read by the master, so the slave needs to write a byte ready for this transaction. This is the one transaction where both a read an write must happen. Effectively the 'crossover' state between read transactions and write transactions.
Values above this each say another byte should be loaded. Again increments for each byte.
There is a limitation here, in that a maximum of 126 bytes is all that can be handled as a single transaction, without the counter overflowing into the top bit. However most I2C devices have lower length limits than this (typically 16, or 64 bytes), for sequential transfers, so this would never normally be met.
Now the order of the bytes is completely up to the device and you. You could send data LSB first or LSB second. Most devices send LSB first, but there are ones that send MSB first. Down to reading the data sheet for the device concerned.
Then addresses. Addresses 0x00 to 0x0F, and 0xFF are reserved in the I2C specification. I suspect this is why you found 0x10 was the first that worked for you. 112 legal addresses. 0x10, 0x12, 0x14 etc.. This is in both the I2C specification, and the PIC data sheet.
Then there is clock stretching. Now on I2C, when a byte is received, it holds the clock line low, until it has finished handling it. By default, the line is released, when the slave reads the byte. So the master will pause for a moment, until this has happened. On byte 0x80, you can use I2C_read(2), which is special instruction to say "don't release the clock". This is worth using, if the master is fast, and might try to read the byte for transmission, before it has been loaded. Then write the new byte, and release the clock. It is worth explicitly setting the CKP bit yourself at this point to do this. The actual behaviour varies according to timing, and the chip involved. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Wed Oct 26, 2016 3:07 am |
|
|
Never rely on guessing (otherwise known as "intuition") in engineering! Always read the manual, and the datasheet.
If you do read the datasheets of I2C devices, you will find they generally can't be assigned random addresses. Instead they are usually preset to a small range of addresses, often, but not always, with some pin or a few pins allowing them to be assigned specific addresses within that range.
The CCS manual tells you what the state means. There is also example code which shows how it should be used. Many, many people come on here, such as yourself, clearly showing they have at best half-read the manual, and thus not understood what they have to do, or partially copied the example, and thus not correctly handled the state variable. You don't have to understand the rationale behind the design (which is pretty straightforward when you think about it), you just have to know how to use it. There is no C source that we, or anyone else can point you to: the routine is not a C routine. |
|
|
Chevy64
Joined: 05 Apr 2013
Posts: 7
|
| Thank you |
| Posted: Wed Oct 26, 2016 3:55 am |
|
|
Thank you Guys for information. Have to say manual is not so informative however needs to be read. CCS C help file is a copy of manual.
It is not necessary to put KW on the air most of times QRP works well.  |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
