PTR: pointer to the packet’s current instruction, so the pattern is pck[pck[0]] ==INSTRUCTION_KEY
PHTTL: how many ms the packet can hang in each device before being deleted. Due to scheduling algo, this is effectively a priority as well.
MSEGSIZE: the maximum segment size possible to transmit along this route.
ROUTE: see below
PAYLOAD: any # of bytes
Routes
Routes are encoded as a series of instructions in the packet. Instructions behind the PTR encode the path back to the packet’s source, and instructions in front of the PTR encode the path forwards.
KEY
NUM
INSTRCT
TKEY_LINKF
12
FWD Packet on ARG1 Port
TKEY_BUSF
14
FWD Packet on ARG1 Link, to ARG2 Address
TKEY_PORTPACK
33
Packet is destined for port at ARG2, originated at port ARG1
System Messages
Runtime Info Collection
Runtime Info Request
B0
B1
B2
B3
B4
B5
MSG_KEY
MSG_ID
Sweep Session ID
101
uint8_t
uint32_t
Runtime Info Response
B0
B1
B2
B3
B4
B5
B6
B7
B8
B9
B10
B11
B12
B13
B14
B15
B16
B17
B18
B19
B20
MSG_KEY
MSG_ID
Prev. Sweep Session ID
RT_TYPE
VERSION
Entry Route
Port Count
Gateway Count
Bus Count
102
uint8_t
uint32_t
KEY
Major
Mid
Minor
Disambiguation of Entry...?
uint16_t
uint16_t
uint16_t
Port Info Collection
We need to collect information on system ports, in this case we are getting a type key for each.
Port Info Request
B0
B1
B2
B3
B4
B5
MSG_KEY
MSG_ID
Query Start Index
Query End Index
103
uint8_t
uint16_t
uint16_t
Ports can be null’d out, i.e. we can have holes in our list…
Port Info Request
B0
B1
B2
...
BN
MSG_KEY
MSG_ID
PTYPEKEY @ Start Index
...
PTYPEKEY @ End Index
104
uint8_t
KEY
...
KEY
… overall, I think the redux should simplify this kind of thing; let’s just grep one port per message: name and type, or a “null” … then we can do link-layer stuffing of multiple packets per frame - it should save some flash. It also makes the spec easier to describe, which is a valid metric.