Follow our illustrated blog on Embedded Software Architecture

How to build a hybrid solar/wind energy harvester?

Green4 power controller: remote control with Raspberry Pi

VN:F [1.9.22_1171]
Rating: 4.0/10 (1 vote cast)

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).


Test setup

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):

Distributed control

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.

Event-rate limiting

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.

Safety mechanisms


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.

VN:F [1.9.22_1171]
Rating: 4.0/10 (1 vote cast)

The embedded hierarchy – Part3

Linux-based software platforms Linux kernel In this section the Linux kernel part of an embedded software platform is discussed. Compiler While FreeRTOS (see Part2) has support for several compilers, the Linux kernel community has chosen GCC. … [Continue reading]

Responsive software design without threads — Part 1

responsive event-based I/O design

We need a GUI thread. a common developer's reaction when the application only responds slowly to user clicks. The developer might be right: when some (gui) events require a lot of processing then having more than one thread, e.g. a GUI thread … [Continue reading]

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 … [Continue reading]

The red-black tree and hash table

red-black tree The even more advanced container we look at now is the red-black tree, which is a type of self-balancing binary search tree. Especially, interesting is the time complexity in big O notation: Action/Subject       Average          … [Continue reading]

3D printing of enclosures

Having the correct and proper enclosures, is a mechanical (and also a marketing) problem many electronics projects suffer from. It is also related to anticipated sales numbers. For big numbers, a custom enclosure which is produced with an injection … [Continue reading]

Vector, list and tree

Choice of containers Information technology, even embedded devices, is about information gathering, processing or calculation, and control. Input and data needs to be juggled around and maybe sorted. In this article, we want to point out some … [Continue reading]

Priority inversion

I found the inspiration for this article while working on a consultancy job: Priority inversion. In computer science, priority inversion is a (potential) problematic scenario in scheduling in which a high priority task is indirectly preempted by a … [Continue reading]

Progress update

Time for another update. The Green4 project is progressing steadily. In the last few months, we have been busy preparing the Green4 prototypes. Test software has been developed which is already very usable, but it is still in a state of flux as we … [Continue reading]

Embedding a Basic interpreter

The green4 stm32 cortex m3 microprocessor we selected is - according to today's standards - a rather small microprocessor in Flash (128KB) and RAM (8KB). why an interpreter The Green4 device is running control software on top of FreeRTOS, with a … [Continue reading]