Difference between revisions of "Gen 1 Software"
| Line 9: | Line 9: | ||
{| class="wikitable" | {| class="wikitable" | ||
| − | |Type (Req/Resp) | + | |Type (Req/Resp) (1 bit) |
| − | |Source Identifier | + | |State Flags (7 bits) |
| − | |Destination Identifier | + | |Source Identifier (8 bit) |
| − | |Data | + | |Destination Identifier (8 bit) |
| + | |Data (1-500 byte) | ||
|State Flags | |State Flags | ||
|Checksum | |Checksum | ||
| Line 19: | Line 20: | ||
=== Type Frame === | === Type Frame === | ||
The Type frame, the first frame in a Gesture, is a 1 bit frame that determines whether a Gesture is a request from one board to another, or a response from one board from a prior request. This frame is a 0 for a request, and a 1 for a response. | The Type frame, the first frame in a Gesture, is a 1 bit frame that determines whether a Gesture is a request from one board to another, or a response from one board from a prior request. This frame is a 0 for a request, and a 1 for a response. | ||
| + | |||
| + | === State Flags Frame === | ||
| + | The 7 bits following the Type bit are the State Flag bits. This 7-bit frame allows transmitting boards to provide specialty signals to the receiving board. A low bit indicates a flag that isn't down, while a high bit indicates a raised flag. The current flags are as follows, from LSB to MSB. | ||
| + | |||
| + | {| class="wikitable" | ||
| + | |High Priority | ||
| + | |Low Priority | ||
| + | |No Override | ||
| + | |Reserved | ||
| + | |Reserved | ||
| + | |Reserved | ||
| + | |Reserved | ||
| + | |} | ||
| + | |||
| + | The flags are defined as follows: | ||
| + | * '''High Priority''': The board receiving the request should cease all operation immediately and respond to the request before continuing. | ||
| + | * '''Low Priority''': The board receiving the request can wait to respond to the request until the most convenient. | ||
| + | * '''No Override''': The board receiving the request has no choice but to comply with the request sent -- it should not exert any effort attempting to question or combat the transmitting board. If this flag is low, a board receiving a request has the ability to ask the transmitting board for clarification or request a re-consideration. If this flag is high, the receiving board should execute the request regardless. | ||
| + | |||
| + | Flags are stacking, meaning multiple flags can be high. For example, a high high-priority flag and high no-override flag means a board not only must comply without question, but it should do so immediately prior to continuing any of its standard operations. | ||
=== Source & Destination Identifiers === | === Source & Destination Identifiers === | ||
| Line 36: | Line 57: | ||
|00000010 | |00000010 | ||
|} | |} | ||
| − | |||
== Core Functions == | == Core Functions == | ||
Revision as of 02:41, 22 June 2017
STINGR (Stack Transmission & Inter-Nodal Gesture Repository is the primary software suite used within the HONEY architecture for communication between boards in a HONEY flight stack.
STINGR allows boards in the flight stack to do a number of critical operations and provides a large number of utilities for FTC's, providing an easy-to-use interface that masks the complexity of CAN Bus transmissions from developers. The STINGR library is primarily comprised of operations called Gestures -- any request or response on the CAN Bus is referred to as a Gesture. Gestures are comprised of a series of frames, which provide the following information for each transmission: Type (Request/Response), Source Identifier, Destination Identifier, Data, State Flags, and Checksum.
Gesture Specification
As mentioned above, a Gesture consists of a series of frames, each with a specific purpose. Each Gesture is transmitted on the CAN Bus, and allows all boards to determine if a Gesture is targeted towards them, and act appropriately. This section defines the specification of a Gesture, including a description of each of the frames.
More explicitly, a Gesture looks as so, with the leftmost frames being transmitted first, and the rightmost frames being transmitted last.
| Type (Req/Resp) (1 bit) | State Flags (7 bits) | Source Identifier (8 bit) | Destination Identifier (8 bit) | Data (1-500 byte) | State Flags | Checksum |
Type Frame
The Type frame, the first frame in a Gesture, is a 1 bit frame that determines whether a Gesture is a request from one board to another, or a response from one board from a prior request. This frame is a 0 for a request, and a 1 for a response.
State Flags Frame
The 7 bits following the Type bit are the State Flag bits. This 7-bit frame allows transmitting boards to provide specialty signals to the receiving board. A low bit indicates a flag that isn't down, while a high bit indicates a raised flag. The current flags are as follows, from LSB to MSB.
| High Priority | Low Priority | No Override | Reserved | Reserved | Reserved | Reserved |
The flags are defined as follows:
- High Priority: The board receiving the request should cease all operation immediately and respond to the request before continuing.
- Low Priority: The board receiving the request can wait to respond to the request until the most convenient.
- No Override: The board receiving the request has no choice but to comply with the request sent -- it should not exert any effort attempting to question or combat the transmitting board. If this flag is low, a board receiving a request has the ability to ask the transmitting board for clarification or request a re-consideration. If this flag is high, the receiving board should execute the request regardless.
Flags are stacking, meaning multiple flags can be high. For example, a high high-priority flag and high no-override flag means a board not only must comply without question, but it should do so immediately prior to continuing any of its standard operations.
Source & Destination Identifiers
The Source & Destination Identifiers, the second and third frames in a Gesture, are 8 bit frames that indicate the source of the Gesture. Each board developed for the HONEY architecture is catalogued and given a unique identifier code. These unique identifiers allow boards to identify who a request or response from, and respond accordingly. Note that each unique board is given a unique identifier -- The Count, the first HONEY-compliant avionics board, has the identifier of 0, but a subsequent revision of avionics would acquire a new identifier code. This allows boards to be aware of the specific revisions that are flying in the stack -- allowing them to dynamically take advantage of the utilities of newer boards as they are added. The identifiers are encoded into the STINGR suite, and one can call a simple function to determine what board was the source or destination, without memorizing or encoding any of these identifiers in local board code.
The following are the current identifier codes, as of writing (June 21, 2017).
| The Count (Gen 4 Avionics) | 00000000 |
| Biscuit (Gen 2 BMS) | 00000001 |
| Macaw (Gen 1 Radio) | 00000010 |