The Parlaytm firmware codebase uses a C++ object oriented, single threaded, event driven architecture. It has a clear and repeated and extensible Active Object design pattern 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.
Just as intra-communications uses messages, the same method is used for inter-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. Command messages will result in the item function being called, and upon its completion, a response message is returned. Properties, which are member variables of the item, can be read, set, or streamed (as they get written or at a desired rate) . The Parlay UI allow the user to choose the item, and the item's commands or properties to control.
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.