...
Topic | Notes |
---|---|
Communication Interface (CAN, Ethernet, other options) | |
Narrow down requirements Backplane Architecture Requirements |
Stock considerations are not relevant because the bottleneck is the microcontroller in either (Ethernet/CAN) case.
Metric | Ethernet better | CAN better | Impact and why |
---|---|---|---|
Cost | X | Low - Difference is that of Ethernet chips, switches, and supporting passives | |
Software complexity | X | High - less software bandwidth; more experience with Ethernet implementation | |
Hardware complexity | X | Medium - More careful routing required, more traces in general, but that is concentrated to the backplane and we have hardware engineering bandwidth | |
Data Bandwidth | X | Medium - CAN precludes video over the bus | |
Physical size | X | Low - Not that much worse | |
Module testing | X | High - Individual modules easier and there are many of them | |
Backplane testing | X | Medium - Fewer points of failure to troubleshoot but is very important | |
MCU compatibility | X | Low - Lots for either | |
Power | X | Medium - Ethernet very slightly violates modularity philosophy due to having ICs on the backplane + Ethernet switches require more current |
Summary:
Priority | Ethernet | CAN |
---|---|---|
High | 2 | 0 |
Medium | 1 | 3 |
Low | 1 | 2 |
Additional notes:
- Ethernet violates modularity because there are ICs on the backplane that need to be tested, requiring the power board, which isn't the case for CAN because the CAN bus doesn't have ICs
- Wiznet chips (130 mA active, 13 inactive) and switches draw a significant amount of current, but power considerations can be mitigated by better design or operations planning
- Power might push us in favor of a more expensive 8-port switcher
- Can also limit the number of modules
- Stock considerations are not relevant because the bottleneck is the microcontroller in either case.
Decision: Ethernet, due to high impact tradeoffs.
...