Espruino JavaScript
Puck.js v2.1: Why don't Accel/Mag sensors share common I2C bus? #7779
-
|
Hi there, I am working on a project that involves laying out a custom PCB with an NRF52832 which will run Espruino. I've been referencing the schematic for Puck.js v2.1, and I noticed that the LSM6DS3TR-C (Accel/Gyro) and MMC5603NJ (Mag) connect to the NRF chip, but they don't share traces. As per the schematic: They do not share the same bus for SCL/SDA. Is there a reason for this? I don't know too much about I2C, but I thought the only reasons you would avoid sharing a bus are conflicting addresses, or if you're nearing the crazy high limit for number of devices on a shared bus. I plan to have one SPI device (a display connected to separate pins) and around four I2C devices (connected to the same two pins). So far, I have hooked up two of these I2C devices on a breadboard, and they seem to work perfectly fine sharing the same wires. One of the four I2C devices I want to use is the same accelerometer the Puck.js uses, the LSM6DS3TR-C, but I haven't tested it with the other I2C devices yet (I still need to break it out, I only have the bare chips). Any insight is appreciated. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
There's no particular reason other than that it makes layout easier, and it meant that if we ended up communicating with one device from an interrupt and the other outside, we don't have to worry about 'sharing' the bus. In a way we had the pins available, so there was really no reason not to have each device with its own I2C bus. On the Puck.js v1 we also switched power to the magnetometer (https://github.com/espruino/EspruinoBoard/blob/master/Puck.js/pdf/puckjs_sch.pdf) and in that case you can't just power off a device on the I2C bus because it'll drag the I2C lines low - but we're able to just leave everything powered on newer Puck.js |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense. Thanks Gordon! One of the I2C devices I will be using is the FS3000-1015 air velocity sensor, which I don't believe has any sort of sleep mode and the datasheet says it draws 10mA. I am planning on switching this off when not in use, so I guess I'll have to give this sensor it's own dedicated lines. I wasn't aware an "off" device could drag lines low! That would have probably led to hours of confusion later on if the other devices started having communication issues after switching off the FS3000. I assume I should not power the FS3000 via GPIO alone, like you did with the mag on the v1, since the current is pretty high (seems to near the max (~15mA?) for the NRF52832 GPIO current limit) so I'll look into a transistor/FET switching circuit. I'm looking forward to sharing more about the project as I progress further over on the "projects" discussion category! |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that sounds good - if the sensor can't sleep then I'd definitely turn it off with a FET. I'm interested to see what it all turns out like! |
Beta Was this translation helpful? Give feedback.
There's no particular reason other than that it makes layout easier, and it meant that if we ended up communicating with one device from an interrupt and the other outside, we don't have to worry about 'sharing' the bus.
In a way we had the pins available, so there was really no reason not to have each device with its own I2C bus.
On the Puck.js v1 we also switched power to the magnetometer (https://github.com/espruino/EspruinoBoard/blob/master/Puck.js/pdf/puckjs_sch.pdf) and in that case you can't just power off a device on the I2C bus because it'll drag the I2C lines low - but we're able to just leave everything powered on newer Puck.js