I must apologize in advance. Yes, I’ve had to do quite a few things in the embedded/semi-embedded world with Qt on Linux. Yes, this increasingly means cross compiling Qt applications to run in various configurations on the Raspberry Pi. These posts will be sporadic and they will not be a soup to nuts tutorial on how to go from a box showing up in the mail to having a real usable embedded application on the Pi.
I’m kicking around the idea of another book in “The Minimum You Need to Know” series tentatively titled “The Minimum You Need to Know About Qt and the Raspberry Pi.” These posts are part of the research for what will and won’t work. Normally all of this research would be squirreled away and archived off onto LS-120 Super Floppies. Don’t laugh. Those drives may be old, but they are perfectly sized to store working content AND they are highly secure. Seriously. Just how many people do you know who own anything that can read them? People also laugh when they see pictures of the nuclear missile control rooms using 8 inch floppies, but, think about it. Even if you stole one with super secret whatever on it, how would you know? While I’m older than dirt, even I came into IT about the time 8 inch floppies were phased out. Stealing one would let you feel like the main villain in “The Book of Eli.” If that statement makes no sense to you, rent the movie.
The scope of this project will be simple yet meaningful. It really will cover the minimums you need to know because it is a lot more than most people think. I’m not going to go into detail about Qt as there are many fine books and Web sites covering that. We are going to develop several applications with it for the Raspberry Pi.
First will be a simple keypad application which reads and writes via the serial port. Initially we will compile and run this under the Raspian desktop, then we will learn how to compile and run it from the command line without X or a desktop running. I might even go into debugging this application remotely.
Next we will develop an application which receives data via the serial port then writes/updates a local SQLite database. We will also need to create an application to run on a Linux desktop which feeds data to our Pi.
Why serial?
Because if you are developing an application to use in an embedded world 90% of the time you will need serial communications. It is the oldest and most trusted industrial communications medium. The definition of our 25-pin serial connection occurred long before computers were built. If you can find a first edition of “C Programmer’s Guide to Serial Communications” it has a great history of serial communications in it.
Yes, many embedded systems are mistakenly connecting to networks and the Internet. No matter how you justify the increase in data speed and functionality, exposing your product to the hacks and horrors of the connected world is irresponsible. Thankfully there are ample sites showing you how to do sloppy TCP/IP programming on a default configured OS which doesn’t even have the basic attack ports turned off so I don’t need to help you there.
If you are going to connect your product to the Internet or a network then you must roll your own Linux build via Bitbake or some other means stripping out all network services your application does not directly use. Coming up with such a build is a long and painful process. By that I mean one person full time with a massive compilation machine for just over a year. The spaghetti octopus of build recipes is not for the faint of heart. All of this “share and re-use” being foisted onto the 12 year old kids doing much of the world’s Linux development leads to one module having hundreds, perhaps thousands of seemingly unrelated dependencies all because someone decided to use one function out of one library to do one tiny thing without considering the cesspit of dependencies that came along with it.
No, we will not be covering how to Bitbake a secure and minimal Linux. Someone else can write that book. The Linux community in general needs to address this issue, but it won’t. It will keep having 12 year olds do much of the development creating and ever going dependency list while the old men running the distros continue to grub for support contract dollars from major corporations.
