Post by thread:[PIC]: 16C74a - I2C module & vague documentation.

Hello All, I'm trying to write some code for the 16C74A's I2C-module, and have a nice time interpreting the documentation. I've got MicroChip's Microcontroller databook in front of me (1996/1997 edition, document DS30390D) , and have some questions about the following: At page 10-77 the contents of the (read-only) SSPSTAT-register are explained. The R/W -bit seems only to be valid during "the transmission" ... What transmission ? Up untill a Stop-bit is detected ? Up untill another Address-byte is received ? Or up untill the last bit of the current Address send ? (would be quite short I would say :-). Could somebody help me out here ? Does anybody have any drawings that explain the relations of the bits in the SSPSTAT-register to the actual I2C-signals ? Furthermore I must assume that the bits P & S are mutually exclusive (only one of them can be a "1" at a time). Is obvious if you know it, but is nowhere mentioned in the text ... Next question: How can I determine what the response (Ack/not Ack) was on a Slave-transmission by the ' 74 ? Page 10-90 tells me that the ACK-bit is sampled, but not what is being done with it, or even if the missing ACK effects anything at-all ... It could mean that a Master-device could not-Acknowledge a byte, but go on with generating clock-pulses, and I (the ' 74) would be nothing the wiser ... That can't be true ! Come on guys/girls, Anyone ? Hmm... I just tought of something ... How would the ' 74 (as Slave) react if I would swap the Start & Stop-bits on my Master-device ? Will have to try that some time ... Would double the possible number of devices on the bus. By the way: Watch-out for the BF-bit ... It does not really reflect the actual state of the Buffer. Reading the SSPBUF right after it goes high will not immediatily clear it. Regards, Rudy Wieser -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

