PIC Microcontoller Input / Output Methods

for I²C

NEW! RS-232 / I²C-Adapter & Parallel I/O Module

IIC can be implimented by onboard hardware (in the PIC's which contain such) or by "bit banging" or simulating in software the functions of the interface hardware.

Software methods are somewhat generic and can be ported from one system to another with minor adjustments. Unfortunatly, they do require that the controller process instructions much faster than would be required with a hardware implementation, so they may not be ideal for all applications

• Bit Banged I2C by Drew Vassallo
• Ultra-optimised I2C EEPROM routines by Mike Harrison
• Non PIC specific I2C

Harware solutions are specific to the processor used and seem to have been confusing for many people to use. Luckily, there are some working examples to start from:

• 18F452 I2C test with timing diagram by Jinx
• 16f876 USART, I2C, EERAM read/write, port setup, ISR, and full initialization sample from Tony Kübek of Flintab AB [tony.kubek at flintab.com]
• 16f87x MPLAB macros by John Snd
• 16c77x discussion

See also:

• Bergthaller C Iulian refers to " http://sandiding.tripod.com/seeprom.html I2c routines for 24c64 eeprom" +
• http://www.microchip.com/Download/Appnote/Category/PIC16/00735a.pdf Master mode i2c routines.
• http://www.microchip.com/Download/Appnote/Category/PIC16/00735.zip and the code:
• http://web.hazmat.com/~mjb/projects/walkingrobot/source/master.asm
• http://web.hazmat.com/~mjb/projects/walkingrobot/source/slave.asm

Questions:

• autx790-yahoo-CA asks:

  I'm having trouble getting my I2C code to run consistently. I'm new to this site and haven't quite figured it all out, but I have posted a detailed description of my problem and code here...
  http://forum.microchip.com/tm.aspx?m=277525
  If anyone can help me get this debugged I would be very grateful! If you can help please email me (autx790@yahoo.com).
  Thanks!

  +
• spamferrous2 at -Remove-juno.com asks:

  I'd like to have transmit and receive subroutines for I2C that are not interrupt driven. I'd like to poll for I/O periodically, at less of an interval than a byte takes to come through.

• spamanconor at -Remove-hotmail.com asks: Reading the 16F87XA datasheet I've noticed that in this family there are two new modes for Slave operation. In this two modes you get interrupts after Start and Stop conditions in the bus wich is sweet because you can determine the end of a transmission without relying on the undocumented feature of the R/W bit holding ACK value.
  The problem now is that the S bit is set to 1 during all the transfer and it's not writable, so it can't be used to determine wether the present interrupt is being raised by a Start condition or by any other event. Furthermore, the value stored by the Status bits in an interrupt raised by an Start condition is undocumented, both in AN734 and in the 16F87XA Datasheet.
  Has anyone found a way to work arround this problem?
  Does anybody now if the SSP still locks up using this modes?
  If it does so, can the interrupt raised by the Stop condition be used to reset the logic in some way? +
• spampaulcunningham at -Remove-sprintmail.com asks:

  Ref: Microchip Application note AN554, Software implementation of I2C bus master. "On initialization, these I/O lines are configured as input pins (tri-state) and their respective latchs are loaded with 0's. To emulate the high (passive), these lines are configured as inputs. To emulate the active low state, the pins are configured as outputs"

  Testing 
      bcf STATUS,RP0 
      bcf PORTB,7  ;<- "was" the only place I set B7
      bcf STATUS,RP0
  ActiveLow 
      bsf STATUS,RP0 
      bcf TRISB,7 
      bcf STATUS,RP0 
      bcf PORTB,7 ;<- this line is required, why? 
      goto Done 
  SetPassive 
      bsf STATUS,RP0 
      bsf TRISB,7 
      bcf STATUS,RP0 
      Done 
  

  Why does the Data Latch need to be reset each time?
   

  Philip Arden Quesinberry of Q-Systems Answers:

  Since you're effectively trying to simulate open-collector operation on those pins, it would be assumed that you're using pullup resistors to keep the lines high when configured as inputs. You need to reset the data latch each time since when configured as an input, the pin reads high and that state goes into the PORTB register as a '1'. When you change it to an output, it's still set to a '1' so it just drives the pin high instead of sinking it like you were expecting. It's another one of those Read-Modify-Write gotchas... well, sort of.
  
  - Phil

  +

  .