Software » Canbridge

h1. Modes

h2. Unrelated

* Send CAN messages as Broadcast messages; fire and forget

* Good enough for sensor values

* Robust code, not much that can fail

* Not good enough for e.g. Flashing firmware on remote device or even scanning nodes.

h2. Related

* Each package need an acknowledge

* Retransmitts are send if acknowledge is missing

* Heavy traffic if nodes are blocking each other.

* Complex code, but ok

* Order may not be guearanteed / optional

h1. Related

h2. Retransmits

* In starting phase there is an auto-tune which requires traffic

* There are at least some CRC errors

h2. Send package

* ringTransmitted.canPush()?

* store essage there

* Send it via RFM69

h2. Receive package

* If type is "Acknowledge"

** find corresponding message

** mark slot as acked/nacked

* If regular message/resend

** If resend: is the package older than the last?, drop it

** is it not last+1? send NACK via RFM69

** fill it in the receive buffer

** directly send acknowledge via RFM69

h2. Loop

* iterate Slots

* If WAITing: is message is older than ??ms, perform an resend

* If ACKed, pop it from the ring. Not the first non-ACKed? Error

* If NACKed, resend it, if there is no WAITing before

h2. Open points

* Acknowledge gets lost; retransmit started

** last-id for every net. Drop message if it matches

* RFM-Class receives messages in ISR as fast as possible. Sending acknowledge is done in the loop. 

** Order should be preserved.

** Makes things super slow

h2. State machine

h3. Sender event loop

* Each node sends a heartbeat every 5 seconds with the current message counter.

* A node has a list of (expected) package counter of other devices

* When a node received a message via can, it sends it as broadcast and sets the open-ack-mask to the node-mask

* If there was no ACK after 10ms, send retransmit to each Ack-missing node.

* If there was no ACK after 10 Seconds, remove remaing nodes from Node-List.

* If there is no Heartbeat from a Node for 1 Minute, remove node from  

h3. Receiver Event loop

* When receiving a message via radio with correct order, an acknowledge is send immediately. Process and drop the message. 

* When receiving a message via radio with to low order, send an acknowledge again and drop the message.

* When receiving a message via radio with too high order, act like in (1), but warn becuase of lost message.

h3. Keep order

To keep the order of the messages, the event loop need to handle only the oldest message in the list. 

This may slow down everything. All messages are blocked till a last node send an ACK. 

-This can be tested by making it optional.- This has to be the implemented or the message-counter does not work any more.

h3. Overflow

It may make sence to have a small message counter of 8bit, a bigger one is not really needed.

0 ... 127, -128 ... -1

Overflow-save operations:

<pre><code class="cpp">

#define TYPE    signed char

// Don't cast the types anywhere!

constexpr TYPE counterDistance( TYPE c1, TYPE c2)

{

    return( c2 - c1 );

}

static_assert( counterDistance(0x7F, 0x80) == 1, "A" );

static_assert( counterDistance(0xFF, 0x00) == 1, "B" );

static_assert( counterDistance(0x80, 0x7F) == -1, "A" );

static_assert( counterDistance(0x00, 0xFF) == -1, "B" );

</code></pre>

h3. CANRec

Replay-Messages (seperate function code) will be skipped. The order has to be kept anyways because of the message counter.

h3. Diagnose

Timing measurements would be nice but at high cost. Skip it for now.

h3. Methods

* enqueueReceiveRadioMessage

* enqueueTransmitRadioMessage

* receiveRadioMessage; physical transition of radio module to CANBridge state machine

* transmitRadioMessage; physical transition of radio module to CANBridge state machine

h3. States

* Invalid

* Unsend

* WaitForAck