We must figure out why a Yocto package doesn’t work as expected. So, we must tweak the source code a bit here and there, cross-build the package for our ARM-based embedded Linux system and install some shared libraries from the package on the embedded Linux system. Of course, we want short turnaround times to try out our changes quickly. The bitbake task devshell will save our day.
Read More »Building Yocto Packages Manually with devshell
In the beginning, the application shows the Main Screen. When the user clicks on the Open button, the application will show a second screen. The second screen creates a C++ model when opened and destroys this model when closed.
As zealous Qt developers, we use the pimpl idiom to hide private declarations from its clients. Hence, we move the write and read functions of Qt properties to the implementation class in the source file. When the value of the property changes, the write function emits a signal of the interface class.
When the signal emission occurs during the construction or destruction of the interface class, we end up in the land of undefined behaviour. At the point of the signal emission, the interface object does not exist yet or does not exist any more. A real-life application will most likely crash – right a way if we are lucky or much later if Old Murphy has his way.
Read More »Emitting Signals during Construction or Destruction
When the driver turns off the ignition in a vehicle, display computers like terminals in harvesters or infotainment systems in cars should be notified. The display computers should save important data and shut down orderly.
When the display computer runs on Linux, it learns the status of the ignition by monitoring the GPIO for clamp 15. Linux writes the value of the GPIO to a special file in the sys filesystem. On one of my display computers, clamp15 is mapped to the special file /sys/class/gpio/gpio72/value. When the ignition is on, this file contains the string “1”. When off, this file contains “0”. The number of GPIO (here: 72) varies from display computer to display computer.
On the Linux command line, we get the value of clamp 15 with this command:
$ cat /sys/class/gpio/gpio72/value 1
The command returns “0” when the ignition is off and “1” when it is on.
How can a Qt application monitor the status of the GPIO clamp 15 such that it can shut down orderly when the driver turns off the ignition?
Read More »Monitoring Sys Files with QFileSystemWatcher
Correction: In the original post, I stated that ownership is transferred from C++ to QML by READ functions of Q_PROPERTYs. This is wrong. Ownership is only transferred by Q_INVOKABLE functions and slots, which return a QObject pointer. I corrected my post and my code example. Now, the simple code example crashes as desired. Many thanks to Richard and Simon for pointing out my mistake.
I recently spent three days on a customer project to figure out why my QML application crashed with a segmentation fault. The crash happened after a long sequence of interactions, which was hard to reproduce. I finally managed to reproduce the crash reliably after going through the same six-step interaction four times.
After many hours of debugging and scrutinising my code, I had an epiphany about the stack trace leading to the crash. The stack trace originated from deep inside the QML engine and ended in calling the destructor of a C++ object, which was still in use on the C++ side. The trace never touched any of the application’s C++ code in between.
So far, I had only asked myself the question: Where in my C++ code do I corrupt the memory? After my little epiphany, I changed my question: Why does the QML engine delete a C++ object still in use? What do I overlook in the interaction between QML and C++?
Read More »QML Engine Deletes C++ Objects Still In Use
My program received messages from a network as an array of bytes. The sender of the messages encoded integers in Big Endian format. So, the hex number 0x1540 arrived in the sequence [0x15, 0x40]. I wrote the following function, which converts such a byte array of at most four bytes into a 32-bit unsigned integer. The function converts the sequence [0x15, 0x40] into the hex number 0x1540.
quint32 byteArrayToUint32(const QByteArray &bytes)
{
auto count = bytes.size();
if (count == 0 || count > 4) {
return 0;
}
quint32 number = 0U;
for (int i = 0; i < count; ++i) {
auto b = static_cast<quint32>(bytes[count - 1 - i]);
number += static_cast<quint32>(b << (8 * i));
}
return number;
}
Of course, I also wrote a unit test.
void TestByteArrayToUint32::testByteArrayToUint32()
{
QCOMPARE(byteArrayToUint32(QByteArray::fromHex("9020562f")), 0x9020562fU);
QCOMPARE(byteArrayToUint32(QByteArray::fromHex("314922")), 0x314922U);
QCOMPARE(byteArrayToUint32(QByteArray::fromHex("1540")), 0x1540U);
QCOMPARE(byteArrayToUint32(QByteArray::fromHex("38")), 0x38U);
QCOMPARE(byteArrayToUint32(QByteArray::fromHex("")), 0x0U);
QCOMPARE(byteArrayToUint32(QByteArray::fromHex("559020562f")), 0x0U);
}
All QCOMPARE checks passed. All seemed fine. After using my function for a (short) while, a test didn't want to pass. I tracked the problem down to my function. Converting the byte array [0x01, 0x80] yielded the result 0x80.
Can you spot the bug in my code - and in my test?
Read More »Converting a QByteArray into an Unsigned Integer
Over the last two years, agricultural OEMs have been in a rush to get data from their machines to their cloud servers. Claas uses Proemion’s connectivity solution. Agco, Grimme, Krone and a few others bet on AgriRouter running on SAP’s cloud servers. Holmer seems to favour Bosch’s IoT suite. All these solutions have one thing in common: They transfer little data, typically less than 50 data points per second. They top out at 100 data points. They are good for task or order management, asset tracking, fleet management, monitoring of machine health and remote diagnosis.
At least some of these companies seem to think that these connectivity solutions will help them with driver-less or autonomous farming like harvesting, seeding, spraying or fertilising. The wishful thinking would go like this.
The farm machines transfer data to the cloud. The data is used to train machine learning algorithms on extremely powerful compute servers. The model, the result of the learning process, automagically detects whether grains are dirty, maize leaves are dry or the heads of sugar beets are chopped off. Typically, this model runs in the cloud as well, because it requires more compute power than is available on the farm machine or because it adapts to new conditions and self-optimises by continuous learning. This is the way how voice assistants like Alexa and Siri understand spoken language or how medical software recognises cancer cells in MRT scans.
This approach does not work for farm machines. Here is why and what we can do about it.
Read More »Connectivity Solutions Will Not Help with Autonomous Farming