[PIC] PIC18F I2C Start/Stop condition detection

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[PIC] PIC18F I2C Start/Stop condition detection

Neil
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
Reply | Threaded
Open this post in threaded view
|

Re: [PIC] PIC18F I2C Start/Stop condition detection

Joep Suijs-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [PIC] PIC18F I2C Start/Stop condition detection

Neil
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
Reply | Threaded
Open this post in threaded view
|

Re: [PIC] PIC18F I2C Start/Stop condition detection

Harold Hallikainen-3
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
Reply | Threaded
Open this post in threaded view
|

Re: [PIC] PIC18F I2C Start/Stop condition detection

Neil
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
Reply | Threaded
Open this post in threaded view
|

Unwanted email

vela1

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
Reply | Threaded
Open this post in threaded view
|

Re: Unwanted email

Steven Howes-4
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
Reply | Threaded
Open this post in threaded view
|

Re: [PIC] PIC18F I2C Start/Stop condition detection

madscientistatlarge
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
Reply | Threaded
Open this post in threaded view
|

Re: Unwanted email

Bob Blick-5
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
Reply | Threaded
Open this post in threaded view
|

Re: Unwanted email

James Burkart-2
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