As in the subject. Did anyone recieve the below message ? I can't believe no-one knows anything about the SSP/I2C-Module of the 16C74A .... Regards, Rudy Wieser ---------- {Quote hidden}> Van: Caisson <spam_OUTcaissonTakeThisOuTTELEBYTE.NL> > Aan: .....PICLISTKILLspam@spam@MITVMA.MIT.EDU > Onderwerp: [PIC]: 16C74a - I2C module & vague documentation. > Datum: vrijdag 11 augustus 2000 11:35 > > Hello All, > > I'm trying to write some code for the 16C74A's I2C-module, and have a > nice time interpreting the documentation. I've got MicroChip's > Microcontroller databook in front of me (1996/1997 edition, document > DS30390D) , and have some questions about the following: > > At page 10-77 the contents of the (read-only) SSPSTAT-register are > explained. > > The R/W -bit seems only to be valid during "the transmission" ... What > transmission ? Up untill a Stop-bit is detected ? Up untill another > Address-byte is received ? Or up untill the last bit of the current > Address send ? (would be quite short I would say :-). > > Could somebody help me out here ? Does anybody have any drawings that > explain the relations of the bits in the SSPSTAT-register to the actual > I2C-signals ? > > > Furthermore I must assume that the bits P & S are mutually exclusive (only > one of them can be a "1" at a time). Is obvious if you know it, but is > nowhere mentioned in the text ... > > Next question: How can I determine what the response (Ack/not Ack) was on > a Slave-transmission by the ' 74 ? Page 10-90 tells me that the ACK-bit is > sampled, but not what is being done with it, or even if the missing ACK > effects anything at-all ... It could mean that a Master-device could > not-Acknowledge a byte, but go on with generating clock-pulses, and I (the > ' 74) would be nothing the wiser ... That can't be true ! Come on > guys/girls, Anyone ? > > > Hmm... I just tought of something ... How would the ' 74 (as Slave) react > if I would swap the Start & Stop-bits on my Master-device ? Will have to > try that some time ... Would double the possible number of devices on the > bus. > > By the way: Watch-out for the BF-bit ... It does not really reflect the > actual state of the Buffer. Reading the SSPBUF right after it goes high > will not immediatily clear it. > > Regards, > Rudy Wieser -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

{Quote hidden}> -----Original Message----- > From: Caisson [SMTP:caissonKILLspamTELEBYTE.NL] > Sent: Monday, August 14, 2000 8:32 AM > To: .....PICLISTKILLspam.....MITVMA.MIT.EDU > Subject: Re: [PIC]: 16C74a - I2C module & vague documentation. - Did > anyone receive this message ? > > As in the subject. Did anyone recieve the below message ? I can't > believe > no-one knows anything about the SSP/I2C-Module of the 16C74A .... > > Regards, > Rudy Wieser > > ---------- > > Van: Caisson <EraseMEcaissonspam_OUTTakeThisOuTTELEBYTE.NL> > > Aan: PICLISTspam_OUTMITVMA.MIT.EDU > > Onderwerp: [PIC]: 16C74a - I2C module & vague documentation. > > Datum: vrijdag 11 augustus 2000 11:35 > > > > Hello All, > > > > I'm trying to write some code for the 16C74A's I2C-module, and have a > > nice time interpreting the documentation. I've got MicroChip's > > Microcontroller databook in front of me (1996/1997 edition, document > > DS30390D) , and have some questions about the following: > > > > At page 10-77 the contents of the (read-only) SSPSTAT-register are > > explained. > > > > The R/W -bit seems only to be valid during "the transmission" ... What > > transmission ? Up untill a Stop-bit is detected ? Up untill another > > Address-byte is received ? Or up untill the last bit of the current > > Address send ? (would be quite short I would say :-). > > > The R/W bit is valid only directly after receiving the device address. The R/W bit effectively mirrors the LSB of the incomming byte, so after receiving non-address data, it will very likely have changed. This is easy to get around, just check the D/A bit in SSPSTAT in your interrupt code. If an address has just been received, copy the R/W bit into a register somewhere. Then on the next interrupt, your code can check this bit to see whether it should be sending data or receiving it. > > Could somebody help me out here ? Does anybody have any drawings that > > explain the relations of the bits in the SSPSTAT-register to the actual > > I2C-signals ? > Sorry no. I just fiddled until it worked. > > > > > > Furthermore I must assume that the bits P & S are mutually exclusive > (only > > one of them can be a "1" at a time). Is obvious if you know it, but is > > nowhere mentioned in the text ... > > I have to admitt, I've not used either the P or S bits in my implementation and I'm not entirely sure under what circumstances you would need to use them. {Quote hidden}> > Next question: How can I determine what the response (Ack/not Ack) was > on > > a Slave-transmission by the ' 74 ? Page 10-90 tells me that the ACK-bit > is > > sampled, but not what is being done with it, or even if the missing ACK > > effects anything at-all ... It could mean that a Master-device could > > not-Acknowledge a byte, but go on with generating clock-pulses, and I > (the > > ' 74) would be nothing the wiser ... That can't be true ! Come on > > guys/girls, Anyone ? > > If a master generates an ACK, the slave expects to be sending more data to it, so the ACK causes another interrupt to occurr. If the master NACKs the slave, then the slave hardware assumes that was the last byte in the transmission and no interrupt is fired. That is the correct implementation of the I2C bus. Unfortunately many masters will ACK the last byte which can cause all sorts of problems which have been broughtup on the list several times. If this happens you basically need to load the SSPBUF with a dummy byte after the last ACK. > > > > Hmm... I just tought of something ... How would the ' 74 (as Slave) > react > > if I would swap the Start & Stop-bits on my Master-device ? Will have > to > > try that some time ... Would double the possible number of devices on > the > > bus. > > Sorry, don't know about this. > > By the way: Watch-out for the BF-bit ... It does not really reflect the > > actual state of the Buffer. Reading the SSPBUF right after it goes high > > will not immediatily clear it. > > > > Regards, > > Rudy Wieser > Equally watch out if you are trying to use an emulator. Putting a break point anywhere causes the emulator to read all the registers to update the display on the PC. Unfortunately, this can cause BF to be cleared which breaks your code. This was the RF Solutions ICEPIC BTW. Regards Mike -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

> > Van: Caisson <@spam@caissonKILLspamTELEBYTE.NL> > > Aan: KILLspamPICLISTKILLspamMITVMA.MIT.EDU > > Onderwerp: [PIC]: 16C74a - I2C module & vague documentation. > > Datum: vrijdag 11 augustus 2000 11:35 > > > > Hello All, [Snip] > > The R/W -bit seems only to be valid during "the transmission" ... What > > transmission ? Up untill a Stop-bit is detected ? Up untill another > > Address-byte is received ? Or up untill the last bit of the current > > Address send ? (would be quite short I would say :-). > > The R/W bit is valid only directly after receiving the device address. The > R/W bit effectively mirrors the LSB of the incomming byte, so after > receiving non-address data, it will very likely have changed. This is easy > to get around, just check the D/A bit in SSPSTAT in your interrupt code. If > an address has just been received, copy the R/W bit into a register > somewhere. Then on the next interrupt, your code can check this bit to see > whether it should be sending data or receiving it. Right ! So the R/W bit is valid upto the next "byte received" interrupt. Hmm... Strange ... They are able to keep the level of a Start/Stop bit, but can't seem to be able to retain the level of the R/W bit upto the next incoming Address-byte .... > > Could somebody help me out here ? Does anybody have any drawings that > > explain the relations of the bits in the SSPSTAT-register to the actual > > I2C-signals ? > > Sorry no. I just fiddled until it worked. Yep. That's what I'm doing now. Not exacly what I expected to do (fiddeling around) when having the documentation at hand ... :-( Ah, well, It's a nice day :-) > > > Furthermore I must assume that the bits P & S are mutually exclusive > > (only > > > one of them can be a "1" at a time). Is obvious if you know it, but is > > > nowhere mentioned in the text ... > > I have to admitt, I've not used either the P or S bits in my implementation > and I'm not entirely sure under what circumstances you would need to use > them. > > Next question: How can I determine what the response (Ack/not Ack) was > > on a Slave-transmission by the ' 74 ? Page 10-90 tells me that the ACK-bit > > is sampled, but not what is being done with it, or even if the missing ACK > > effects anything at-all ... It could mean that a Master-device could > > not-Acknowledge a byte, but go on with generating clock-pulses, and I > > (the ' 74) would be nothing the wiser ... That can't be true ! Come on > > > guys/girls, Anyone ? > > If a master generates an ACK, the slave expects to be sending more data to > it, so the ACK causes another interrupt to occurr. If the master NACKs the > slave, then the slave hardware assumes that was the last byte in the > transmission and no interrupt is fired. That is the correct implementation > of the I2C bus. Unfortunately many masters will ACK the last byte which can > cause all sorts of problems which have been broughtup on the list several > times. If this happens you basically need to load the SSPBUF with a dummy > byte after the last ACK. The problem is that my ' 74 is a Slave. It should transmit bytes upto the point that the Master does not require any more (by Not-acknowledging the last byte). Just sending a Stop-condition is not really my idea of a gracious end-of-transmission. Apart from the fact that the I2C-specs do not allow it .... > Equally watch out if you are trying to use an emulator. Putting a break > point anywhere causes the emulator to read all the registers to update the > display on the PC. Unfortunately, this can cause BF to be cleared which > breaks your code. This was the RF Solutions ICEPIC BTW. Have not got a Emulator here. A Simulator is all I've got. But don't try to use it with anything reeking of Hardware either ... Most of the simulated hardware is (at best) *partially* implemented ... I dumped it when I found out that even something basic like the "weak pull-up's" for Port B (16C84) was not there ... Nahhh... I'll take JW-parts any time. If there are no EEProm-parts available that is <grin> Regards, Rudy Wieser -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

