Episode 17: Burkhard on Qt Embedded Systems

May 03, 2021

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

You may have been wondering, why you didn’t receive the April issue of my newsletter last Friday - on the last day of the month. I simply was too busy with my projects. In the past, I compensated this with late-evening shifts.

Now, I decided to send out my newsletter on the first Monday of each month. I’ll post a preview with the contents on Twitter and LinkedIn on the Friday before. When push comes to shove, I have the weekend to write the newsletter.

Enjoy reading and stay safe - Burkhard 💜

My Blog Posts

Using Qt 5.15 and Qt 6 under LGPLv3

The predecessor post Using Qt 5.6 and Later under LGPL is the third-most read post on my website. It looks like the new post will catch up quickly. Most comments were positive. For example: “Concise and clear. I think this is the best article I’ve ever read about Qt Licensing.” (Homero J. Oria-Aguilera on LinkedIn).

There was one notable exception. I received a fairly grumpy email from a senior manager of The Qt Company. First, he challenges the factual correctness of the cost comparison between Qt LGPLv3 and Qt Commercial. Second, he regards the published price estimates as an unfair advantage for the competitors of The Qt Company. I think I touched a nerve.

I used nearly the same cost comparison to convince a home-appliance maker to use Qt Commercial instead of a web framework like Angular or ReactNative. Using the web frameworks would have cost the home-appliance maker several million dollars more than using Qt Commercial.

My cost comparison earned The Qt Company a million-dollar license deal. It earned me a white paper, a webinar organised by The Qt Company and a talk at Qt World Summit 2017 (see my overview post). It triggered the Forrester study Total Economic Impact of Qt Embedded Software Development and a calculator to estimate the return on investment when using Qt Commercial.

My cost comparison is pretty effective in fending off the competition - even the free competition. And, it was very much appreciated by The Qt Company. Comparing Qt Commercial and Qt LGPLv3 poses several tricky problems for The Qt Company.

Making Qt LGPLv3 look bad also makes Qt Commercial look bad, as Qt LGPLv3 is the foundation of Qt Commercial.
The anti-tivoisation clause only applies to B2C products and not to B2B products.
45 Qt modules are available under LGPLv3, 7 under market-place license and 7 under commercial license (part of Qt for Device Creation).
Qt LGPLv3 is good enough for many Qt embedded systems.
Convincing potential customers that they’ll get a big return on their investment in Qt Commercial is a difficult sale.

