CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

I2C best practices? Example template?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
allenhuffman



Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

I2C best practices? Example template?
PostPosted: Fri Oct 25, 2019 7:53 am     Reply with quote

After looking through dozens and dozens of topics on I2C, I see so many different examples of how to use it, that I wanted to ask if there were any sanctioned "best practices" examples showing Slave, Master, and HW versus Software I2C usage.

My day job has been fighting various I2C issues for the past month or so -- some appear to be hardware quirks in certain PIC chips, some were bugs in the FTDI library (PC-side) -- and I'm now wanting to implement some very simple I2C sniffer code for testing.

Any white papers I should be looking at?
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Ttelmah



Joined: 11 Mar 2010
Posts: 19539

View user's profile Send private message

PostPosted: Fri Oct 25, 2019 8:22 am     Reply with quote

Look at PCM_programmers sniffer in the code library.

On the master there is little variation, except for people making mistakes.
On the slave, there is one 'hiccup', with some chips not correctly releasing
the clock hold, when changing from a read to a write, which requires a
tiny software bodge.
allenhuffman



Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Fri Oct 25, 2019 8:41 am     Reply with quote

Ttelmah wrote:
Look at PCM_programmers sniffer in the code library


I actually started with that, mostly to have some outside code to verify things are on the line. Now I'm wanting independent code to show what Master requests some in to a Slave. Master requests could be coming from a PIC (on a separate sub-net), or from a PC via FTDI interface (main I2C net). I'm going to code up a device to move on each net and use for testing.

Ttelmah wrote:
On the master there is little variation, except for people making mistakes.
On the slave, there is one 'hiccup', with some chips not correctly releasing
the clock hold, when changing from a read to a write, which requires a
tiny software bodge.


Interesting. We have seen numerous hangs and even some odd bit spacing between I2C pulses, with certain PIC chips we use.

Where is an example of what folks have done for the issue you have seen?
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Ttelmah



Joined: 11 Mar 2010
Posts: 19539

View user's profile Send private message

PostPosted: Fri Oct 25, 2019 10:28 am     Reply with quote

Bit spacing doesn't matter at all. I2C is a clocked bus.

The patch for the clock release is shown here:

<http://www.ccsinfo.com/forum/viewtopic.php?t=58095&highlight=i2c+ckp>

The only other difference, is that most I2C, follows the device address
write with the register address. This then is used for either read or write,
and this needs to be handled if required.
allenhuffman



Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Fri Oct 25, 2019 12:41 pm     Reply with quote

Ttelmah wrote:
Bit spacing doesn't matter at all. I2C is a clocked bus.


Except ours is always followed by a bus lockup (or rather, when we have the lockup, we see the odd bit spacing before it happens).

Thanks for the link.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

Re: I2C best practices? Example template?
PostPosted: Fri Oct 25, 2019 12:43 pm     Reply with quote

allenhuffman wrote:
I'm now wanting to implement some very simple I2C sniffer code for testing.

In the Code Library, PrinceNai has posted a simple i2c sniffer:
http://www.ccsinfo.com/forum/viewtopic.php?t=57855

If you want to use hardware:
Here is a usb logic analyzer for $389 USD. The screen shot on the
following page shows it does i2c interpretation. It shows a Start, a
Write of 0x50, and an Ack. http://www.pctestinstruments.com/index.htm
I have one.
allenhuffman



Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

Re: I2C best practices? Example template?
PostPosted: Fri Oct 25, 2019 1:41 pm     Reply with quote

PCM programmer wrote:
allenhuffman wrote:
I'm now wanting to implement some very simple I2C sniffer code for testing.

In the Code Library, PrinceNai has posted a simple i2c sniffer:
http://www.ccsinfo.com/forum/viewtopic.php?t=57855

If you want to use hardware:
Here is a usb logic analyzer for $389 USD. The screen shot on the
following page shows it does i2c interpretation. It shows a Start, a
Write of 0x50, and an Ack. http://www.pctestinstruments.com/index.htm
I have one.


