Serial protocol and connector choice for tethered firmware distribution project

Question

I am designing a system in which a central host controller that has a cellular internet connection is going to be used to query/control/flash intermittently tethered (wired) nodes.

The central host controller is a Particle Electron and that is set in stone (already have dozens of units deployed and working well for 1+ years).

The intermittently connected nodes are smart batteries that will be connected to the host control/charging interface.

The smart batteries will have an ATtiny MCU (flexible on choice of specific MCU) in them that logs charging data, queries a UUID chip and communicates historical data saved in EEPROM to the host controller.

Part of the design goal is to be able to update firmware on the ATtiny seamlessly after connecting it to the charging harness. This implies that the charging harness will need to be able to carry 4 additional wires on top of the 2 charging wires to facilitate programming of the MCU via its SPI interface: (SCK, MISO, MOSI) plus a reset wire.

This poses a challenge because if I have 12 smart batteries all connected to the same SPI bus, I will likely have a crappy SPI bus that probably will have a lot of capacitance/slew/noise issues, especially considering that the cable run from host controller to each smart battery will be up to 2 m. That quickly adds up to 24 m of copper at 12 channels.

My idea to counteract this right now is to multiplex each SPI signal to the 12 channels such that the "activated" portion of the SPI bus stays at 2m. This would also take care of "addressing" specific channels/smart batteries, which makes me think that I could probably just tie all the ATtiny slave select pins to ground... (though I know that a high to low transition on SS pin of ATtiny results in resetting of the SPI peripheral... which could be important).

The other part of the calzone is the wiring harness/connector. The charging power wires will be 16 gauge. There will be minimum 4 additional comms wires (assuming I'm married to the firmware update idea), but ideally 5 (to provide for the slave select pins).

A quick search for 6-8 pin connectors reveals that they will likely cost almost as much as an ATtiny, which makes me want to just add a secondary ATtiny as an external programmer and have both ATtiny operate on a two-wire (or 1-wire) searchable/addressable comm protocol. This approach has the downside of increased development work that would likely need to be sourced out to an independent developer.

Smart battery production affected by this decision long-term could be in the millions easily.

So, questions are:

• What seems saner: 6-8 pin connectors/wiring harness (times 12) running on multiplexed SPI peripheral or a farmed-out ATtiny programmer project running on a 1 or 2 wire interface?

• Is multiplexing a 24-foot copper SPI bus down to ("manageable") 2 foot buses doable, advisable, appropriate?

Answer 1

Multiplexing the SPI bus is easily done if you select the correct types of switch parts for this. Do not tie the slave device select pin to GND at the slave. The slave select signal initial transition is the thing that provides the sync for the slave device to know when the boundary of the first byte of a SPI transaction is going to come. If you skip its usage you risk the high possibility that a slave gets out of sync with the master controller.

There are some connectors that are inexpensive, robust enough for this application and manufactured in huge volumes. One type that comes to my mind to suggest to you is the ubiquitous DSub-9 connector. It seems like it would be perfect for this application. Use 2 pins for the charging wire, 2 pins for the charging GND leaving 5 pins for your SPI interface. Instead of using a pair of 16AWG wires for the charging and GND you could go to a smaller gauge (18AWG?) and double to two pairs. This would map to the connector pinning better and lead to a more flexible cable.