.png)
The Parlaytm firmware codebase uses a C++ object oriented, single threaded, architecture. It has a clear and repeated and extensible design pan for easy project implementation and maintenance. This single threaded architecture prevents the threading and blocking perils that can cause intermittent instabilities. It also supports full software instrumentation - with external control and visibility throughout.
The Parlay instrumentation is accomplished by providing message based interface to the functions and variables of the C++ class. A preprocessor identifies those functions and variables that should be accessible, and generates the code to interface. In this manner, the internal member functions and variables can be called, set and streamed.
There are 4 main design elements:
Messages provide the intra-communications between items in the system. For example, a controller will send a message to a SPI based sensor driver to read an ADC. When the data is received a response message is sent back to the original caller with the data.
Communications between sub-systems, and the Parlay test tool. The functions and variables of each Item of each subsystem are "discovered", and made accessible as commands and properties respectively. This allows for external control of components, and monitoring of data - i.e. instrumentation.
The items in a subsystem are hierarchical - generally each item controls the items of the next level. However from Parlay test UI, all items can be accessed. For example, a temperature control item can be started with a chosen target temperature. The subsequent thermistor sensor response can be streamed and graphed live on the PC.
The
embedded codebase communicates with the above
described message which is the same over all communications links. The
packaging of the message may change from protocol to protocol, but the
content is always a messages. Unless the codebase is
communicating to other embedded system, the communications on the other
side will handle the discovery of items and translation of the message
structure to a JSON message. For example, a typical system would look
like the following:
For Bluetooth BLE communications, the BLE characteristics are translated into the message protocol of the firmware, making simple, discoverable controls from a mobile device.
For multiple subsystems in a system, the following scheme could be applied:
No matter the complexity of the system, the commands and properties of all system Items are accessible and controllable from the Parlay UI and scripting.
