> Make sure your drivers can handle NAKs and errors on the line. Make sure you can reset subsystems (probably by power-cycling) completely and your system can keep running. Be ready to deal with stale sensor data or having to do a few retries at times.
By the time you've implemented that, you've negated any advantages of I2C. So, why not go directly to SPI?
Re:Docker containers in space
by patrickyeon on Wednesday October 16, 2019 @08:53PM
(#21277894)
Because a whole bunch of chips you want to use are on I2C. And/or you want to work with a large number of devices, and a chip select per is a lot of GPIO to burn on this. Also you're going to want to handle errors and bad devices on SPI, so it's not like that's new work anyway.
Additionally, sensor data should be oversampled and filtered/fused using a filter that is robust to outliers. This whether coming in over I2C, or not.
Robust systems assume failures will occur and manage them in such a way that they still do their job correctly.
Make sure your drivers can handle NAKs and errors on the line. Make sure you can reset subsystems (probably by power-cycling) completely and your system can keep running. Be ready to deal with stale sensor data or having to do a few retries at times. With these and some good testing you'll be fine with I2C, and really there's immense value in having those attitudes in your system design anyway.
I was a design EE at Planet Labs for 4 years, have sent something like 200 satellites to space, each with literally dozens of I2C devices on them, and supported them in orbit.