For most embedded projects it is good practice to have basic tooling for testing I/Os. I/O primitives such as ‘read gpio’, ‘set pwm duty cycle’, ‘read adc’, not only allow engineers to verify hardware and software drivers, it might also be very helpful to service and support people.
In our project we use a simple serial protocol which brings all I/Os to the end-user. Its main usage is testing but it could be used by a controlling application as well (more on this later). To give you an idea, here are a few protocol commands:
- h: help
- c <0-3> pwm,<0-100>: set pwm duty cycle of channel.
- c <0-3>: get channel mode/setting
- f pwm,<0-100>: set fan duty cycle
- l <0-3> <on,off>: set led on or off
The green4 will answer whether the command was successful or not e.g. c:0 3 pwm,80 (i.e. channel 3 was successfully set to pwm 80).
The protocol being ascii-based is a deliberate choice: ascii is human readable so the user only needs a serial terminal to communicate with the device. No additional tooling is required. A binary protocol would be more efficient though: less bytes to transfer and less parsing on target (ideally, binary data can be mapped 1-to-1 in a memory structure – beware of endianness!). As a consequence, cpu power and bandwidth is better utilized.
At this moment communication speed is configured as 9600 baud which is slow but reliable (less chance of hardware errors).
We are planning to extend the serial commands with an optional CRC.
But of course, it is nicer and more fun to work with a GUI. Here is a screenshot:
All peripherals are ‘exposed’ to the user:
- 4 ‘green’ channels for switching renewable energy including volts and amps measurements
- 3 supplementary channels e.g. for fan, external device etc.
- a collection of inputs configurable as gpio or adc/input capture
- board input voltage
- some leds
Also, it is possible to connect channels to each other by making groups (in the picture, channel 3 and 4 are each other’s complement).
Not too many features: the goal is to test hardware and basic software.
Choice of technology
The Green4 gui runs multi-platform on Windows and Linux (and probably OSX as well). In order to achieve this, the choice of GUI framework (or toolkit) is important. There are several possibilities such as Qt, Fox toolkit, wxWidgets, juce… but we choose FLTK because it is simple, lightweight and long-lasting (we know the code will still compile 20 years from now without much effort).
The windows executable is cross-compiled from Linux with mingw.
The linux version has several scripting possibilities and integrates well in the unix/linux environment. Some examples:
- ./green4: start the gui and do your thing there No scripting.
- ./green4 -s /dev/ttyUSB0: start gui and connect to serial
- ./green4 configuration.txt: start gui with certain config (connection and all I/Os can be configured)
- cat configuration.txt | ./green4 –stdin config1.txt config2.txt: read configuration from stdin and from 2 files
- ./green4 -s/dev/ttyUSB0 –stdout –nogui | grep ‘something': do not start gui but dump everything on stdout and grep a certain IO
Remote telemetry is an advanced feature we support as well (with the same tool!). This will be explained in another article.