-
However, I'm not initializing the accelerometer at all, so I'm hoping it's not doing anything
So most probably it sits on i2c bus trying to read i2c traffic when clock is pulsed and in very unlikely case may respond. For I2c the SDA pin is open drain with pull up, so only when it decides to send zero bits it will pull the shared data pin low and possibly mess up SPI communication randomly. However it is very very unlikely as the traffic would need to be valid i2c with matching address otherwise it should not do anything(?). In theory the safest would be to put it to deep sleep like the P8 touchscreen chip which must be then woken by interrupt pin to listen on i2c.
What is more likely is the power drain if the last SPI bit is low = data pin driven is low with the i2c SDA pin having a pull up. This can be fixed by setting MOSI high or floating (=reconfigure as input) after spi transfer ends
Same issue could be with SPI clock polarity if the clock is idle low as i2c clock is also open drain with pull up.
see e.g. https://learn.sparkfun.com/tutorials/i2c/i2c-at-the-hardware-level
You are reading a single comment by @fanoush and its replies.
Click here to read the full conversation.
fanoush
totally agree I don't know why they share those lines.. and this one actually shares data and clock with display, SPI flash AND accelerometer! However, as I've removed the display and the touchscreen, I've grabbed the touchscreen SDA/SCL for my e-ink display, so that's not shared.
However, I'm not initializing the accelerometer at all, so I'm hoping it's not doing anything (yet). My intention was to use a very basic JS driver and simply ignore any requests if the SPI flash is low. Klunky, but it should do for now.
Right now the watch has been running off charger for 19hours, but NRF.getBattery() is reporting 3.02 so not expecting it to last the night... this is with manually setting the SPI flash to sleep (current firmware isn't using it for Storage, but it is compiled in so I can get it via require("Flash"))