Embedded Android? Call me, maybe
Welcome to the inaugural post to my new little home on the Internet. I have to admit, I was pretty excited when UBM offered me the chance to write a blog about "anything you like". One can imagine my disappointment, then, when their lawyers followed up with some fine print narrowing the range of subject matter to things that were, "legal, ethical, unlikely to cause physical and/or emotional distress in the reader, and within the author's recognized area of expertise".
Honestly, that doesn't leave us much to talk about. But with ESC/EELive! 2014 just around the corner, and my being contractually obligated to bring something to teach there, I'm thinking a lot about Android lately. A LOT about Android, actually, and I'm thinking that you probably should too.
A match made in [redacted]
What's not to love about Android? It's an application framework built to run upon the Linux kernel, and was designed from the beginning to be secure, easy to program, and power-efficient on mobile devices with touch screens and modest computational horsepower. And since most of Android is available under licenses that allow for commercial redistribution, you could be tailoring it for one of your new devices after just a few mouse clicks to download the source code.
Just like I am. As I type this, another window on my workstation is churning out comforting streams of compiler messages as the Android framework's build system works its way through itself. In another hour or two, I should have disk images ready for my device.
It's a real pity that it isn't THAT simple, however. In fact, after working with Android for almost four years now, I'm convinced that its excellence for embedded work comes at a pretty heavy price. And if you aren't prepared to pay it, then the experience is like getting so excited to attend a really, really cool conference (hint, hint), that you forget to buy your all-access pass until they're all gone (hint, hint). And I'd hate to see that happen to you (hint, hint).
Divide, or be conquered
Here are a few of the things you can look forward to on your first embedded Android project. First, Android's design makes it impossible to implement anything involving real-time operation within the Android framework itself. Don't bother trying: it simply can't be done. Why? Because the implementation decisions that make real-time operation possible also work against things like power and performance efficiency.
This would seem to be a pretty big problem, given the number of computerized devices out there that need to keep up with the real world. In cell phones, developers work around this problem by running time-critical code in dedicated coprocessors, which are almost always available anyway due to the workloads required to implement RF protocols. That code then communicates with Android using network sockets, USB, or other high-level abstractions, many built upon Linux kernel APIs designed specifically for that purpose.
That's precisely the model you should follow if you want to use Android successfully in your own embedded system: put the stuff that needs real-time scheduling OUTSIDE of Android, either in an external microcontroller, or in a standalone user program or device driver. Run that code on one of the Linux kernel's built-in, real-time schedulers, and then connect it to your non-real-time Android programs through a network socket or similar API.
"Wait a minute, ... Linux has real-time schedulers?!", I hear you ask. Indeed it does! Two of them, in fact, and they have been available in every mainstream Linux kernel since before most people knew Linux existed. They don't deliver the same precision you find in RTOS kernels designed specifically for real-time behavior, but nowadays the difference is small enough that it often just doesn't matter. I plan to make these schedulers the subject of a future article or two, because they offer plenty to talk about.