As long as real-time control and fail-safe operation is not a strict requirement, the GUI or another PC application could be used to control the Green4 via our rs232 serial protocol. The target software simply executes what is being demanded by the application, and returns its measurements at regular intervals.
Various – but mainly prototyping – applications are possible:
- testing hardware e.g. green4 hardware board
- evaluate algorithms on the PC side without having to update the target e.g. battery charge strategies
- remote telemetry e.g. collect target measurements
- controlling an application by hand e.g. lighting systems
- integrate the green4 as a slave in a machine
There is one inconvenience though: the serial link. Long cables are not very practical and serial communication is more error prone. Therefore, we have extended the Green4 GUI with tcp/ip server and client functionality. In order to test it, we have bought:
- a Raspberry Pi, and
- a Nano TP-Link wireless USB module (little black box with green led).
Here is an overview of our test setup:
- serial rs232 connection between Raspberry Pi and Green4 development board
- wireless tcp/ip connection between RP and a Linux laptop
- wireless tcp/ip connection between RP and a Windows laptop.
All devices (except for the target software) run the same program (green4 gui) but with different configuration. It also means this program is compiled to run in windows, linux i386 and linux arm.
The Raspberry Pi has a dual role: it has a direct connection to the target and acts as a tcp/ip server. The gui has to be started with this command: ./green4 -p4000 -s/dev/ttyUSB0 -g (listen to port 4000, connect to target via /dev/ttyUSB0 and do not start gui). The program starts a server when both port and serial link have been configured.
Both laptops are tcp/ip clients (e.g. ./green4 -a192.168.1.1 -p4000).
Here is a short bad-quality demo (Windows PC at the right side, Linux virtual machine at the back and RP with development board in the front):
As can be seen in the demo, this software architecture enables distributed control: the target can get commands from multiple ‘endpoints’. Distributed control is not uncommon in some domains (e.g. automotive), and it is the responsibility of the system’s architect to ensure proper functioning.
Of course, the bandwidth of the serial link is limited. For this reason we have implemented event-rate limiting: a new command overwrites a previous one if it is still in the send queue. This works quite well and the delay between command generation and execution is reasonable.
This being said, for applications that require fast response, it is probably better to write native code.
When the gui detects an out-of-sync setting, it will try to recover by re-sending the command.
An optional CRC at the end of each command would greatly improve link reliability. We still have to implement this feature though.