search

UWCubeSat / DubSat1

Main repository for all flight software (including all subsystems, core libraries, and hardware abstraction layers) for the DubSat-1 3U Cubesat.
22 stars 10 forks source link

Determine true need for inter-board I2C bus communications and design solution #39

Open jeffchrisope opened 7 years ago

jeffchrisope commented 7 years ago

Most likely culprit subsystem here is ADCS, and a good example is the magnetometer, which will very possibly NOT be on the same board as the BDot controller, or might be on the same board with the BDot but on a different board from the state estimator 432s, etc.

Main issues that will need to be resolved will be bus length problems (maybe needing buffers to re-boost so we don't have capacitance issues slowing the bus down and making it unreliable), and almost certainly having to solve the "reset line" issue as well.

Also, if we end up needing multiple bus instances for a single MSP (quite possible on the 432s, particularly), API needs to support that as well. See issue #3 for more info in that effort.

jeffchrisope commented 7 years ago

At this point, it looks like I2C will be used for all comms between components on the same board (if supported). This means we need multimastering working, as well as easy use of multiple devices (with different IDs) per bus AND multiple I2C buses.

MrWilson1 commented 7 years ago

Thanks Jeff for detailed explanation on this design decision.

Hello Everyone,

If the decision is to use I2C to communicate between processors on the same board, we need to make sure that we minimize its proliferation - because it a risky endeavor (it may look easy now, but the problems won't be seen until the end).

If the plan is to have sun sensors on every subsystem board, the sensors should tie into the existing subsystem 430 rather than adding a second 430 with an I2C communication bus.

Otherwise, we will be adding unnecessary complexity and risk to every subsystem - meaning reading a sensor is not core to the software design of a subsystem 430, but an I2C communication bus is. And if we have a latent bug that does not show until we are in orbit - it would take out all subsystems.

Mark

Sent from my iPhone

On Jun 3, 2017, at 9:28 AM, jeffchrisope notifications@github.com wrote:

At this point, it looks like I2C will be used for all comms between components on the same board (if supported). This means we need multimastering working, as well as easy use of multiple devices (with different IDs) per bus AND multiple I2C buses.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

jeffchrisope commented 7 years ago

Agreed - hopefully there won't be too much cross-processor I2C needed, most of the need will be multiple I2C slave devices (sensors), which we can't get away from. In some cases, we might want to have slaves on different buses from the same processor to mitigate risk, but I'm not 100% sure that will be needed.

The ADCS MSP432 is the main case where it's easy to imagine a scenario where a high-bandwidth comm channel is needed between it and another 430 (I.e faster than CAN), but it's possible we will avoid that entirely. Most of that comes down to the channel between the state estimator and the model predictive controller, which likely will have to reside on two different processors.

Re: your point about whether ADCS assets located on non-ADCS-dedicated boards should drive the decision to put another (ADCS) MSP on that board ... I think we can probably avoid doing that in most, or maybe even all, cases - but if we determine we MUST add another (e.g. the complexity of the ADCS functionality starts to drive risk up on the mission critical portions of the subsystems processor), that processor won't have a I2C channel to that local subsystem processor I wouldn't think - it will be its own island, throwing stuff onto the CAN bus. So that is "good", I think.

But ironically, just in general, we did get the feedback from the Planetary Resources demo yesterday to not have too many compute elements. They ended up in that boat (17!), and believe now they went a bit overboard. Of course, they are using more powerful processors, but still ... valid general point.

On Jun 3, 2017, at 10:07 AM, Mr. Wilson notifications@github.com<mailto:notifications@github.com> wrote:

Thanks Jeff for detailed explanation on this design decision.

Hello Everyone,

If the decision is to use I2C to communicate between processors on the same board, we need to make sure that we minimize its proliferation - because it a risky endeavor (it may look easy now, but the problems won't be seen until the end).

If the plan is to have sun sensors on every subsystem board, the sensors should tie into the existing subsystem 430 rather than adding a second 430 with an I2C communication bus.

Otherwise, we will be adding unnecessary complexity and risk to every subsystem - meaning reading a sensor is not core to the software design of a subsystem 430, but an I2C communication bus is. And if we have a latent bug that does not show until we are in orbit - it would take out all subsystems.

Mark

Sent from my iPhone

On Jun 3, 2017, at 9:28 AM, jeffchrisope notifications@github.com<mailto:notifications@github.com> wrote:

At this point, it looks like I2C will be used for all comms between components on the same board (if supported). This means we need multimastering working, as well as easy use of multiple devices (with different IDs) per bus AND multiple I2C buses.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/UWCubeSat/DubSat1/issues/39#issuecomment-305988275, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGdloO16EjjJX-PdHHFA4WpTaCIc4dTnks5sAZLOgaJpZM4NZ-eR.