Software Architecture

Key Software Components

The following Block Definition Diagram shows the major components of the Solo Controller application. This software is designed to run as a single threaded application.

The Solo Controller App uses the TaskMangerIO library to schedule tasks to be run on the Mega 2560 controller. This provides a convenient mechanism for managing all the individual tasks used by the application. Tasks can scheduled to run at different rates. So, as an example, user interface tasks can be scheduled to run frequently to ensure the UI is responsive. However, sensor tasks can be read at a slower rate, since these values are expected to change more slowly.

All of the tasks run by TaskMangerIO are run sequentially within a single thread. So, only one object/function/task can be running at any one time. Therefore there is no need to protect the global data structures (temperatures, volume readings, etc) with mutex or semaphore protections.

The various other classes used by the application include:

• TempSensor: Interface to the PT100 RTD temperature probes
• VolSensor: Interface to the volume sensor installed in the Kettle
• AlarmManage: Monitors sensor values against set values. Triggers audible alarms when out of bounds. Notifies SoloMenu of alarm conditions
• PID_Manager: (TBD)
• SoloMenu Collection of User Interface classes, described in more detail below.

The following object diagram shows how these components interact with one another:

Upon startup, the application will register a number of default tasks with the TaskManager. These tasks handle basic functionality such as updating the user interface, reading temperature and volume sensors, and monitoring for alarms.

The user interacts with the application via the TFT touch screen display. If possible, SoloMenu will respond directly to user requests. In some cases, SoloMenu will implement the behavior by sending a new task to TaskManager. Some examples of tasks that could be generated by SoloMenu, include turn on/off temperature PIDs and turning on/off the system alarm.

Note that user interface graphics and font imagery is not passed between objects. The SPI interfaces used by the electronics just isn't fast enough to efficiently transfer this data in a timely fashion. Instead, the images uses by the UI are either either stored in TFT ROM or is generated by the TFT/LT7683 graphics engine. The resulting images are loaded into TFT RAM, making it available to SoloMenu.

User Interface Classes

The classes that implement the menu system for the Solo Controller app are shown in the following diagram:

SoloMenu is an abstract base used by all menu objects. SoloMenu defines the common methods used by all menu classes. It also provides a basic button management capability. Derived menus just need to register their buttons with SoloMenu. SoloMenu will track screen touches by the user, checking to see if one of the registered buttons has been pressed. Once a button is pressed, the buttons callback function is called.

Low level functions that drive the TFT/LT7683 graphics chip are contained within TFTM070A1 class. This is a slight repackaging of the low level functions provided by BuyDisplay.com for use with their ER-TFT070A2-6-5633 TFT. The SoloCanvas class provides higher level TFT/RAM management functionality. The menu objects use SoloCanvas to load, display, and manipulate imagery stored in TFT RAM. This insulates the menu classes from the lower-level graphics display details. Instead, the only need to interact with the simpler interface provided by SoloCanvas.

Each menu consists of:

• Background imagery, which is stored managed by a SoloCanvas object
• Dynamic text, provided by the DynamicText and TextBox objects
• Buttons, provided by the various button classes shown in the following diagram

The base Button class handle core functionality such as graphics updates, button presses/releases, and initiation of callback functions. There are a number of derived button classes that provide buttons with slightly different behaviors:

• ToggleButton: Has two States: on/off. Each state has it's own callback function. The callback functions are called whenever the button is pressed. Examples: Pump on/off button and Alarm on/off button
• MomentaryButton: Has two States: on/off. Each state has it's own callback function. The "on" callback function is called whenever the button is pressed. The "off" callback function is called whenever the button is released. Examples: Setup button on the main menu (Setup menu appears after user releases the button).
• ImmediateButton: Has a single state and a single callback function. The callback function is called whenever the button is pressed. Examples: Buttons that switch between setup menus
• TextBox: Dynamic text that is also an ImmediateButton. When the button is pressed, the DataEntry dialog appears, giving users the ability to update/change numerical values. Example: Kettle set temperature.

Font Classes

Future Section....

Software Dependencies

The following diagram shows the dependencies between the major c++ header and cpp files in the project. The goal with this analysis was to avoid circular dependencies and, where possible, eliminate unnecessary dependencies between files.

Note that main.cpp only uses TaskManagerIO.h and Tasks.h. This means that Main.cpp does not have access to the alarms, sensors, menus, and canvases used by the application. It only needs to understand how to schedule tasks with the TaskManager. The file that implements the Tasks, Tasks.cpp, is responsible for interacting with the alarms, sensors, and menu objects used by the app.

Common parameters, such as Arduino pin definitions, are contained within Common.h

TBD: The write-up in this section needs to be updated.