Episode 16: Burkhard on Qt Embedded Systems

View this email in your browser

Welcome to Episode 16 of my newsletter on Qt Embedded Systems!

This newsletter is a bit shorter than usual. I had too much on my hands this month: a full-time project, a license-compliance project on the side, preparing a talk, writing a post and more.

If you are an experienced freelance QML/Qt developer, I may have a gig for you (see below) on my current project: the operator terminal for a medical cleaning robot. If you are interested, let me know.

The Reading section offers powerful keyboard shortcuts for QtCreator, explains how to call C functions from C++, lets you achieve testing superpowers with approval tests and CLion and shows project managers and developers how to make the deadline.

Enjoy reading and stay safe - Burkhard 💜

My Blog Posts

How to Set Up QtCreator for Cross-Compilation with CMake in 5 Minutes

This post is my third attempt to get cross-compilation with CMake from QtCreator right (see my first attempt and my second attempt). As all good things come in threes, I am pretty sure that I nailed it this time. I have successfully tested the script with the SDK of the SECO SBC-A62-J (quad-core i.MX6) and with the SDK of the Toradex Verdin i.MX8M Mini. Within 5 minutes, I was able to cross-build my Qt applications from QtCreator. Let me know your experience with the script.

A Freelance Gig

My current customer is looking for an experienced freelance QML/Qt developer (full-time and 100% remote). The developer would implement major parts of the GUI in a mostly self-dependent way. A detailed GUI design is available. The developer would work alongside the UX designers and me. I have been on the project since January.

Together we’d build a Display unit for a medical cleaning robot. The display unit runs on a Yocto-built Linux system powered by a Toradex Verdin i.MX8M Mini computer-on-module. The display talks to the robot via Bluetooth and to the cloud via an LTE modem. Users identify themselves with an RFID card. We’d use Kanban and make sure that every feature is well-tested and fully integrated with the rest of the system.

The full-time contract will start in May (probably even in April) and will run for 2-3 months (maybe longer). If you are interested, reply to this email and let me know why you are the one.

News

Qt Embedded Days, 13-14 April 2021 (organised by KDAB)

You can find a teaser of the available talks on the page Speakers 2021 (the page Program is still empty). My favourite talks so far are:

• Dealing with physical units in modern C++ by Nikola Jelić (Zühlke). I hope it makes the conversion between metric and imperial units easier. I still get nightmares when I think of the ugly C++03 code I wrote for two harvester HMIs.

• Simulator Training for Hardware Pilots – Case Study: simulating CAN-Bus attached hardware by Alexander Trica (Data Modul) and Kevin Krammer. For my two harvester terminals, I built very simple ECU simulators that exchanged CAN messages over a TCP connection with the terminal. Such simulators are helpful for integration tests. I am very curious how Alexander and Kevin tackled the problem.

• Demystifying C++ for C embedded developers by Giuseppe D’Angelo (KDAB). I never miss a talk by Giuseppe. I always come out a lot smarter. Recently, I had to write some C code for a microcontroller. It was a real painful exercise: why is everything so long-winded! I was happy when I could return to my beloved C++.

My talk How to Set Up QtCreator for Cross-Compilation with CMake in 5 Minutes was accepted as well. I’ll show in a live demo that the 5 minutes are achievable. I had to withdraw my other talk How to Get the Architecture of Qt Embedded Systems Right, because I ran out of time.

Reading

Top 7 Shortcuts in Qt Creator (video) by Jesper Pedersen (KDAB)

When I pair-program with people, I get impatient with people spending tens of seconds if not minutes to click around their way in QtCreator with a mouse. On the first occurrence, I tell my partner about an existing keyboard shortcut. On the second occurrence, they hear a disapproving grumbling as a reminder. On the third occurrence, I take away their mouse for the rest of the day 😉

As an HR manager for KDAB, Jesper goes through similar steps in job interviews. Jesper recorded a video to teach you more than 7 extremely useful keyboard shortcuts for QtCreator.

The keyboard shortcut with super powers and probably the least known one is Alt+Enter.

• Press Alt+Enter on any class name and QtCreator will offer you to insert the corresponding include file.

• Press Alt+Enter on a base class in class Derived : public Base and QtCreator offers to insert the declarations and definitions of virtual functions in the header and source file, respectively.

• Press Alt+Enter on a function declaration in a header file and QtCreator offers to insert the definition in the header file inside or outside the class or in the source file. This is equivalent to right-clicking on the function and selecting and of the three actions Refactor | Add definition - always a fiddly endeavour.

• Press Alt+Enter on a Q_PROPERTY declaration and QtCreator will insert the implementations for the READ, WRITE, NOTIFY and other attributes.

• Try out Alt+Enter on other symbols in your C++ and QML code to discover more amazing use cases.

By the way, the last three tips are bonus tips from yours truly.

Jesper lists a couple of more keyboard shortcuts.

• Press F4 to switch between C++ source and header file.

• Press Alt+0 to hide the left side bar with the Projects and Open Documents view and press it again to make the side bar visible again. Alt+1 (Issues), Alt+2 (Search Results), Alt+3 (Application Output) and so on hide or show the output panes at the bottom.

