Improve hello message exchange

midgard commented

2021-02-01 18:03:20 +01:00

(Migrated from git.zeus.gent)

Make controller resend hello periodically.
Make module wait random time before answering a hello to mitigate conflicts on the bus.

- Make controller resend hello periodically. - Make module wait random time before answering a hello to mitigate conflicts on the bus.

j commented

2021-02-01 21:32:00 +01:00

(Migrated from git.zeus.gent)

The first part might not be needed if we assume CAN transmission to be reliable.

The second part might not be desired, but not for the reason you think: if we just delay() before sending the hello message, the hello messages of other modules will overflow our RX buffer. If we however transmit all at once, the collision avoidance will make sure only one packet at a time is sent, the code on the microcontroller will then sequentially handle every CAN packet. A better solution however would be to busyloop in the random "delay" and keep handling packets.

The first part might not be needed if we assume CAN transmission to be reliable. The second part might not be desired, but not for the reason you think: if we just `delay()` before sending the hello message, the hello messages of other modules will overflow our RX buffer. If we however transmit all at once, the collision avoidance will make sure only one packet at a time is sent, the code on the microcontroller will then sequentially handle every CAN packet. A better solution however would be to busyloop in the random "delay" and keep handling packets.

midgard commented

2021-02-01 21:37:00 +01:00

(Migrated from git.zeus.gent)

The first part is still useful for newly connected modules. I noticed this in practice when we were still physically working on OBUS: the controller is turned on first and modules only after that. It would be sweet if they show up without restarting the controller, and it's not hard to implement.

midgard commented

2021-02-01 21:38:24 +01:00

(Migrated from git.zeus.gent)

For the second part: I had imagined setting a timer variable and letting the main loop loop, with a check to see if it should send the reply already. If you think the CAN module will already handle this, it's not necessary though.

j commented

2021-02-01 21:48:08 +01:00

(Migrated from git.zeus.gent)

Didn't think of that, this does seem useful now. How will this interact with the info phase? If the info phase doesn't get repeated, module that need this will instantly crash.

j commented

2021-02-01 21:50:17 +01:00

(Migrated from git.zeus.gent)

Looks like a good solution! The CAN module will handle collisions and make sure all messages get delivered, but the receive buffer can still overflow.

midgard commented

2021-02-01 22:07:02 +01:00

(Migrated from git.zeus.gent)

The receive buffer overflowing would imply that the main loop was stopped. Do you mean that the CAN module might block the CPU when it has messages in the "retry sending" queue?

j commented

2021-02-01 22:36:42 +01:00

(Migrated from git.zeus.gent)

I looked into it in the datasheet: the CAN chip will, independently of the microcontroller, keep retrying to transmit when it loses arbitration (when it loses the priority race). That means that the random delay is not needed I think. It will also retransmit if an recoverable error happens.

Improve hello message exchange #2