[PIC] PIC18F I2C Start/Stop condition detection
Locked
 
|
Hi all,
I'm using I2C in slave mode on a PIC18F24Q10. The incoming packets are like this... http://orlandorobotbuilders.com/stuff/WD-I2C-hold-packet-01.gif The PIC18F24Q10 datasheet is here... https://ww1.microchip.com/downloads/en/DeviceDoc/PIC18F24-25-Q10-Data-Sheet-40001945D.pdf The MSSP has a flag and interrupt for Start and Stop condition (S & P bits in SSPxSTAT) and I tried this code in the ISR to detect these... if (SSP1STATbits.S == 1) { TX1REG = 'S'; SSP1STATbits.S = 0; } if (SSP1STATbits.P == 1) { TX1REG = 'P'; SSP1STATbits.P = 0; } (I'm using EUSART1 for debugging to a serial terminal). But I'm getting the 'S' 6 times for each message, and It's repeating the 'P' several times, even after the message is over. (The package is being sent once only). Am I missing something obvious here? BTW, I've worked around this already, but just want to know now. Cheers, -Neil. -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: [PIC] PIC18F I2C Start/Stop condition detection
|
|
Neil,
When looking at fig 26-17, it seems S remains high until stop is received. The description mentions 'detected last', which -although not very specific - might confirm that it remains high until a stop condition is detected. Joep Op zo 24 jan. 2021 om 06:59 schreef Neil <[hidden email]>: > Hi all, > > I'm using I2C in slave mode on a PIC18F24Q10. The incoming packets are > like this... > http://orlandorobotbuilders.com/stuff/WD-I2C-hold-packet-01.gif > > The PIC18F24Q10 datasheet is here... > > https://ww1.microchip.com/downloads/en/DeviceDoc/PIC18F24-25-Q10-Data-Sheet-40001945D.pdf > > The MSSP has a flag and interrupt for Start and Stop condition (S & P > bits in SSPxSTAT) and I tried this code in the ISR to detect these... > > if (SSP1STATbits.S == 1) > { > TX1REG = 'S'; > SSP1STATbits.S = 0; > } > > if (SSP1STATbits.P == 1) > { > TX1REG = 'P'; > SSP1STATbits.P = 0; > } > > (I'm using EUSART1 for debugging to a serial terminal). > > But I'm getting the 'S' 6 times for each message, and It's repeating the > 'P' several times, even after the message is over. (The package is > being sent once only). Am I missing something obvious here? > BTW, I've worked around this already, but just want to know now. > > Cheers, > -Neil. > > > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Joep,
I was looking at fig 26-15, because I was not using AHEN & DHEN. Even with the behaviour shown in fig 26-17, I was wondering why clearing this flag would not work, but I just this minute realized (from the SSPxSTAT register definition in fig 26.9.1) that the P and S bits are read-only. So this explains why my code detects the S bit every time I receive a byte in the ISR. I'm not sure now how they expect this feature to be used. My thought was that I'd detect the S bit, initialize my receiving buffer, capture bytes, then when I detect the P bit, verify the recipient (slave address in first byte) is my device and send off the bytes for processing in non-ISR code. I guess I could check for a change from P to S and S to P to get those transition points, but it's really not an issue, oh well. Cheers, -Neil. On 1/24/2021 2:50 AM, Joep Suijs wrote: > Neil, > > When looking at fig 26-17, it seems S remains high until stop is received. > The description mentions 'detected last', which -although not very specific > - might confirm that it remains high until a stop condition is detected. > > Joep > > Op zo 24 jan. 2021 om 06:59 schreef Neil <[hidden email]>: > >> Hi all, >> >> I'm using I2C in slave mode on a PIC18F24Q10. The incoming packets are >> like this... >> http://orlandorobotbuilders.com/stuff/WD-I2C-hold-packet-01.gif >> >> The PIC18F24Q10 datasheet is here... >> >> https://ww1.microchip.com/downloads/en/DeviceDoc/PIC18F24-25-Q10-Data-Sheet-40001945D.pdf >> >> The MSSP has a flag and interrupt for Start and Stop condition (S & P >> bits in SSPxSTAT) and I tried this code in the ISR to detect these... >> >> if (SSP1STATbits.S == 1) >> { >> TX1REG = 'S'; >> SSP1STATbits.S = 0; >> } >> >> if (SSP1STATbits.P == 1) >> { >> TX1REG = 'P'; >> SSP1STATbits.P = 0; >> } >> >> (I'm using EUSART1 for debugging to a serial terminal). >> >> But I'm getting the 'S' 6 times for each message, and It's repeating the >> 'P' several times, even after the message is over. (The package is >> being sent once only). Am I missing something obvious here? >> BTW, I've worked around this already, but just want to know now. >> >> Cheers, >> -Neil. >> >> >> >> -- >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: [PIC] PIC18F I2C Start/Stop condition detection
|
|
All this is why I really like SPI more than I2C. I have never gotten I2C
to work without putting a logic analyzer on the bus to figure out what's going on. It saves a wire per device compared to SPI, but what a pain! And, SPI can be a lot faster! We did a project where there were a LOT of SPI devices and an FPGA. There we had a single SPI port and chip select going to the FPGA. The first byte after chip select went low was the address of the device we wanted to talk to. After that, the FPGA drove the chip select for that device low until the FPGA chip select input went high. We also repeated the clock and data lines out to each device so there was a separate bus to each chip. These were source series terminated. No reflections! Good luck with the I2C! Harold -- FCC Rules Updated Daily at http://www.hallikainen.com Not sent from an iPhone. -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
I've always preferred I2C specifically due to the minimal wiring, but
I've only ever done master mode before. So this is a first for me. I do now see a benefit of SPI over I2C as the ISR gets called for every byte on the I2C bus, and there's a lot going on on this bus (touch screen, I/O expander, etc). But in this case at least, the PIC is doing very little... it's mostly just a secondary watchdog which can warn the primary processor of any issues, and even reboot it. Customer had issues (with noticeable consequences) with a previous version of this product (developed by someone else), so this backup watchdog gives him a lot of peace of mind for <$1. On this project though, we had to use I2C as the primary processor is an ESP32 as chosen by the guy developing that code, and he already had 8-bit MCU drivers for an LCD display, so we had very few pins remaining. And worse, ESP32 GPIOs are very often ust GPIs or GPOs. :( Cheers -Neil On 1/24/2021 2:26 PM, Harold Hallikainen wrote: > All this is why I really like SPI more than I2C. I have never gotten I2C > to work without putting a logic analyzer on the bus to figure out what's > going on. It saves a wire per device compared to SPI, but what a pain! > And, SPI can be a lot faster! We did a project where there were a LOT of > SPI devices and an FPGA. There we had a single SPI port and chip select > going to the FPGA. The first byte after chip select went low was the > address of the device we wanted to talk to. After that, the FPGA drove the > chip select for that device low until the FPGA chip select input went > high. We also repeated the clock and data lines out to each device so > there was a separate bus to each chip. These were source series > terminated. No reflections! > > Good luck with the I2C! > > Harold > > > -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
PLEASE REMOVE MY EMAIL FROM YOUR CONTACT LIST. ------ Original Message ------ On Sunday, 24 Jan, 21 At 21:47, Neil<[hidden email]> wrote: I've always preferred I2C specifically due to the minimal wiring, but I've only ever done master mode before. So this is a first for me. I do now see a benefit of SPI over I2C as the ISR gets called for every byte on the I2C bus, and there's a lot going on on this bus (touch screen, I/O expander, etc). But in this case at least, the PIC is doing very little... it's mostly just a secondary watchdog which can warn the primary processor of any issues, and even reboot it. Customer had issues (with noticeable consequences) with a previous version of this product (developed by someone else), so this backup watchdog gives him a lot of peace of mind for <$1. On this project though, we had to use I2C as the primary processor is an ESP32 as chosen by the guy developing that code, and he already had 8-bit MCU drivers for an LCD display, so we had very few pins remaining. And worse, ESP32 GPIOs are very often ust GPIs or GPOs. :( Cheers -Neil On 1/24/2021 2:26 PM, Harold Hallikainen wrote: > > All this is why I really like SPI more than I2C. I have never gotten I2C > > to work without putting a logic analyzer on the bus to figure out what's > > going on. It saves a wire per device compared to SPI, but what a pain! > > And, SPI can be a lot faster! We did a project where there were a LOT of > > SPI devices and an FPGA. There we had a single SPI port and chip select > going to the FPGA. The first byte after chip select went low was the > > address of the device we wanted to talk to. After that, the FPGA drove the > chip select for that device low until the FPGA chip select input went > high. We also repeated the clock and data lines out to each device so > there was a separate bus to each chip. These were source series > terminated. No reflections! > > Good luck with the I2C! > > Harold > > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
On 2021-01-24 22:02, [hidden email] [hidden email] wrote:
> PLEASE REMOVE MY EMAIL FROM YOUR CONTACT LIST. Remove yourself? - there's a link at the bottom of every email. Steve -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
Re: [PIC] PIC18F I2C Start/Stop condition detection
|
|
In reply to this post by Neil
I've actually hung I2C off of the last SPI device, the timing just has to be compatible. This was bit-banged on an S-100 buss parallel port(long after S-100 was obsoleted, but it was the computer I had). It worked great. It saved wiring which was important in this application (an array of sensors/signal generators That would be outdoors). I did this because some of the devices I wanted to use were I2C and some were SPI.
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, January 24, 2021 2:47 PM, Neil <[hidden email]> wrote: > I've always preferred I2C specifically due to the minimal wiring, but > I've only ever done master mode before. So this is a first for me. > I do now see a benefit of SPI over I2C as the ISR gets called for every > byte on the I2C bus, and there's a lot going on on this bus (touch > screen, I/O expander, etc). But in this case at least, the PIC is doing > very little... it's mostly just a secondary watchdog which can warn the > primary processor of any issues, and even reboot it. Customer had > issues (with noticeable consequences) with a previous version of this > product (developed by someone else), so this backup watchdog gives him a > lot of peace of mind for <$1. > > On this project though, we had to use I2C as the primary processor is an > ESP32 as chosen by the guy developing that code, and he already had > 8-bit MCU drivers for an LCD display, so we had very few pins > remaining. And worse, ESP32 GPIOs are very often ust GPIs or GPOs. :( > > Cheers > -Neil > > On 1/24/2021 2:26 PM, Harold Hallikainen wrote: > > > All this is why I really like SPI more than I2C. I have never gotten I2C > > to work without putting a logic analyzer on the bus to figure out what's > > going on. It saves a wire per device compared to SPI, but what a pain! > > And, SPI can be a lot faster! We did a project where there were a LOT of > > SPI devices and an FPGA. There we had a single SPI port and chip select > > going to the FPGA. The first byte after chip select went low was the > > address of the device we wanted to talk to. After that, the FPGA drove the > > chip select for that device low until the FPGA chip select input went > > high. We also repeated the clock and data lines out to each device so > > there was a separate bus to each chip. These were source series > > terminated. No reflections! > > Good luck with the I2C! > > Harold > > -- > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
In reply to this post by vela1
There are many ways to accomplish this automatically, including the "unsubscribble" command, but since you said "PLEASE", I have fulfilled your request.
Bob ________________________________________ From: [hidden email] <[hidden email]> on behalf of [hidden email] [hidden email] <[hidden email]> Sent: Sunday, January 24, 2021 2:02 PM To: Microcontroller discussion list - Public. Subject: Unwanted email PLEASE REMOVE MY EMAIL FROM YOUR CONTACT LIST. -- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
WUT!?! THAT'S ALL IT TAKES????
Kidding!!! -- James On Sun, Jan 24, 2021, 6:01 PM Bob Blick <[hidden email]> wrote: > There are many ways to accomplish this automatically, including the > "unsubscribble" command, but since you said "PLEASE", I have fulfilled your > request. > Bob > > ________________________________________ > From: [hidden email] <[hidden email]> on behalf of > [hidden email] [hidden email] <[hidden email]> > Sent: Sunday, January 24, 2021 2:02 PM > To: Microcontroller discussion list - Public. > Subject: Unwanted email > > > PLEASE REMOVE MY EMAIL FROM YOUR CONTACT LIST. > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
«
Return to MicroControllers - PIC
|
1 view|%1 views
| Free forum by Nabble | Edit this page |