Green4 serial test protocol and GUI

Introduction

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.

Serial protocol

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.

Gui

But of course, it is nicer and more fun to work with a GUI. Here is a screenshot:

green4 power controller gui

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.

Scripting possibilities

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.