• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 33 subscribers
  • Views 1320 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C using gpio to simulate i2c function need 3 pins?

Leo Liao20
Prodigy 150 points


For some reason, I need to implement i2c fucntion by gpio simulation(not use TM4C embedded i2c function),

currently, I used 3 gpios to implement i2c function,

1 for SDA in(config as input)

1 for SDA out(config as output OD)

1 for SCL (config as output)

I think it should have better solution to implement i2c function by 2 gpio.

anybody can give me some advice?


Thanks
Leo Liao

  • 0
    Guru 47900 points

    Leo Liao20 said:
    For some reason, I need to implement i2c fucntion by gpio simulation

    That "reason" (demand more likely) is the most interesting part of your post - and hidden.

    Perhaps a (misguided) school assignment.

    You've properly identified the 3 signal points - your reduction to 2 GPIO hinges upon your recognition of, "When to switch SDA from Output to Input" - does it not?   In addition - that switch-over may yield a simplification, too.   (you are not "burdened" by a read during your I2C-like "writes.")

    Is not your normal mode of operation "write" - and switch-over to "read" occurs during Slave's "ACK/NAK" and when the I2C Slave is returning (other) data?

    Your use of a small, simple I2C memory would best serve your test efforts.   (using a more complex IC adds difficulty - violates KISS)

  • 0 in reply to cb1
    Guru 11940 points

    That "reason" (demand more likely) is the most interesting part of your post - and hidden.

    Perhaps a (misguided) school assignment.

    You take the words right out of my mouth ...

    I believe there is (or was) a library from TI, containing "soft" versions (a.k.a. bit-banging) of serial interfaces like I2c, SPI and UART, including a documentation of the performance penalty vs. the bitrates. Regular StellarisWare/TiveWare user might know more about it.

    However, when hard-pressed, I would sacrifice a third GPIO to make the I2C lines switchable between busses, rather than bit-banging. I know this works - had done this 15 years ago, realized with discrete components (BJT, resistors, diodes) for a PC interface.

  • 0 in reply to f. m.
    Guru 27665 points

    f. m. said:
    However, when hard-pressed, I would sacrifice a third GPIO to make the I2C lines switchable between busses, rather than bit-banging. I know this works - had done this 15 years ago, realized with discrete components (BJT, resistors, diodes) for a PC interface.

    Aren't there IIC based IIC bus switches/multiplexers?  ISTR reading of such (one use of which was to avoid addressing conflicts).

    Robert

  • 0 in reply to f. m.
    Guru 47900 points

    f. m. said:
    I believe there is (or was) a library from TI, containing "soft" versions (a.k.a. bit-banging)

    And - after "taking the words from your mouth" - may I (now) present the "soft I2C" version you so note?

    "soft_i2c_atmel.c" is JUST the short program you identified - and resides w/in StellarisWare 9453.   (and likely other versions - as well.)

    Still though - rejecting the tried/true/tested API makes little (likely NO sense) and small tech firms such as mine NEVER would allow any new hire to "reinvent the wheel!"    Why (some) schools "delight" in such inefficient, error-laden approaches proves a constant thorn in the side of small tech biz while reducing the hiring of recent graduates - who are the real VICTIMS of such misguidance!

  • 0 in reply to cb1
    Guru 11940 points

    Just to state my personal opinion - I would avoid I2C if possible.

    More complex, "stateful" I2C slaves are a mess to handle properly. What happens if, for certain reasons, the master aborts the transfer after the "repeated start", and "forgets" about the current state? You can read it up in almost all popular MCU fora: "I2C bus suddenly stops after some time...". And since this chips use to have no reset input, usually only power cycling helps.

    And how many silicons are really prepared to handle clock stretching correctly ?

  • 0 in reply to f. m.
    Guru 117855 points
    Indeed my friend - while the "appeal" of a 2-wire bus is high - many traps/pitfalls lurk. Should such system operate in a "noisy" environment - user frustration is sure to peak. Passive pull-ups (especially when located sub-optimally) are not known for great signal robustness...
  • 0 in reply to f. m.
    Guru 27665 points

    f. m. said:
    Just to state my personal opinion - I would avoid I2C if possible.

    Agreed, I've not yet needed to use IIC. There are some functions only available on IIC but I've managed to avoid them.

    Almost everything that is available on IIC is also available on an SPI or SPI-like interface. Using SPI, they are almost invariably simpler, more robust simply for avoiding IIC complexities, often faster and it's not unusual for them to be cheaper as well.

    I/O expansion, NV memory, switch inputs, A/D, D/A all easily available. TV tuners on the other hand.

    Robert

  • 0 in reply to Robert Adsett
    Guru 11940 points
    Totally agree with you.
    I'm having some IMU sensor boards, and prefer SPI there as well.

    I2C was manageable "decades ago" when Philips specified it (according to their requirements in entertainment electronics). We used the PCF85xx chips extensively at that time.
    But then came "stateful" designs with repeated start conditions, and messed everything up ...
  • 0 in reply to f. m.
    Guru 117855 points

    We tech "mortals" are advised to, "listen up" when posters f.m. & Robert  present.   If these two seek to "avoid" - the attempts of  we (lesser) others present very high risk...   (and very little reward - especially so when an SPI solution proves an option)