Discover more from Better Built By Burkhard
Episode 6: Burkhard on Qt Embedded Systems
Welcome to Episode 6 of my newsletter on Qt embedded systems. This newsletter goes out to 130 people. Thank you very much for your interest 🙏 I would love to learn what you are working on and what topics interest you most. So, don't be shy: Reply to this email or contact me on Twitter (@wittyelk) or on LinkedIn (Burkhard Stubert).
This epsiode is mostly about Qt Virtual Tech Con 2020. I attended eight talks or watched them later. As most talks were given by employees of The Qt Company, the talks were slightly biased towards the commercial Qt offerings. So, I assess these talks from my outside perspective in addition to giving short summaries.
Enjoy reading and stay safe - Burkhard 💜
My Thoughts on 7 Years as a Solo Consultant
Seven years ago, on 1 June 2013, I started my own business as a solo consultant. At that time, I was nearly 45. I had a big mortgage on a rented-out flat. I had a high cost of living in Stuttgart. My family and friends declared me nuts doing such a risky move advanced in years. Only my wife supported me full-heartedly and was sure that solo consulting was exactly the right thing for me.
And - my wife was right. I have never regretted becoming self-employed. I have the privilige to work on interesting projects (e.g., driver terminals for maize and sugar beet harvesters, infotainment systems, metal sheet benders, e-bikes) mostly with amazing people. I can do what I love most: develop Qt embedded systems.
We have done pretty well. We live in our own flat in Muehldorf am Inn with a panoramic view of the Eastern Bavarian Alpes, where we love to hike, bike and go cross-country skiing. The mortgage will be paid off in two years. My family and friends still think I am crazy - but may be a little bit less 😉
I looked back at being a solo consultant after three years and after six years. I am currently in the process of moving from freelancing (doing things myself) to consulting (coaching other people to do things). Here are four pieces of advice that I hope to be useful for aspiring or active solo consultants.
Find your niche.
My niche is Qt embedded systems, probably even LGPLv3-Qt embedded systems. I moved from Qt desktop development to embedded development in 2006 and I haven't done anything else ever since. When going solo in 2013, I didn't decide consciously to focus only on Qt embedded systems. It was the natural thing to do. Once I had finished the first embedded project, the next embedded projects were easier to find. So, it took on a life of its own.
In retrospect, I think that I should have made a more conscious decision about my niche. The goal is to find or define a niche where you are "the" authority or at least one of the top-5 experts. If people think of your niche or google for it, you must come to their mind instantly or be on the first page of search results.This helps you to differentiate yourself from your competition and to demand higher fees. If you do everything, you will compete with everyone. Your differentiator will be the lowest price.
I am certainly not suggesting to buy a higher SEO rank on search machines or ads on Google, Facebook or Twitter. It's not worth the money. Ask yourself: Do you ever click on promoted links or ads? I am pretty sure you don't. And neither do your prospective clients.
Sorry, there are no shortcuts for marketing yourself. There is only the hard way ☹️ You must invest a lot of time for marketing. You write blog posts and newsletters, create video tutorials and podcasts, give talks on conferences, help other people online, write a book, get references from your customers, etc. You do all these activities with a razor-sharp focus on your niche. Otherwise, you waste your time. All your activities must provide real value to the recipients.
Then after some years of hard work, projects will start finding you. You will have to do less cold-emailing. The search for new projects will become easier. It feels like magic when a project finds you. It happened to me a couple of times, but I still have a long path towards nirvana.
Bonus tip: Make sure in your proposals that you get marketing rights for the project. Customers always ask to reduce your fee. Never do this without getting something in return. Marketing rights are such a thing.
Create your own intellectual property (IP).
This is my sore point. For example, I built CAN middleware three times in the last seven years (twice for harvesters, once for e-bikes). I had to write the software three times from scratch - instead of reusing it the second and third time. The problem is that I gave away the exclusive usage rights to my customers. I didn't even negotiate higher prices for this exclusivity.
Instead, I should have offered my customers three options.
Option 1: I keep exclusive usage rights and grant the customer non-exclusive usage rights.
Option 2: I grant the customer exclusive usage rights for 2-3 years. I regain exclusive rights after this time period.
Option 3: I grant the customer exclusive usage rights forever and waive my rights.
Of course, Option 1 is the cheapest and Option 3 the most expensive. The three options give me a lever in negotiating the fees. Remember: Never reduce your fee without getting something in return.
When customers choose Options 1 or 2 (most will), I can use the software parts with non-exclusive rights for the customer to build up my own IP. This gives me leverage for the next project requiring this kind of IP. My IP saves the next customers considerable development time. I would offer this IP in addition to my normal services - for a higher fee.
Build up a financial buffer.
The COVID-19 pandemic made it crystal clear how important a financial buffer for solo and small businesses is. Many of these businesses saw their income drop to zero when the lockdown started. The German government, for example, promised 50 billion Euros of aid for solo and small businesses. By quickly changing the initially generous rules, the government cheated most solo businesses out of the aid and redirected them to social welfare. Some lucky people were granted aid, but they haven't received it yet.
The lesson is clear: Don't rely on anyone to help you through a tough period - not even in a pandemic. Be sure that you will have periods of no income - even in normal times. I had two 6-month periods of zero income during the last seven years.
I started my solo business with enough cash reserves to get through three months of no income while maintaining my normal living standards. I also had the first big contract in the pocket, when I quit my regular job. Over the next years, I built up my reserves first to six months and now to twelve months. So, I could go without income for a year without draining my retirement funds. It lets my wife and me sleep a lot better.
Bonus tip: I do the monthly revenue tax declarations and the yearly tax returns myself (the tax software is, of course, written with Qt by a well-known Qt consultancy 😉). This way I always know exactly how much money is coming in and going out.
My Blog Posts
Qt Embedded Systems - Part1: Building a Linux Image with Yocto.
Step by step, I walk you through building a Qt embedded system, an Internet radio, with Yocto in a Docker container. The Internet radio runs on a Raspberry Pi 3B. At the end of the post, you can power on the Raspberry Pi, which starts playing a preset station in the radio application.
This is the first part of a series on building Qt Embedded Systems. My plan is to publish one part per month. My plans for the near future include the following topics.
Building the Qt SDK (with stripped-down meta-toolchain-qt5 recipe) such that developers can run and debug the radio app on the Raspberry Pi instead of their desktop PC.
Explaining the recipes from the layer meta-cuteradio and organising them in a modular way.
Simplifying the setup of a build environment with a setup-environment.sh script or kas, a setup tool for bitbake-based projects (thanks, Marek, for pointing me to kas 🙏).
Updating the Yocto version step-by-step from Thud (2.6) to Dunfell (3.1).
Running the Internet radio on other SoCs like the i.MX7 (no OpenGL) and the Raspberry Pi 0W.
Making the Internet radio use Wifi instead of Ethernet.
Creating a Wayland-based window and application manager for multiple apps like image viewer, alarm clock and settings.
Minimising the Linux image.
Optimising the startup time of the system.
And many, many more.
You see that I have plenty ideas for this series. Keep your fingers crossed that I find enough time beside the paying projects 😉 Please tell me which topics interest you most.
Book Review: "Accelerate" by Nicole Forsgren et al. In Episode 5 of my newsletter, you could read my review of Chapters 1, 2 and 4 of Nicole's book. In my post, I added Chapter 5: Architecture to the review. A good architecture is of paramount importance to the success of software development projects. A loosely coupled and well encapsulated architecture is “the biggest contributor to continuous delivery […] – larger even than test and deployment automation […]”.
If the components of a system are loosely coupled, the component teams can work mostly independent of each other. The teams can develop, test and release even large-scale changes with little or no communication with other teams. The structure of the organisation influences the structure of the system and vice versa.
Loosely coupled organisations scale a lot better than tightly coupled organisations (see Figure 5.1).
High performers with 1000 developers deliver their sotware three times more often than medium performers with 1000 developers.
High performers with 1000 developers deliver their sotware three times more often than high performers with 100 developers.
Low performers don't scale over 100 developers.
High performers have a very loosely coupled organisation and achitecture, whereas low performers have a very tightly coupled organisation and architecture.
Qt Virtual Tech Con 2020
Building an app with Qt for MCUs on top of FreeRTOS by Bartosz Taczala, Siili.
The NXP 1170 is a dual-core microcontroller with a Cortex-M7 core and a Cortex-M4 core. The M7 runs the non-certified part of an embedded system with the HMI on FreeRTOS. The M4 runs the certified part of the system bare-metal. Partitioning a system into a certified and a non-certified part is common practice, although a Cortex-A microprocessor will normally take the place of the M7. The NXP i.MX8 and i.MX7 are well-known examples.
NXP provides a lightweight implementation of the RPMsg protocol such that the M4 and M7 core can communicate through shared memory with each other. Bartosz gives a code example for the inter-core communication. The Linux kernel supports RPMsg as well. So, Bartosz's talk and the NXP's RPMsg documentation look like a good starting point to get RPMsg communication working on an i.MX7 or i.MX8. Bartosz will make the example code available on his github site.
In the Q&A session, Bartosz mentioned that Qt for MCUs requires compiled QML. Loading and parsing QML files at runtime doesn't work.
Getting Started with Yocto & eLinux by Tino Pyssysalo, The Qt Company. Tino shows how to install a Boot2Qt SDK on a Windows PC, how to install the corresponding Boot2Qt Linux image on a Toradex i.MX8 board and how to run a 3D-heavy application on the i.MX8. Within a couple of hours (spent mainly on waiting for the download to finish), you are in a position to run, debug, test and profile your application remotely on the target device - in the same way you would do it on the PC. Having feedback right from the project start is invaluable. And - it's only fair that you can only enjoy this goodness with a commercial Qt license.
If Boot2Qt is so great: Why do many businesses nevertheless use Qt under LGPL for their embedded systems?
The Boot2Qt image contains all the Qt modules plus all the Linux packages required by them. You must remove from this maximum image all the packages you don't need. The embedded systems I help building typically need less than half the available Qt modules.
Boot2Qt images are only available for unmodified development boards from Toradex, Boundary Devices, NVIDIA and others. Production boards rarely come unmodified. The board needs four CAN ports instead of the single standard port. Heavy vibration of the machine demands that the CAN and Ethernet ports must be provided through Deutsch and M12 connectors, respectively. You must adapt the Linux image to all these hardware modifications.
The startup time of the Boot2Qt image is far too slow for most products. You must optimise the startup time.
You will easily spend three months to fix the above problems. Or, you'll pay someone to do it for you. These costs are not included in the license fees of Qt for Device Creation. These customisations could be covered by the royalties you must pay per embedded device. So, businesses would get some value in return for the royalties. The Qt Company would get a simple justification for charging royalties and businesses would have a reason less to bail on Qt Commercial.
Advanced session on Yocto & eLinux by Samuli Piippo, The Qt Company.
Samuli walks you through building and customising a Boot2Qt image and SDK for the i.MX8 yourself. The result is similar to the image and SDK that Tino used in the previous talk Getting Started with Yocto & eLinux. Here are the steps with the starting times in parentheses.
Getting the Boot2Qt Sources (3:50). You download the layer repositories for OpenEmbedded, Poky, several BSPs (Freescale, NVIDIA, Toradex, Raspberry Pi, etc), Qt and Boot2Qt with the repo tool.
Using Docker Container for the Build (5:25). You can use the simple Dockerfile provided for building the Boot2Qt image and SDK.
The Build (7:07). It takes four commands and a couple of hours waiting to build the Boot2Qt image and SDK. The BitBake targets are b2qt-embedded-qt5-image and meta-toolchain-b2qt-embedded-qt5-sdk. The flashing wizard located in /path/to/Qt/Tools/b2qt is a utility for burning the image to the device's flash storage.
Customizing the image (8:22). You customise the Boot2Qt image in a separate layer for your product. Extending existing recipes in .bbappend files is the preferred way. This way you can remove packages from the image, add packages to the image, apply patches to package sources, change kernel configurations, remove specific packages from package groups and set Qt environment variables.
Samuli suggest to add DISTRO_FEATURE_remove = "webengine" to local.conf to "limit the size of the image" and to "make the build faster". I second this. When I recently built Boot2Qt, building Qt5WebEngine not only took ages but also failed. Webkit Port for Embedded Qt or WPEQt for short may be a good alternative for embedded systems.
Getting Updated Packages to the Device (17:39). As an application developer, you don't want to fiddle around with Yocto recipes and you don't want to wait for lengthy Yocto builds. It's more efficient, if one or two people maintain and build the Linux image and provide the latest packages through the packge feed. Updating packages on the embedded devices becomes as easy as on the desktop PC with the package manager.
You create a package index with bitbake package-index, start a web server in the directory tmp/deploy/idk with python3 -m http.server and add the package feed URLs, which point to directories on the development PC, to the file /etc/opkg/opkg.conf on the device.
At the beginning of the talk, Samuli states that "Boot2Qt itself is open-source. So you can download the source [...] and build your images using open-source Qt as well." This statement is not wrong. It only leaves out the fine print.
Boot2Qt builds all Qt modules - no matter whether they are licensed under Commercial, LGPLv3 or GPLv3. If you want to use Qt under LGPLv3, you must remove all the Qt modules that are only available under Commercial or GPLv3. I find it easier to add packages to a minimal image than removing images from a maximal image.
Using Modern CMake with Qt by Kevin Funk, KDAB.
Kevin gives a compact and easy-to-follow introduction how to write CMakeLists.txt files with modern CMake (versions 3.x). Loyal readers will know most of the tips from the CMake special in Episode 4 of my newsletter.
Enabling AUTOMOC merges all the files generated by moc into one big source file (one-big-file approach). The alternative is to have moc generate a file for each header file containing a Q_OBJECT macro (many-small-files approach). Kevin saw a 5% speedup with the one-big-file approach over the many-small-files approach. The overhead of creating a new compile process for each moc file outweighs the gains from building individual moc files in parallel.
Craig Scott makes the opposite observation in Section 30.3.1 Moc in his book Professional CMake (6th Edition): "If the number of classes processed by AUTOMOC [...] is very large, [...] it can make larger builds less efficient, so it may be desirable to have the generated files compiled individually to take advantage of build parallelism and reduce resource requirements."
My observations are more in line with Craig's. However, I haven't done any measurements. So, Kevin's advice may depend on the concrete situation.
Qt Quick 3D: An Introduction and Best Practices by Andy Nichols, The Qt Company.
I have always conjectured that Andy has magic skills. He kept talking fluently, while typing out answers to the audience's questions - without ever skipping a beat 😉
The QML-based Qt Quick 3D is a high-level and simple extension of the C++-based Qt 3D. It doesn't have all the features of Qt 3D yet, but it makes essential features like models, materials, lights and cameras easy to use. Qt Quick 3D comes with a tool called balsam that generates QML code from 3D models.
Qt Quick 3D was a technology preview in Qt 5.14 and was released in Qt 5.15. It is available under the Commercial license and GPLv3. It is not available under LGPLv3.
Andy smuggled a cool refactoring feature into his talk: He selected a piece of QML code in QtCreator and applied the refactoring Move to Component. QtCreator created a new file containing the selected code.
Build your first WebAssembly application by Morten Sørvig, The Qt Company.
Qt for WebAssembly enables you to run Qt applications in Web browsers. The Emscripten compiler translates C++ source code into WebAssembly (Wasm, for short). Modern browsers know how to execute Wasm binaries. Morten walks you through all the steps needed to run a simple QML application in Chrome.
QtWasm has been available since Qt 5.12 under Commercial license and GPLv3. It is not available under LGPLv3.
QtWasm supports only a limited set of the Qt modules: base, declarative, quickcontrols2, websockets, svg, charts and mqtt. It does not support qtmultimedia and qtwebengine. Other modules may or may not work. They haven't been tested. Multi-threading is disabled by support, because only Chrome supports it at the moment.
QtWasm lets Qt applications enjoy the same advantages as Web applications: zero-install (app as URL), no app store reviews and sandboxing. I doubt that these advantages compensate for the disadvantages of web applications like huge resource consumption and sluggish responsiveness. However, I think that QtWasm could save you considerable development costs.
Developing certified Medtech products with Qt by Roger Mazzella, The Qt Company.
Roger is the Senior Product Manager for Medtech at The Qt Company. He has 20 years of experience in the medtech industry from the product side. He gave an excellent introduction into the certification of medical devices.
Qt is used in FDA (Class I, II and III) and EU (Class I, II, IIa, IIb and III) certified medical devices. The focus of device certification is on mitigating or eliminating risks. There are three main risk ares.
Clinical risk - product will not work as intented. The Qt Safe Renderer - so far The Qt Company's only safety-critical tool - is certified up to class C of IEC 62304. The Qt Company has partnered with Emergo by UL to help its customers comply with global medical regulations.
Human factor risks - product will not be used as intended. Doctors and nurses must be able to operate medical devices without effort in high-stress situations. Hence, usability testing is part of the certification. During development, quick and frequent feedback from the users is paramount. Assembling the UI with Qt Design Studio is preferred over writing code, because it reduces the risk of introducing errors. Roger summarises mitigation for human factor risks in these catchy sentences: "Design in usability. Design out use error."
Cyber-security risk - product will be hacked or compromised. The Qt Company performs cyber-security testing and validation routinely - especially for QtNetwork. It publishes security fixes nearly monthly with the Qt bug fix releases. Locking down a device (that is, using Qt Commercial) makes it harder for attackers to compromise a device.
Qt Safe Renderer comprises 3000 lines of code. It is certified to the highest class of IEC 62304. The uncertified main UI runs in the unsafe world on a standard OS. The certified emergency UI and Qt Safe Renderer run in the safe world on a certified OS like QNX or INTEGRITY. The two worlds are coordinated by a certified hypervisor (see here for more details). When the main UI crashes, the safe UI will still be shown on the screen. Nurses and doctors will always see the important information - no matter whether the main system is just rebooting or not. This is what the certification must guarantee.
Roger was spot-on about using Qt under LGPLv3 on medical devices. The FDA and the EU don't care about about whether you use Qt under LGPLv3, Commercial or any other license on a medical device. They only care about risks and their mitigation.
Licensing Overview by Thilak Ramanna, Sales Director for India, Australia and New Zealand, The Qt Company.
In his talk, Thilak spreads lies, untruths and half truths about using Qt under LGPLv3 in best Trump fashion. Here are some of the worst examples.
The medtech industry "does not allow LGPL". Lie! Let me repeat what Thilak's colleague Roger Mazzella said in the previous talk. The certification authorities don't care about the license used. They only care about risks.
"It is not allowed to [...] voiding the warranty" when using Qt under LGPLv3. Lie! This is refuted in Section 6. Conveying Non-Source Forms of the GPLv3: "The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed."
"Static linking is not OK under LGPLv3". Untrue! Static linking is covered by Paragraph 4d0 of the LGPLv3. You must provide everything such that users can statically link the application against a modified Qt version. This would most likely include the object files of the application, which can be stripped off the debug symbols.
There is no way to publish Qt apps on iOS store with Qt (L)GPL. Untrue! As LGPLv3 allows static linking (see previous item), it is no problem to publish apps using Qt under LGPLv3 in the app store. Apple lifted the ban of LGPL libraries long ago.
"Locking of devices is prohibited by LGPLv3". Not true! Manufacturers of B2B devices need not provide the information to install a modified Qt version on the device. So, they can essentially lock down or tivoise the device. In contrast, manufacturers of B2C devices must provide this information.
The Qt Quick Compiler is commercial only (see slide 29). No true! The Qt Quick Compiler has been available under GPLv3 since Qt 5.12. You can safely use it to compile QML files for an application that uses Qt under LGPLv3.
I have witnessed quite a few Qt sales people using this FUD strategy in meetings with potential customers. I have heard about more such incidents from trustworthy people. Thanks to Thilak's talk this FUD strategy is now on public record. Regarding your customers as stupid is not a winning strategy for The Qt Company.