The high level design is like so:
The most important structure in the shalias crate is SHAlias. It oversees all communication to the hardware.
The UI communicates with the SHAlias via the SHAliasController, which runs in its own thread to avoid blocking the UI. The SHAliasController defines commands (SHAliasCommand) and responses (SHAliasResponse) to control the hardware and receive responses across mpsc channels.
SHAlias uses SHMessage to talk to the hardware. This object's layout is specified by the SparkLink protocol documentation (see section 2. DEFINITIONS). It contains 2 main pieces:
- Pfc: Protocol function code. Describes the type of message/response
- These are converted to an
SHMessagewith.to_message()(see pfc_impl.rs). The value (see below) is either inferred or provided as an argument to thePfcitself before converting to a message.
- These are converted to an
- value: 6 bytes of information pertaining to the Pfc.
Responses often consist only of a simple MessageCode at the beginning, simply stating whether the hardware understood the command.
Messages can be collected in an SHUserProgram. This is essentially a vector of messages which helps you out by assigning sequence id's to the messages once you're ready to send them (see get_messages()).
However, not all messages need to be part of a user program to be used. Certain messages can be sent standalone, like when reading the unit's serial number. The crate also provides the ability to send_command_sync(), which packages the message into a user program to skip the overhead of creating the program yourself. Note that this should only be used with commands that are meant to run as part of a user program - this excludes commands that expect a response other than a MessageCode::Ack, like Pfc::SoftwareRevision (use SHAlias::sw_rev() and other relevant wrapper functions in these cases).