• Press Ctrl+Shift+V to see a dropdown list with the last texts copied to the clipboard. You select the one you want to insert.

• Press F2 to toggle between the declaration and definition of a function.

• Press Alt+Left or Alt+Right to navigate backwards or forwards through the cursor positions.

Calling C Code from C++ With ‘extern “C”‘ by Arne Mertz (Simplify C++ blog)

Recently, I wanted to write unit tests for the C functions of a Bluetooth application running on a NordicSemi nRF52840 chip. Of course, I used QtTest written in C++. Arne’s article about how to call C functions from C++ helped me out.

The correct solution is to wrap an extern “C” declaration around the #include statements of C header files. Don’t forget to add LANGUAGES C CXX in the project call of your CMakeLists.txt file. CMake will then make sure that the C compiler is called for *.c files.

Testing Superpowers: Using CLion to Add Tests Easily (video) by Clare Macrae (Independent Consultant)

In , I had a detailed look at Clare’s brilliant talk Quickly Testing Qt Desktop Applications with Approval Tests. I understood at that time that Approval Tests is a divide-and-conquer approach to break down a tightly coupled application into many small, easily testable and loosely coupled units - always guided by tests. That’s by far not all as I learned from Clare’s new talk.

You don’t even have to break any dependencies and add any doubles, fakes or mocks, before you can write your first tests. You overload the function ApprovalTests::verify for the class under test. This function typically converts the state of the class into a string and writes the string to stdout, which is redirected into the received file.

A test executes a function on an object and then calls ApprovalTests::verify to log the changed state of the object in the received file. The received file contains a log of states and all other messages written to stdout. You copy the received file into the expected file. Now, you can change the code. Each test run will compare the received file with the expected file and flag differences.

Adding print statements at strategic places in the code and comparing the resulting logs with expected logs is straightforward. Strategic places are the seams where we want to break dependencies. These seams are the future interfaces. Approval tests check that the right values flow through these interfaces. In TDD, you would use mocks, which are pretty difficult to set up.

When you start putting legacy code under test, you often run into a Catch-22. You must change code before you can write the first tests. However, you must not change code without tests. In a personal conversation, Clare told me that the numerous automated refactorings of the CLion IDE can get you out of this tricky situation.

These refactorings are correct by construction. If you can break down a code change into a series of automated and safe refactorings done by CLion, you can perform the code change even without tests. Clare wants to explore this approach in more detail. And, I am looking forward to her next talk how to leverage automated refactorings for testing legacy code.

Making the Date by Ron Jeffries

The customer wants all the features of a product ready in perfect quality at a given date. Project management comes up with a big up-front plan to achieve this goal. The development team works extremely hard to implement as many features as possible. Three quarters through the project, it’s clear to everyone that the deadline is unrealistic.

The customer shouts at project management who shouts at the development team. The delivery date is not changed. The customer grudgingly pays more money to hire more developers. Eventually a product with less features than planned and with lower quality is released months after the original date. Nobody is happy.

Does this sound familiar? I bet it does. Ron explains how to avoid such death-march projects.

Ron starts with a realisation from Kent Beck: “It’s not that we don’t have enough time. We have too much to do.” A team of a given size can only implement and test an approximate number of features by a fixed date. The feature list needs prioritisation, because only a part of the features will be ready at the date.

Projects run into trouble, when the customer determines both the date, the scope and the resources (people and material). As customers almost always set the date and have a limited budget, project management must have control over the scope and must exercise this control to “make the date”. Ron characterises management as “the process of meeting the goals as well as possible, within the limitations of time and resources.”

The customer “has control over exactly one thing: which features are done next.” By prioritising the features, the customer ensures that “the team [delivers] the best combination of features, by the date”.

The developers are responsible for producing “fully implemented, truly available, running, tested features”. And, they must report their progress frequently to management and the customer. Management can only do its job - adapt the scope, if they have a pretty good idea where development stands.

In my projects, I set up a Kanban board for the development team and install weekly meetings with the customer, management and other stakeholders, where we demonstrate the finished features. These meetings are similar to Sprint Review Meetings. This practice robs customer and management of their standard excuses when a project goes south: “You developers didn’t tell us early enough. You didn’t work hard enough. You aren’t smart enough.”

Ron concludes: “All this doesn’t make successful software development trivially easy. But it does make it possible, and a lot more likely than what many of us have been doing before. Making the date is not a development responsibility, it’s primarily a management and customer responsibility. Let’s treat it that way.”

Copyright (C) *|CURRENT_YEAR|* *|LIST:COMPANY|*. All rights reserved.

*|IFNOT:ARCHIVE_PAGE|**|LIST:DESCRIPTION|**|END:IF|*

*|IFNOT:ARCHIVE_PAGE|**|HTML:LIST_ADDRESS_HTML|**|END:IF|*

Update Preferences | Unsubscribe

*|IF:REWARDS|* *|HTML:REWARDS|* *|END:IF|*