Given this tricky situation, quite a few Qt sales people resort to a FUD strategy telling potential customers how extremely dangerous LGPLv3 is. Let me quote Thilak Ramanna, Sales Director of India, Australia and New Zealand, The Qt Company, from his talk at Qt Virtual TechCon 2020 (see also (see Episode 6 of my newsletter): the medtech industry "does not allow LGPL"; "It is not allowed to [...] voiding the warranty" when using Qt LPGLv3; "Locking of devices is prohibited by LGPLv3”. Interestingly, the video “Licensing Overview” has been removed from the conference talks.

Potential and paying customers will eventually figure out that these statements are all wrong. Guess what they will do. They will take the first opportunity to move to Qt LGPLv3 or ditch Qt altogether. This is not a winning sales strategy.

More than 75% (!!!) of the Qt modules are available under LGPLv3. Hence, Qt LGPLv3 is good enough for many, if not most projects. Qt sales people must show potential customers how the value gained from using Qt Commercial is a lot more than the costs for Qt Commercial. This is a much more difficult sale (a.k.a. a complex sale) than selling software licenses.

With the marketplace license, the Qt Company has introduced a way to earn some money from Qt LGPLv3 users. Paying 49 USD for Qt MQTT or 199 USD for Qt Charts per year is a no-brainer for companies. The prices are very fair.

I’d also suggest to change the license of some more add-on modules from LGPLv3 to Marketplace. Good candidates would be Bluetooth, Gamepad, Location, NFC, Positioning, Purchasing, Sensors, SerialBus, SerialPort, Speech, WebChannel, WebEngine, WebSockets and WebView.

The license agreement between The KDE Free Qt Foundation and The Qt Company makes a license change close to impossible. Section 4.6 stipulates that add-on modules must keep their license in future Qt versions. Once an add-on module has been released under LGPLv3, it will be under LGPLv3 forever.

Well, almost forever. Section 4.8 allows The Qt Company to change the licensing of the add-on modules from time to time, if three of the four board members agree. That’s a big if, as two board members are from KDE and two from The Qt Company. Such changes would typically take place with the introduction of a major release - such as Qt 6. I can think of a few good arguments for The Qt Company.

Nokia introduced Qt LGPLv3, because they considered Qt license income as a rounding error. Nokia needed to get Qt to as many people as possible - and LGPL was perfect for this purpose. But the situation has changed.
Qt LGPL and the contractual obligation to keep add-on modules under LGPLv3 almost forever make it hard for The Qt Company to differentiate Qt Commercial from Qt LGPLv3. Making a profit becomes harder.
Putting a good deal of the add-on modules under the Marketplace license and GPLv3 but not LGPLv3 is a good compromise. GPLv3 and not LGPLv3 is the primary license for KDE (see Section 4.3).
As the Qt community we should have a vested interest in The Qt Company being profitable. This will make sure that we can enjoy the goodness of Qt for many years to come.

Such a change would cause an uproar. But from whom? From non-paying customers. Most of them would quickly figure out that Qt LGPLv3 for the essential modules plus the Marketplace license for some add-on modules is a fantastic deal.

As a consultant and architect, I would do what I have always done. I would educate my customers about their options and the costs for each option: Qt LGPLv3, Qt LGPLv3 plus Marketplace and Qt Commercial. Qt sales people are always welcome in the decision process. They should be able to answer the question from my cost comparison though: How can Qt Commercial add an additional value of 100,000 USD to a project? It is their job to sell Qt not mine.

In the end, customers decide based on the presented facts. No matter how they decide, I have no financial gain. And that’s exactly what my customers appreciate.

My Thoughts on Effective Decision Making

Ineffective decision making can quickly turn a risky but feasible project into a death-march project. There is always too much to do on a risky project. Time is at a premium. Spending time on the right things and reducing the scope are paramount to navigate risky projects successfully.

Here are some signs of ineffective decision making.

The project managers wants to be involved in every technical decision no matter how small or unimportant.
Multiple people are responsible for a decision.
Every problem, issue or question is discussed in gory detail no matter how severe, important or urgent.
Decisions are made by wearing down the other parties. Discussions tend to be acid, disrespectful and non-constructive.
Meetings don’t lead to any decisions. Decisions are postponed to follow-up meetings.
Done decisions are revisited over and over again. Changing these decisions leads to reimplementation of working and tested software.

Project managers should mostly stay out of technical discussions and decisions. They should only get involved, if the effort estimates for two options differ significantly. A good practice in Scrum’s planning poker is to discuss the estimate only if it is two steps apart, say, 2pt and 5pt for a Fibonacci scale.

If multiple people are responsible for a decision, decisions will take a lot longer or will not be taken at all. People dig in on their positions. Discussions tend to become rude and non-constructive. Decisions become a matter of losing face and ego.

On project start, the team should agree on some guidelines how to ensure respectful and constructive discussions. These guidelines for respectful and constructive code review feedback are a good starting point. After all, code reviews are discussions that will lead to decisions how to improve code.

The usual approach is to find a compromise. The result is often similar to this UI design joke. One designer favours a horizontal toolbar, another a vertical toolbar. Both have good arguments. As neither designer wants to back down, the project leader suggests a diagonal toolbar as a compromise.

Compromises tend to bring out the worst of multiple solutions. In this case, letting the user configure whether to use a vertical or horizontal toolbar may be the best solution. Both-and solutions combining the good parts of multiple options are often a good choice.

I have seen project managers that almost compulsively go for a compromise. They are extremely consensus-driven. Project members use this weakness to derail discussions and to delay decisions. They hope for the other party to say: “Oh for god’s sake, let’s do it your way.” Both these members and the managers hurt the project.

Project managers should stay out of such technical discussions and delegate the decision making to a single person. A good candidate is the person, who will implement the feature, who has implemented other features of the same epic or who has proven expertise in this area.

For each decision, team members should answer the following questions at least for themselves.

What is the current and future impact of a decision? What are the immediate and follow-up efforts/costs of this decision? 
How easy or difficult is it to change this decision in 1 month, 3 months, 6 months or 1 year? How likely is a change? 
What are the costs if we don’t take the decision now? What other decisions would make this decision easier? 
How severe, important or urgent is a decision?

Let me give you an example. Bob develops the operator terminal for a machine. Ken develops the machine control. The terminal and the machine communicate over a proprietary stream-oriented protocol. Bob has already implemented large parts of the protocol and tested it with a machine simulator. Ken hasn’t started with the protocol yet.

Stream-oriented protocols need a terminator to mark the end of a message. The terminator must be escaped inside the message. Bob escapes the terminator in his implementation in one way, Ken would prefer it differently.

By answering the questions, Ken would find out that the way of escaping is a matter of taste and hence unimportant. As he hasn’t implemented anything yet, he wouldn’t incur any extra costs during implementation but Bob would. If Bob’s way of escaping turns out to be a serious problem later, it’s easy to change: just a couple of hours effort. So, Ken should not even raise the issue or at least back down quickly.

Pretty much out of the blue, Ken wants to change the protocol completely: different message format, polling instead of event-driven, assembly of long messages and more. For Bob, this would mean nearly a complete reimplementation. He estimates 2 weeks of extra work. Some of Ken’s suggestions are good and Bob is happy to implement them. The cost would be 2 days. Here are different scenarios how this could play out.

Ken is a reasonable person and goes through the questions above. He agrees that the 2-day changes will make a later change very unlikely and that spending 2 weeks would increase the risk of failure for the project.
Bob is responsible for the decision, as he has done all the work so far, and decides to go for the 2-day change. Ken doesn’t agree with Bob’s decision but commits. Ken fully supports Bob with the changes.
Ken is responsible for the decision, as he has been longer on the project, and decides to go for the 2-week change. Bob disagrees with the decision and escalates it to the project manager, because 8 days of extra work are a significant time and cost factor. The project manager must decide. Either Ken or Bob will have to answer with a very powerful and pragmatic “I disagree and commit”.
The consensus-obsessed project manager doesn’t decide, because there is no agreement between Bob and Ken. The decision lingers around. Ken implements his version of the protocol. Terminal and machine don’t understand each other when integrated. The project is delayed. Bob quits.

The last scenario happens more often than you may think. Rational decision making is rare. Emotions play an important role. So, define some guidelines for decision making, use “I disagree and commit” frequently, decide in a timely and pragmatic way and don’t be afraid to change your decisions once you know more.

News

The Qt Company Acquires Froglogic

The Qt Company acquired froglogic, the maker of Squish and Coco. The press release gives the following reason: “The acquisition will bring froglogic’s market-leading test automation tools into the Qt product portfolio […] extending the offering to encompass the entire software development process from design, development and deployment and now quality assurance.”

This acquisition fits nicely in The Qt Company’s strategy to improve their tooling. This strategy started with integrating Nvidia’s 3D studio into Qt Creator. This became Qt Design Studio for 2D and 3D graphics. You can buy bridges from Photoshop, Sketch and Figma on Qt Marketplace. The Qt Dev/Des Days this year will showcase the tooling for better collaboration between designers and developers.

Integrating Squish and Coco into Qt Creator will similarly bring together developers and testers. Integrating code coverage (Coco) with unit testing (Qt Test) and having a single tool from unit to system testing would be a boon.

By the way, froglogic is the fourth Qt consultancy that got acquired in the last three years. e-GITS was acquired by Garz & Fricke, Basyskom by the UX Gruppe and Develer by Comelz (a manufacturer of leather and textile cutting machines). The Qt market seems to consolidate.

Reading

The 2021 Embedded Product Planning and Requirements Guide by The Qt Company

This 42-page free e-book tries to “reduce the effort and risk in building your next [IoT or embedded] project”. The guide stays in the vague and general, as it lumps together all the different application domains of embedded systems. The application domain rules out many hardware and software choices right away and makes many choices fairly obvious.

The SoC/CPU table (p. 31) lists the AMD Ryzen V1807B, Intel Celeron J3455, NXP i.MX8 QuadMax, Renesas R-CAR H3 and TI AM5728. For each SoC, the table gives the RAM size, peripherals, the architecture, use cases, power draw (1-5 stars), longevity (1-5 stars) and unique features.

How does this table help you decide which SoC is best suited, say, for an operator terminal of a harvester, packaging machine, industrial robot or an infotainment system? - Well, it doesn’t because it lacks important information like price and operating conditions, because the list of peripherals is incomplete and because a “large” number of use cases or a 3-star longevity are non-telling.

The following criteria would be a lot more helpful in selecting a SoC for such an operator terminal:

What is the expected life time of the SoC? 10 or 15 years?
In which temperature range does the SoC operate? Commercial (0 to +70 °C), Industrial (-20 to +85 °C) or Automotive (-40 to +85 °C)?
What is the price of the SoC at the required volume? What is the BoM of the terminal?
Which peripherals with which specifications are needed (CAN, RS232/485, UART, I2C, I2S, LVDS, HDMI, DP, MIPI, etc.)?
Will you buy a ready-made terminal or assemble a custom one yourself?

Such an operator terminal will almost always run embedded Linux custom-built with Yocto these days. Real-time and safe-critical jobs are often handled by an embedded system on the machine, with which the terminal communicates. For example, the ECUs take care of the real-time and safety-critical jobs in a harvester. If the terminal must handle such jobs, you’d use a hybrid SoC and run these jobs bare-metal or in an RTOS on the microcontroller.

Using a web framework for the terminal is rarely a good choice: too resource-hungry, too far away from hardware, too short life expectancy, etc. Python may become interesting with Qt 6, once Yocto builds Qt for Python properly. The build is broken in Qt 5. So, the programming language is QML for the GUI part of an application and Qt/C++ for the rest.

Although the guide never mentions Qt except on the last page, it’s far away from being “an impartial guide”. It smells of Qt sales material in every line. I don’t mind reading a sales pitch, but please say so, make it a good pitch and make it worth my time. This guide is not worth reading.

Is Qt Right for Your Project and How Can You Tell? by KDAB

KDAB gives some guidance how to choose the right software stack for a project. The choice is a strategic decision with with long-term consequences and depends on many criteria.

Existing code base. Changing to a new software stack makes good sense, if you have a lot of untested, undocumented and hard-to-read legacy code. During reimplementation make sure that you don’t lose the business knowledge hidden in the legacy code.

Skills and availability. Qt makes it easier to find good people, as Qt “tends to tame the complexity of C++” and as QML “, due to its similarities to Javascript, makes user interface development dramatically simpler and closer to web-based development”. In the end, the search for people boils down to this: “[…] excellent people are rare regardless of the language.”

Platform and silicon. As a cross-platform framework, Qt provides a good UI on all platforms, but not necessarily the best on a specific platform. If you target mobile, Flutter or ReactNative should be the preferred choice. If you target desktop and mobile, Electron should be. Web frameworks are not a good choice for embedded. Qt is a very good choice for embedded systems running on microprocessors, whereas Crank Storyboard may be a better choice for microcontrollers.

User interface requirements. If your UI requires extensive data visualisation with graphs, R, Julia and Python are a good option. Qt does a good and reliable job in all GUI applications. Qt really shines with “3D [image] manipulation [, …] scientific applications, high-throughput measurement systems, or real-time data collection”. Web frameworks will struggle with this kind of applications.

Remote access. Operator control machines remotely from their offices. They perform remote diagnostics or remote support. The standard solution is a web app running in a browser. This often means substantial duplicate work, if a Qt application runs on an operator terminal on site. Then, WebGL or VNC could be used to transfer the screen contents to the remote office. WebAssembly could be used to run the Qt application unchanged in the browser.

Vertical markets. The vertical market pretty much determines the software stack. If you choose an uncommon stack, you’ll have problems finding libraries, finding good people and getting the stack through certifications. Ignoring the characteristics of a vertical market is my main critique point with the Embedded Product Planning and Requirements Guide reviewed in the previous item.

Tool interest and longevity. Do not choose the latest, greatest and hottest software stack, which is especially true for JavaScript frameworks. Choose a stack with a big developer community. And 💯 👉: “Finding tools that can easily integrate unit testing into the development process can help maintainability and should be a priority for modern development.”

Strategic considerations. All stakeholders including developers, architects, managers, HR and purchasers should be included in the choice of a software stack. They all bring their unique perspective to the table.

Qt Creator 4.15: New CMake Features by Cristian Adam (The Qt Company)

Cristian and his colleagues have been busy improving the QtCreator-CMake interface. As I have spent considerable time in making the two work together (see my latest post about the topic), I deeply appreciate these improvements - and two especially 🙏

Re-configure with initial parameters. The CMake build settings got a button Re-configure with initial parameters that performs a Clear CMake and runs CMake the values of the “Initial CMake parameters” list. This list gets its values from 4 or 5 different files (see the diagram in the post). I never really knew when to run Clear CMake, when to remove CMakeCache.txt, when to remove which parts from CMakeLists.txt or from my local profiles.xml. The new button just does the right thing.

Copy and Batch Edit CMake variables. You can select any set of CMake variables from the CMake build settings, copy them in the clip board and paste them in the editor that opens when you click on the button Batch Edit…You can then edit the variables in the editor, add new variables or remove existing ones. My favourite use case will be to send my CMake variable settings to other team members so that they can paste them into the editor and apply them. CMake settings lost in translation will be a thing of the past.

Signal/Slot Connection Throttlers by Giuseppe D’Angelo (KDAB)

The operator terminal of a harvester receives 1100 CAN messages per second from the ECUs (see my talk A Deep Dive into QtCanBus). Some messages like the engine speed are sent 100 times per second. That’s faster than the refresh rate of the display.

If the classes receiving the messages simply forwarded the messages to the home screen, the GUI would freeze. Users can recognise 4-5 changes per second. So, it makes sense to throttle the incoming signals. The frequency of the outgoing signals is lower than the frequency of the incoming signals.

Enter the class KDSignalThrottler from KDAB’s MIT-licensed KDToolBox. The original connection between the signal Sender::incoming and the signal or slot Receiver::outgoing is split up into two connections. Sender::incoming is connected to the slot KDSignalThrottler::throttle and the signal KDSignalThrottle::triggered to Receiver::outgoing.

The throttler calls Receiver::outgoing only once every X milliseconds. A trailing throttler waits for X ms and forwards the last incoming signal. A leading throttler forwards an incoming signal immediately and then waits for X ms until it forwards the next one.

*|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|*

Better Built By Burkhard

Discussion about this post