Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I2C Pullup Resistors #8

Open
JohnHind opened this issue Jun 22, 2014 · 3 comments
Open

I2C Pullup Resistors #8

JohnHind opened this issue Jun 22, 2014 · 3 comments

Comments

@JohnHind
Copy link

One project I want to do with my PYB is to interface with DaisyLink bus boards, which are I2C with some frills. DaisyLink puts the pull-ups on the slave boards (switchable), so the pull-ups already fitted to the PYB are a problem (R8, 9, 11, 12). I cannot find a board layout to identify these to remove them - any chance of publishing a component layout?

In a future release, I think it would be better to omit these components as they may also interfere with other uses of these pins, for example as open drain drivers (or a user may want to drive the I2C at 5v.). Omitting R8 and 9 would be a problem for the MMA7660 which I would also prefer was omitted to free these pins and reduce BOM cost - it could be supplied optionally on a shield board. However, if this part is regarded as essential, at least omit R11 and 12.

Maybe when you go into production, you could offer a version with these five components not fitted?

@chrismas9
Copy link

R11 and R12 are the two resistors close to pins Y9 and Y10 on PYBv1.0. You should be able to see the traces run to them. You can check with a multimeter. PB11 needs a stable level during reset for DFU to work so you should replace R12 with 100k, otherwise you may not be able to reprogram a bare board.

The problem with leaving pullups off the I2C master is that all slaves will need pullups and as you stack more skins the resistance will drop.

An alternative is to use pins Y3 (PB8) and Y4 (PB9) which can have I2C1 mapped to them. You would loose access to the accelerometer, but this just needs a driver change and no board mods.

@JohnHind
Copy link
Author

Thanks Chris, but I think in general design terms there are two likely cases:

  1. One or two I2C skins on the X and Y locations, only one skin per I2C channel. The skin might have several I2C devices on it (for example an IMU with accelerometer, compass and gyro). In this case, the skin can have the pull-ups on it so the pull-ups are automatically present if and only if they are needed. Changing one of the I2C pin assignments would break the symmetry which allows the same skin design to be compatible with either X or Y position.
  2. A skin (or a direct connection to the terminals) presents the master end of some sort of bus cable. In this case you can have a terminator module at the other end with the pull-ups. Or with the DaisyLink system, the slave nodes all have MPU switchable terminators and a protocol ensures that after initialization, only the slave furthest from the master has its pull-ups enabled (the main purpose of this protocol is to provide automatic address assignment).

Remember that I2C is multi-master capable, so you might well want to have several PYBs on the same bus (or you might even want to implement slave nodes using PYBs). Having permanent pull-ups on the PYB cuts off these possibilities in addition to the ones mentioned in my original post.

@chrismas9
Copy link

Hi John, I will discuss pullups with Damien, but leaving them off will break the AMP and LCD skins which both use I2C for volume control and touch controller. Are you developing a DaisyBus skin? If so you could use a TXS0102 buffer / level translator to isolate DaisyBus. I have just realised that X9 and X10 are not 5V tolerant because the accelerometer isn't 5V tolerant. The buffer would isolate the accelerometer from any 5V I2C devices on the bus. Some buffers are designed to drive long higher capacitance busses than the MCU can handle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants