i've been working on an i2c communication among a unique master and several slaves... (the source code i based on were the microchip application notes 734 and 735) The first thing i need to do in my application is verifying the presence of the slaves and a problem has rised: once the master sends an address that produces a NOT acknowledge, no other slave responds to the next call even though the address is correct... the source code has a routine to handle acknowledge errors, so that such routine sets the bus free when a NOT acknowledge is received (AN735)
PDD the application has been simulated in proteus6
does anybody have any idea of what i could be doing wrong?
That might functions if you run it on SMBus (a newer variant of i2c for PC hardware). But definitely it will not work on i2c! There doesn't exists an time-out in the spec. Timing is not a great issue with i2c. What counts is where a edge on SCL oder SDA comes in relation to logic states (on bus and inside the state machines).
the problem with the verification of slaves has been finaly solved: as I could not find the literarature regarding the "bus reset" i tried something that worked out: in the main cycle of the slave program the sspbuf is read (in each cycle) if such slave is not in the middle of a communication... in this way it is sure that when the master calls it its sspbuf register will be clear and ready to answer
but another problem has rised:
when working with a slave as transmitter, after setting sspcon2.RCEN, the SDA line is supposed to get the value of the most significant bit contained in SSPBUF and then shifting out the next bits with the falling edges of the SCL line (so that the second bit of the byte to be transmitted is shifted out with the falling edge of the first clock pulse, the third bit with the second falling edge... and so on), but what happens in my case is that the first bit shifted out is not the MSB (bit 7), but the next (i.e. the sixth). With this, data like
10000000 is received by the master as 0 because the first bit shifted out is a 0 (bit 6) and both, the first and second clock pulses read 0; and data like 01000000 is received as 11000000 because with the first and second clock pulses a 1 is read. Using a scope probe to view the state of the SDA & SCL lines -simulation in proteus 6- i saw that the first change in the bits to be shifted out is not happening at the first falling edge of SCL but in the second....
I have been thinking and i see no reason for this to happen, and i was wondering if it was possible that the error is being caused by the environment (proteus 6), not by the source code. And if it is not so, what could i be doing wrong?
Those control bits are CKP (clock polarity) which must be set after writing sspbuf (according to i2c specs), and i am not sure about which is that control bit for clock phase, but maybe you're referring to (please correct me if i'm wrong) CKE (clock edge select) that, when working in i2c mode, must be set for SMBUS specs input levels or cleared for i2c specs input levels ...
in my code CKE is always clear in the slaves [which are (like the master) PIC16f877], and CKP is set after writing sspbuf (as sugested above)
but what should i check by that control bits besides that?
Sorry for not having this very clear but, as you already know, I´m just a beginner...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.