> As in the subject. Did anyone recieve the below message ? I can't believe > no-one knows anything about the SSP/I2C-Module of the 16C74A .... Yes, I remember seeing this message earlier. People don't reply for various reasons. I didn't because you were asking very detailed questions that I couldn't have answered without some time reading the data sheet again. You asked so many questions that it seemed to me the problem was a general confusion about IIC instead of a problem with specific PIC issues, and I saw no point duplicating the well written introduction to IIC in the Microchip literature. > > I'm trying to write some code for the 16C74A's I2C-module, and have a > > nice time interpreting the documentation. I've got MicroChip's > > Microcontroller databook in front of me (1996/1997 edition, document > > DS30390D) , and have some questions about the following: I didn't notice this before, but that is probably an old book. Either get the most recent data sheet, or look on the Microchip web site. IIC is relatively complex, and you definitely have to do some reading, especially the first time you try to use it. I do remember the Microchip documentation to be quite good, even providing background on how IIC works in general. There may also be an app note or two. Check the web site. Keep in mind that many of the PICs don't have the support to do master mode in hardware. I believe the 16C74A falls into this category. I gave up on the IIC module and controlled the lines directly from the firmware in master mode. Fortunately master mode is the easy one because you control the clock. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, RemoveMEolinTakeThisOuTcognivis.com, http://www.cognivis.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