We use various smart scopes and USB devices like Salaea (https://www.saleae.com/).

In my instance, we have certain PICs that can cause the line to lock up just by having the PIC with I2C initialized on the bus (no active code running). Don't init, bus is fine. Init, problems. We have been tracking this down for awhile now, and I'm just building some smarter tools to drop on the line to see what's going on.

I'm mostly familiar with I2C on Arduinos. I'm trying to figure out how to replicate their concept of available(). They can do a read of X bytes, then if the Master just writes 3, it returns with just the 3. It allows very flexible arbitrary sized messages. Our work project has fixed size messages, so we don't deal with it. I'm seeing if I can do something similar to my Arduino code using the CCS API.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Ttelmah



Joined: 11 Mar 2010
Posts: 19539

View user's profile Send private message

PostPosted: Fri Oct 25, 2019 1:55 pm     Reply with quote

When you have the PIC on the bus, is it initialised as a master or a slave?.
Matters a lot. A slave will respond to a general broadcast on the bus.
If there is no handler code in the PIC, this can then leave the bus hung.
allenhuffman



Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Fri Oct 25, 2019 2:00 pm     Reply with quote

Ttelmah wrote:
When you have the PIC on the bus, is it initialised as a master or a slave?.
Matters a lot. A slave will respond to a general broadcast on the bus.
If there is no handler code in the PIC, this can then leave the bus hung.


Slaves, with a PC as the Master.

We did a board rev where we swapped out the PIC for a different model and the problem went away. It appears to be a quirk with one of the PIC24 series we use. I'm now writing code to validate the alternative PIC model we will likely be using. I have a note in with Microchip to see if they can figure it out.

We've learned quite a bit about I2C and the PICs these past few months Smile
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
allenhuffman



Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Mon Oct 28, 2019 9:26 am     Reply with quote

Is there a way, from the PIC Slave, to detect that the master has sent a Stop, to know there is no more data? On Arduino, the Master will do things like

Code:

start()
write()
write()
write()
stop()

...and the slave will be doing things like...
Code:

while available()
   read()


If the slave wants to read 128 bytes, and the master writes 4, it will exit with four bytes in the read routine.

The examples I have been seeing assume hard-coded message sizes (write 4, read 4).
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
Ttelmah



Joined: 11 Mar 2010
Posts: 19539

View user's profile Send private message

PostPosted: Mon Oct 28, 2019 12:58 pm     Reply with quote

You can do this by setting bit 4 of the SSPCON1 register. This then makes
the I2C interrupt trigger on start and stop bits as well as normal transactions.
Your IRQ handler then has to test the S & P bits to know that the interrupt
is not a normal call:
Code:

#bit SSPM3=getenv("BIT:SSPM3")
#bit P=getenv("BIT:P")
#bit S=getenv("BIT:S")

//This then controls the feature
SSPM3=TRUE; //enable interrupts on start/stop
SSPM3=FALSE; //or to disable these

//Then at the start of the interrupt handler
if (S==TRUE)
    //code here for start

if (P==TRUE)
   //code here for stop

//obviously these must exit and not call the normal I2C code
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Oct 28, 2019 1:03 pm     Reply with quote

Ttelmah, I wrote this while you were writing. My answer assumes
he's using 24F.

allenhuffman wrote:

Is there a way, from the PIC Slave, to detect that the master
has sent a Stop, to know there is no more data?


From the PIC33/PIC24 i2c reference manual:
Quote:
7.2 Detecting Start and Stop Conditions
The slave detects the Start and the Stop conditions on the bus
and indicates that status on the S status bit (I2CxSTAT<3>) and
P status bit (I2CxSTAT<4>). The Start (S) and Stop (P) status bits
are cleared when a Reset occurs or when the module is disabled.

After detection of a Start or Repeated Start event, the S status bit
is set and the P status bit is cleared. After detection of a Stop event,
the P status bit is set
and the S status bit is cleared.

7.2.1 INTERRUPT ON START/REPEATED START AND STOP CONDITIONS
(SLAVE MODE)

The user software is notified through a slave interrupt if the SCIE
bit (I2CxCONH<5>) is set for a Start/Repeated Start condition or if
the PCIE bit (I2CxCONH<6>) is set for a Stop condition.

Note: The PCIE and the SCIE bits are not available on all devices.
Refer to the specific device data sheet for availability.

If you are still using the 24FJ256GB406, it does have the PCIE bit.
From the data sheet:
Quote:

I2CxCONH: I2Cx CONTROL REGISTER HIGH

bit 6 PCIE: Stop Condition Interrupt Enable bit (I2C Slave mode only).
1 = Enables interrupt on detection of Stop condition
0 = Stop detection interrupts are disabled

So you could enable interrupts for Stop conditions and check the bit
inside the Slave Events isr, to see if the interrupt was caused by a Stop bit.
allenhuffman



Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Mon Oct 28, 2019 1:14 pm     Reply with quote

PCM programmer wrote:

If you are still using the 24FJ256GB406, it does have the PCIE bit.
From the data sheet:
Quote:

I2CxCONH: I2Cx CONTROL REGISTER HIGH

bit 6 PCIE: Stop Condition Interrupt Enable bit (I2C Slave mode only).
1 = Enables interrupt on detection of Stop condition
0 = Stop detection interrupts are disabled

So you could enable interrupts for Stop conditions and check the bit
inside the Slave Events isr, to see if the interrupt was caused by a Stop bit.


I must be on the right track. I was just looking at that in the datasheet. I had hoped it was something covered by a CCS API.

I am off to read up on the compiler to learn more about #bit and such.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
allenhuffman



Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

PostPosted: Mon Oct 28, 2019 1:49 pm     Reply with quote

I'm still not quite getting there. I have this, to match my processor:
Code:

// I2C2CONH - PCIE enable/disable bit, then P and S bits for status.
#bit PCIE=getenv("BIT:PCIE")    // bit 6 - enable/disable
// I2C2STAT
#bit P=getenv("BIT:P")          // bit 4 - stop
#bit S=getenv("BIT:S")          // bit 3 - start

In the code, I enable using:
Code:

PCIE = 1;       // enable interrupts on stop


As I step through the debugger, I am not seeing that change any bits in the I2C2CONH SFR register. Should I see it reflect that change when I enable?
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
gaugeguy



Joined: 05 Apr 2011
Posts: 303

View user's profile Send private message

PostPosted: Mon Oct 28, 2019 2:08 pm     Reply with quote

Check the assembly code. If the bit in CCS is labeled PCIE for both I2C1CON and I2C2CON then your code is probably setting the bit in the wrong register.
You may need to use getenv to get the address for I2C2CONH and then do a #bit for the PCIE in that register manually.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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