One important point for me was to be able to easily configure the hardware and to minimize the programming work, from the enduser perspective.
The system can handle 576 digital inputs, 360 digital outputs and up to 512 display digits. Some of these inputs will correspond to gray encoders, to interface rotary knobs. Quite often, these rotary knobs will be linked to displays that show their values. Also, quite often an output is linked to an input, so that a light can be led upon pushing a knob. I wanted that no programming tasks be involved for a user configuring such behavior. This is done internally in the arduino program and the user just have to supply a configuration file, in the form of a text file which will contain the following items :
ncardA, ncardB : number of OC mastercards connected to the A or B bank (up to 4 MC on each bank).
display : describe a display up to 6 digits. the user supplies the hardware address to which each digit is connected and the simulation purpose of the display (e.g. Heading on MCP).
gray : describe a gray encoder, by giving 2 inputs addresses on which it is connected, then initial value, step for each click, minimum and maximum value. If given an associated display number, the system will automatically update the display upon rotating the knob. It is possible to choose a cyclic or bound behavior to choose what happen when the limit is hit. A switch address can also be supplied to switch between two displays and two different values and steps. This is useful for example to control the NAV, COM or ADF where the same rotary can be pushed to switch between main and decimal frequency.
grayswap : describe an input which allow to exchange values between to displays, typically useful to exchange the active and standby frequencies in a NAV, COM or ADF.
button : allow to define a switch which can be either a temporary pushbutton, or a bistable button (retaining its on/off status). It can be linked to an output to light a LED, by giving the output channel to use. It can also be associated to a simulator item (e.g. LNAV on MCP, or ParkBrake, or Gear down/up lever, …)
output : to connect any output to a simulator item. For example, to light a LED for overspeed limit, or activate the stick shaker, …
analog : allow to select the simulator function for an analog input (throttles, brakes, rudder, yoke …). Minimum and maximum real values can be set, and a denoising algorithm can be parametrized to reduce spurious variations.
servomotor : allow to define a servomotor hardware connections, its maximum and minimum position and associate it with a simulator item (IAS, Brake pressure, artificial horizon axis, for example). The relationship between the simulator item (for example the IAS value) and the servomotor integer position (for the needle of the speed meter in this case) can be linear or quadratic. In some case it is more interesting to have a discrete set of positions (for example for the flap indicator), and this is handled in the configuration.
Configuration Tools
I soon realized that handwriting the configuration file was quite painful (yes, I am a bit lazy …) and that I needed a simple way to store the configuration on the system. The basic way was to write a text file, and copy it on the SD card on the arduino stack (DSTACK). I have then developed a configuration tool that allow a graphical design of the configuration in the form of tables, and allow to upload it on the DSTACK, on the ethernet network.
I am found of using Qt for programming, because it allows me to produce the same application for Windows, Linux and Mac in one single development. Below I included some screenshots of the tool (CKPTconfigurator, for cockpit configurator) :
