Connect with us

Searching for I2C literature

Discussion in 'Electronic Design' started by Al, Aug 22, 2006.

Scroll to continue with content
  1. Al

    Al Guest

    I have a project in which I will be transferring data between two PIC
    microcontrollers. It seems to me that the I2C protocol will do the trick
    for me. However, any information I have been able to find so far has
    been sketchy.

    Does anyone have a book or other reference that will give a good
    tutorial on the subject? I have found the manufacturer's literature


  2."THe I2C protocol"

    See also the relevant reference manual (not just the datasheet) for
    the MCU you're using.

    Best regards,
    Spehro Pefhany
  3. Eeyore

    Eeyore Guest

  4. Luhan

    Luhan Guest

    I've seen this question (or one like it before). Choose a PIC with a
    UART. Tie Tx to Rx and vise versa. Much simpler.

  5. Al

    Al Guest

    Ahh, good idea.


  6. Joel Kolstad

    Joel Kolstad Guest

    Return to I2C when you need to hang multiple devices off your bus...
  7. Joerg

    Joerg Guest

    Hello Joel,
    True. However, I have the impression that I2C devices are slowly losing
    ground versus SPI. Even Philips as the originator of that bus doesn't
    have a lot on the buffet these days, at least not for DACs. Just a few
    audio parts AFAICT.
  8. Luhan

    Luhan Guest

    PIC chips only have I2C *slave* hardware, you need to do the *master*
    in software. Also, you can do a rather simple one-line network with
    the USARTs for multiple units.

  9. Joerg

    Joerg Guest

    Hello Luhan,
    That's true for many uCs but considering that you rarely need much speed
    it's not such a big deal. What surprised me was how small the device
    selection is.
  10. Eeyore

    Eeyore Guest

    When will ppl stop using 24C0X EEproms ? I2C has been around for *yonks*.
    Philips originally came up with the idea for their TeeeVeees.

  11. Eeyore

    Eeyore Guest

    Hardly a problem. It's trivial to code I2C protocol. I use my own routines as it
    happens - not library ones.

  12. Eeyore

    Eeyore Guest

    You can make any 2 general purpose port pins into an I2C i/f.

  13. Probably not during our lifetimes.

    Best regards,
    Spehro Pefhany

  14. So, you don't want your computer to know how much RAM is installed?
    You don't want your computer to identify your monitor?

    Service to my country? Been there, Done that, and I've got my DD214 to
    prove it.
    Member of DAV #85.

    Michael A. Terrell
    Central Florida
  15. Eeyore

    Eeyore Guest

    Your ignorance knows no bounds it seems.

  16. Subhead

    Subhead Guest

    I've done the same with a 16F877 & a 16F873 talking to each other just
    using a Tx & Rx connection to the 2 pins on each PIC I defined for that
    purpose. Both PICs are running from the same 20MHz CMOS oscillator and
    they are on the same board, so I don't have any clock sync problems.
    The PIC to PIC data transfers are running at 115K baud. Even though the
    ports I use have built-in weak pull-ups, I tied each line to 5V thru a
    12K resistor just for insurance.

    Using SPI you can go a lot faster than I2C and you don't have to worry
    about the protocol, or Master/Slave issues.

    Hope this helps.

  17. You are the raging Queen of USENET ignorance. Both item mentioned
    use I2C chips to identify themselves to the motherboad, and the OS.

    Service to my country? Been there, Done that, and I've got my DD214 to
    prove it.
    Member of DAV #85.

    Michael A. Terrell
    Central Florida
  18. Eeyore

    Eeyore Guest

    Sure and I'm all for I2C. Can't you read FFS ?

  19. Luhan

    Luhan Guest

    Or serial async, or anything else for that matter. I like some schemes
    that use just one line to network a bunch of micros together.

  20. Joel Kolstad

    Joel Kolstad Guest

    SPI is faster, of course, but it requires 4 lines rather than 2 and it's more
    difficult to have an "open bus" where you can just "drop in" additional
    peipherals (since you need to switch your data in/out lines to each new device
    as it's dropped in).

    RS-232's main advantage seems to be its ubiquity on older PCs. It's not
    particularly fast (i.e. 115kbps typically) and requires either a hardware UART
    or at least "well controlled timing" if you're going to bit-bang it... for
    ultra-low-end microcontrollers (where all you have is something like a timer
    interrupt and 1 MIP) it's often difficult to get much more than 9600bps
    full-duplex working robustly.

    So, in my mind, I2C is actually one notch better than RS-232 (works on the
    lowest of the low microcontrollers, significantly more robust for multiple
    devices, more or less the same throughput), and while it's certainly not as
    "slick" as SPI, it's a decent tradeoff if you don't need SPI's higher data

Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day