Rudy Wieser asked: > > > Next question: How can I determine what the response (Ack/not Ack) > was > > > on a Slave-transmission by the ' 74 ? Page 10-90 tells me that the > ACK-bit > > > is sampled, but not what is being done with it, or even if the missing > ACK > > > effects anything at-all ... It could mean that a Master-device could > > > not-Acknowledge a byte, but go on with generating clock-pulses, and I > > > (the ' 74) would be nothing the wiser ... That can't be true ! Come > on > > > > guys/girls, Anyone ? > Michael Rigby-Jones replied: {Quote hidden}> > If a master generates an ACK, the slave expects to be sending more data > to > > it, so the ACK causes another interrupt to occurr. If the master NACKs > the > > slave, then the slave hardware assumes that was the last byte in the > > transmission and no interrupt is fired. That is the correct > implementation > > of the I2C bus. Unfortunately many masters will ACK the last byte which > can > > cause all sorts of problems which have been broughtup on the list > several > > times. If this happens you basically need to load the SSPBUF with a > dummy > > byte after the last ACK. > Rudy Wieser responded with: > The problem is that my ' 74 is a Slave. It should transmit bytes upto the > point that the Master does not require any more (by Not-acknowledging the > last byte). Just sending a Stop-condition is not really my idea of a > gracious end-of-transmission. Apart from the fact that the I2C-specs do > not allow it .... > I was refering to the PIC being the slave. If you have a nice buffer full of data to transmit, and you put a byte into SSPBUF and enable CKP, then when the master has received that byte it can either ACK it, or NACK it. If it sends an ACK, the SSPIF flag will get set and (providing they are enabled) an interrupt will occurr. In the interrupt you would normally put the next byte to be sent into SSPBUF. If the master sends a NACK, the interrupt will not occurr. The problem arises if you are writting your slave for an existing master that always ACK's any data it receives. In this case you have to deal with this in your ISR by putting a dummy byte into SSPBUF. The bottom line is that if the master correctly NACK's the last byte, you shouldn't have any problems in this area. Mike -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements

> Van: Olin Lathrop <spamBeGoneolin_piclistspamBeGoneCOGNIVIS.COM> > Aan: TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU > Onderwerp: Re: [PIC]: 16C74a - I2C module & vague documentation. - Didanyone receive this message ? > Datum: maandag 14 augustus 2000 14:54 > > > As in the subject. Did anyone recieve the below message ? I can't > believe > > no-one knows anything about the SSP/I2C-Module of the 16C74A .... > > Yes, I remember seeing this message earlier. People don't reply for various > reasons. I didn't because you were asking very detailed questions that I > couldn't have answered without some time reading the data sheet again. You > asked so many questions that it seemed to me the problem was a general > confusion about IIC instead of a problem with specific PIC issues, and I saw > no point duplicating the well written introduction to IIC in the Microchip > literature. As I remember, none of the questions where pointed at the I2C -protocol in general, but at how he different states are remembered/handled within the controller. Especially how the Status-bits (of the controller) respond. > > > I'm trying to write some code for the 16C74A's I2C-module, and have > > > a nice time interpreting the documentation. I've got MicroChip's > > > Microcontroller databook in front of me (1996/1997 edition, document > > > DS30390D) , and have some questions about the following: > > I didn't notice this before, but that is probably an old book. Either > get the most recent data sheet, or look on the Microchip web site. Well, you where right. I've got a CD here, the "First Edition 2000" that holds a new document (DS30390e). I just checked it, but it only adds specs for the ' 76 & ' 77. Nothing has changed for the orthers. :-( > IIC is relatively complex, and you definitely have to do some reading, > especially the first time you try to use it. I do remember the Microchip > documentation to be quite good, even providing background on how IIC works > in general. There may also be an app note or two. Check the web site. I think I've got a working knowledge of how the I2C-bus works, and I can bit-bang it in MasterMode on (for example) a 16x84. I've even written (machine-language) routines so I can access I2C-devices off a PC's Printer-port (interface-hardware limited to a few diodes & resistors). > Keep in mind that many of the PICs don't have the support to do master > mode in hardware. I believe the 16C74A falls into this category. I gave > up on the IIC module and controlled the lines directly from the firmware > in master mode. Fortunately master mode is the easy one because you > control the clock. I am implementing the Slave-mode. Regards, Rudy Wieser -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics