I2C confusion / Computer Science / Forums

Forums

4hv.org :: Forums :: Computer Science

« Previous topic | Next topic »

I2C confusion

Move Thread

LAN_403

...

Thu May 10 2007, 01:17AM

Registered Member #56 Joined: Thu Feb 09 2006, 05:02AM
Location: Southern Califorina, USA
Posts: 2445

Ok, I am working on the rev3 version of my GPS tracker, and this time I have (among countless other goodies) a 24FC512 I2C eeprom wired into a pic18f1220. Yes I do have the pullups (2k) on the data/clock lines. I am using mplab and using the c18 compiler, and am using it soft I2C libs.

So, on an I2C bus, you start out by pulling the SDA line low ('start bit') and then you pull the clock line low, change the data line to high/low (depending on if you are sending a high/low bit) let the clock float back high, change data, etc then you have an ack or a stop depending on what you are doing.

EDIT: Turns out that wasn't the problem

After looking at the write bit function again, there was a ! before SCLK_PIN

The exact code...

if ( !SCLK_PIN )              // test if clock is low
    {                             // if it is then ..
      if ( Clock_test( ) )        // wait on clock for a short time
      {
        return ( -1 );            // return with error condition      
      }
    }

    else

If SCLK_PIN is high, why is this returning a -1? I tried removing that exclamation mark, and I got some beautiful I2C data on the bus

Now normally this wouldn't be too big of a problem, just remove that exclamation mark, BUT this code is literally 'mission critical' so I would rather do this the right way... I also plan to publish it, so I am trying to avoid modifying the libs more than I have to... I can't imagine the headache that someone would have when they were trying to use the code and it it is doing the opposite of what it should...

edit2: the [code] tags don't seem to like this code either...
if ( !SCLK_PIN ) // test if clock is low
{ // if it is then ..
if ( Clock_test( ) ) // wait on clock for a short time
{
return ( -1 ); // return with error condition
}
}

Conundrum

Mon May 14 2007, 04:00PM

Registered Member #96 Joined: Thu Feb 09 2006, 05:37PM
Location: CI, Earth
Posts: 4061

Have you considered that the library might have an errata?
its not unheard of.

-A

...

Mon May 14 2007, 10:31PM

Registered Member #56 Joined: Thu Feb 09 2006, 05:02AM
Location: Southern Califorina, USA
Posts: 2445

turns out it was a mix of both problems with the library (one function and one function only was referencing to file that comes with the compiler while the rest were referencing to the header file that you use to configure the whole mess) and that I had the a/d configured incorrectly so the pin always showed as a 0 when poled

I ran into another problem, that the fastest eeprom I could find on an i2c buss has a write time of about 5ms, which caps write speed to about 200B/s, and I plan to save about a KiB/s. So, I am making a raid array of 8x 512kb chips... I call it the EEPROMRAIDARRAYFH (Electronically Erasable Programmable Read Only Memory Redundant Array of Inexpensive Disks From Hell)

Conundrum

Sun May 20 2007, 11:24PM

Registered Member #96 Joined: Thu Feb 09 2006, 05:37PM
Location: CI, Earth
Posts: 4061

bwahaha :) i was toying with the idea of building a parallel array of 24C256s for this purpose. In my case it was to parallel-store voice samples in realtime with direct D-A conversion.

-A

Beware:- Sellers on Ebay may be scammers in sheep's clothing...

...

Tue Jul 24 2007, 10:34PM

Registered Member #56 Joined: Thu Feb 09 2006, 05:02AM
Location: Southern Califorina, USA
Posts: 2445

Just in case anyone somehow stumbles across this thread when searching for I2C help...
When using the hardware I2C module in a PIC (instead of the software one I was using), you must follow each write/read/etc with a IdleI2C();, or the module will not respond to anything

don't ask...

Carbon_Rod

Thu Jul 26 2007, 10:05PM

Registered Member #65 Joined: Thu Feb 09 2006, 06:43AM
Location:
Posts: 1155

Also note,

1.) Not all i2c chips are internally page mapped the same.

2.) Some can be over clocked to 400kbs (Microchip), to deal with issue 1 page boundaries simply avoid multi-byte block writes and stick to single byte writes.

3.) The exaggerated start/end bit do not have to be a standard period, i2c usually allows the same clock for the staggered signal as long as DATA shift is centered on the CLK period.

4.) Use your own macro defined ports and mask operations, the bit operator macros are often compiler specific inline functions and cause problems.

5.) If you use an IRQ enabled core -- keep in mind the stack may be handled differently on each mcu. Therefore, I often recommend if you are going to bit-bang a signal make sure its the only one on that port (see read-modify-write errata.)

6.) Declare your global constants and port buffer vars in main.c as:
volatile static
(This can help track down ISR problems...)

Cheers,

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob