1

Does anyone know if it's possible to use the built-in pull-ups for TWI on the at32uc3b chips? I've been adding external pull-ups to my TWI circuits in the past because I couldn't find any concrete info about this. But if it's possible to just use the internal pull-ups, I'd much rather do that.

Thanks!

Jeremiah Lusby
  • 11
  • 1
  • 2
    Don't rely on internal pull-ups for I2C. Here's an thorough [discussion on internal pull-ups for I2C](http://electronics.stackexchange.com/q/102611/7036). There are oscilloscope screenshots in that thread which show the difference between internal pull-ups and proper external pull-ups. – Nick Alexeev Mar 16 '15 at 18:21

2 Answers2

2

The question is not "can" you use them, but "should" you use them. If it does happen to be the case that you can use them, should you actually use them?

Given that the internal pullup resistors are typically 10-50x larger than the values you should use on an I2C bus, the answer is a resounding "NO!", and Arduino are criminally insane for suggesting that you do (and indeed enabling them by default).

Majenko
  • 55,955
  • 9
  • 105
  • 187
-1

the internal pull-ups is weak (about 100k). you can use them but the guaranteed speed will very slow (about 25 bit/s or less). with external 2k..4k pull-ups the speed is limited to 400 kbit/s.

also, remember that you need an external pull-up only at the data line in single-master topology keeping the clock line as push-pull at the master.

EDIT

maybe matt and nick are both right about the clock-stretching feature but it is useful only in theory. i2c was designed so universal (again in theory) but in practice its behavior by design (without additional constraints) leads to the following failures:

driver level deadlock: as a result of a failure on the host, the device's state machine could "freeze" in a non-acknowledged state forever, and if you cannot "re-clock" the device the system fails in this service. this deadlock is manageable in either case you use open-drain or push-pull clock. linux i2c drivers typically manages that scenarios.

device level deadlock: as a result of a failure on the device, its state machine could "freeze" in the clock shrinkage phase, and if you cannot "re-drive" that the overall system fails. this deadlock is manageable only if you use (strong) push-pull clock or your i2c unit support a timeout mechanism with sensing of the clock. hardware support is always necessary to manage that scenarios.

also, the topic starter mentioned the concrete chip --- at32uc3b, which TWI unit does not support a timeout on clock shrinkage.

may be it seems like a hack but it is useful (the only simple?) hack if you design a real system which must be reliable and dependable instead of a toy class/home work which is not intended to work for long and good.

therefore my advice to jeremiah is:

1) use a pull-up at the data line, as strong as your master/slaves can drive;

2) use a push-pull at the clock line if your slaves can work on the target bus frequency;

3) use a clock frequency of the bus as the slowest slave support without the shrinkage;

and also as recommended:

4) use i2c only if another-interfaced devices do not exist, e.g. use spi instead of i2c;

5) always think in terms of reliability and dependability while you design electronics, especially, software-driven electronics.

good luck.

Dave Tweed
  • 168,369
  • 17
  • 228
  • 393
alex
  • 11
  • 1
  • Both lines are open drain and need to be pulled up. A push-pull master trying to drive the clock high while a slave is stretching it would result in output contention. – Matt Young Mar 16 '15 at 18:35
  • @alex Frequently overlooked fact: SCL is bidirectional too because of the clock-stretching feature. – Nick Alexeev Mar 16 '15 at 18:40