Showing posts from 2016

Dragonboard 410c post install tasks

Now that we have the software all installed, let's actually get mythtv running by setting up our environment: First mythtv backend requires it's own user so let's add it: sudo useradd --system mythtv Now we need to tell mysql about time zones: mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql It is safe to ignore the warnings from not being able to load some zone info tabs. Mythbackend will create our database and upgrade the previous mythconverg db schema to the latest version so let's run it: mythbackend Note that it will auto shutdown and any further attempt to run it will end in an error saying no capture cards are defined in the database. Next it's time for some fun gui ease.  Either connect a keyboard / mouse /monitor and run mythtv-setup from the command line or run it via a remote x screen by clever use of ssh (i.e. something like this: ssh -X linaro@ /usr/bin/mythtv-setup). Setup your backend for either your cap

Adding plugins to our Dragonboard mythtv

Welcome to the plugin fun.  This is entirely optional, so feel free to skip it if you don't desire to see all that your new DVR has to offer! Let's start back from the /media/sdcard/mythtv/mythplugins directory. cd /media/sdcard/mythtv/mythplugins Let's run a ./configure command and see what will build and what wont: ./configure The output will help tell you what is missing in your library dependencies for each plugin you want, install what's missing with apt-get install.  Keep at it till you get something you're happy with.  This is what my configure looks like: Configuration settings:         qmake          /usr/bin/qmake         MythArchive    plugin will be built         MythBrowser    plugin will be built         MythGallery    plugin will not be built         MythGame       plugin will be built         MythMusic      plugin will be built         MythNetvision  plugin will be built         MythNews       plugin will be built         MythW

Building a low power mythtv dvr

I recently decided that I needed a better DVR, (Digital Video Recorder) with the purpose of getting better features, use less electricity to do it and provide a platform that can launch all sorts of other projects (home security, home automation, and home AI (Alexa or google assistant style system). Sounds great right?  Well let's get started: The first step in all this is to look at what's already out there that does the work of a DVR to get a minimum viable solution.  MythTV ( is a stable wonderful system with all sorts of great features.  I've used it in the past with setting up similar projects that involved a desktop tower sized computer box.  However, that's years ago, let's see if we can't use our embedded knowledge to make this more compact, less noisy, and use much less power, without sacrificing features. Other projects have successfully used a raspberry pi  (rpi), however, as even the official blog notes , this backend pract

Practical Project 1: Magic Mirror Hardware

Returning again to the Magic Mirror, it's time to add more hardware functionality.  Let's give the mirror a camera and a microphone so we can use gestures and voice for input to better control the magic mirror. First some notes about soldering.  What is solder?  Solder is conductive metal that establishes a joint between two electrical devices whereby one gives electrons the ability to travel through the path of least resistance being a path through the solder.  Solder, when hot, turns into a liquid metal that is easy to work with and turns back into solid metal as it quickly cools down.  You can pick up solder along with a soldering station from your local electronics store. Note that Solder does create toxic fumes and should only be worked with in a well ventilated environment.  To create a joint, heat the pad and the wire one wishes to attach to the pad, then introduce the solder to the pad.  The heat will draw the solder into a liquid form on the pad and secure a join

Vulkan Part 2

This year's Google IO had a lot of wonderful gems for Embedded Development including a release of the official Vulkan support libraries.  Those libraries require Android N and only on one of three specific devices: Nexus 6p Nexus 5x Nexus Player In order to target the larger market, we're going to continue using Qualcomm's released Vulkan API and enable targeting any Qualcomm Snapdragon 820 or 821 device such as the very popular Samsung Note 5 and Samsung S7.  I'll also make the important note that both of these devices are among the current generation able to work in the Oculus Gear VR device.  That important note opens the intriguing possibility of doing Virtual Reality work in Vulkan to give much needed performance improvements. Now that we have our motivation intact for using Qualcomm's Vulkan API, there is something very useful about Google's Vulkan effort that we can take advantage of the SPIR-V compiler (shaderc) included in the NDK in our projec

Practical Project 2: Giving sight to the blind appetizer

Practical Project #2 Giving sight to the blind In this project, I’m going to take a project that I’ve already done and already works and transition it to a different platform in a more generic way and take you fine readers along for the ride.  A while ago, I worked with Google on their Giving Through Glass project and one of the projects I worked on was to give sight to the blind.  I worked with Classroom Champions and an amazing Paralympic athlete named Lex.  Lex is a blind long jumper who lives and trains in San Diego.  I’ve worked with him for the last year or so on creating an application for Google Glass that would allow him to hear the world around him via an app that translates the images from the camera into sin wave sounds. As cool as that project is, there’s plenty of people out there that are similarly blind, like Lex.  And it is now impossible to get the same hardware as Google is no longer selling consumer Glass devices.  So I thought it time to bring this project t

Practical Project 1: Magic Mirror Software

It’s finally time to return to the first practical project “Magic Mirror.”  We need to start addressing the software to make it run and do things that would be cool, useful or at the very least give us a way to start being creative with it from the software side. When we last talked about the “Magic Mirror,” we had our 410c sitting pretty in a custom framed case with a 2 way mirror completing the enclosure with Linux happily running on our network.  So many happy memories getting to this point, continuing is a must!  So in this article, let’s start by talking about trying to get something onscreen.  We want to take up the whole screen.  The easiest way to do that is to launch a browser and use it to browse to a custom server running whatever we want to display on screen.  To do that, we can simply setup what’s called a LAMP (Linux Apache Mysql PHP) stack on our 410c sitting in the mirror.  Then, you’d want to set the servers to launch automatically when the mirror starts up; and fin

Vulkan part 1

In my faculty as a Developer Advocate for Qualcomm, I’ve gotten the awesome chance of working with Vulkan for Android for a few months now.  Being able to work with such a new technology this closely is an awesome chance and I’m so excited about it I felt the need to create an example program and share it with the world via this blog. Let’s start by talking a bit about what this whole Vulkan thing is and why it is important.  Back at the beginning of the graphics world, hackers found ways of creating cursors of ASCII art images decorated by text.  There were no GUI or concept of a window or any other form of User interface beyond a keyboard.  To be honest that level of technology is perfectly serviceable to the business world whose needs range from a text editor to a spreadsheet.  Thus the interest in creating more was chiefly a pursuit by “hackers” a term truly defined as those that would tinker in their free time, making things like games and creatively pursuing the very limits of

Continuous Integration (CI) with Jenkins

Continuous Integration is the idea of running a full build every time someone on a team publishes new changes to source control (such as git).  The idea of setting it up allows for greater visibility into changes, by finding which build exhibits problems and which doesn't as every build happens immediately following a change in source.  This process allows QA to quickly and easily track the life of a bug. By marrying the CI server with other tasks such as Unit tests to check on the system, we get a higher level of confidence that the code under test is stable.  A competent CI system can run several tasks that are often viewed as a drudgery by developers to try and run at regular intervals.  Unit Tests, Integration Tests, code coverage reports, profiling, memory consumption reports, and quick / easy build deployment with automated publishing are just some of the common tasks a Jenkins server can be found doing. As we're embedded developers, we often will have to target both iP

A journey of a thousand miles begins with a single step - laozi

As I'm heading towards discussions about C++ and some cool practical knowledge things for use in Embedded software development, I feel it's important to highlight how we got here by looking at the history of this science.  Let's start by defining Computer Science.  Computer Science is not about coding, programming or software development.  Computer Science is the study of automating algorithmic processes that scale.  Algorithms occur in nature, as everything from how the stars gather together to form galaxies to the spots of a leopard or freckles on a child.  All obey natural laws that are defined within the confines of flow dynamics and were discoveries made possible by algorithmic interpretations made by Alan Turing.  A computer is merely a tool in the same way a microscope is, a tool to observe and work with the natural world by viewing and controlling algorithms. So how did we get to this modern world?  Let's look at where the term "Computer" comes from.

Google Tests

It is time to dive into some software knowledge.  We're going to start by talking further about the tools described earlier and then get into how to work on the software of our practical project "magic mirror."  So let's start: Very often programmers, project managers and industry vets will go on about how much cheaper it is to fix a bug earlier in the software development lifecycle.  The thinking goes that if you equate money with the amount of time it takes to fix something multiplied by the number of people required to fix it you arrive at a logarithmic increase of cost for each stage of the development lifecycle. Over and above the cost of fixing bugs argument, personally, it takes me longer to fix a bug if I have to do a mental context switch and relearn code that I wrote.  The longer the time frame between when I developed code and when I am faced with fixing a bug in it, the harder I feel it is to come to the same level of competence.  Also, maintaining code

App Tune-up Kit

A central theme to all embedded development has been getting better performance and thus increasing battery life.  This is entirely an exercise on how to get more out of the same hardware by doing things smarter with better design. To that end, let's talk about how to rate and compare your app with what others are doing in the wild.  On Android, this is a very easy process thanks to Qualcomm's App Tune-up Kit .  From an Android device, you can quickly grab details about any app currently installed on your device and learn about how costly it is to run that app.  Watch how when the CPU and GPU are working hard crunching numbers the battery life correlates and goes down.  Most importantly, take note of apps that run over the network.  Networking is very battery intensive, especially when not using wifi and going over the cell's 3g or 4g connection. One of the gravest sins an app can do is a process called sending heartbeats.  Heartbeats are short status notifications used t

Setting up git

If you've never used git before; it's probably best to start with github , it's a free service so long as you are doing an open source project.  If you have the ability to run your own server and require keeping your project closed source and not in the hands of a third party, then it's perfectly reasonable to run a local git server. As the process for setting up github is very simple , it seems reasonable to do a quick blog post about how to use git in a day to day type of setting.  First let's cover a few things about the theory of git. Git is a versioning control system.  It works by allowing remote computers to work on the current version of everything in a project.  Git keeps the entire history and change logs inside a subfolder of the project hidden from normal view called ".git".  Git works by comparing the contents of the directory on the remote server with the directory locally to see what has changed and what needs to be added.  This local git

Setting up Software for development and testing

We're going to get into some fun and practical knowledge for this post.  As mentioned in my first blog post, this site will use C / C++.  To that end, we'll start with examining the tools we'll use and getting the IDE (Integrated Development Environment) setup.  In order to try and avoid confusion, I will present a survey of IDE choices and setups that are popular and give advantages and disadvantages of each along with when to use them.  If you feel confused anywhere within this post, just skip to the Android Studio at the end, using it and Gradle is not only the official way to do things, it's also what I'll use in all my projects that target Android on this blog. Choosing an IDE Up until recently, May of 2015 when Google announced Android Studio Native Development Kit support; the old official way of using the Native Development Kit involved using an IDE known as Eclipse.  While I'll be mentioning the official ways, but there are non-official IDEs that ar

Practical project: Magic Mirror - part 1

We're going to do something that is a little whimsical and timely given that it was recently Valentine's day.  First let's discuss the motivation.  Snow White had this evil relative that could call out to her magic mirror by saying "Magic Mirror on the wall" and then ask it any question.  Well ya know what, we can build our own magic mirror that will respond to questions with answers, display a face, or just display some relevant information sans the evil relative bent on feeding poison apples.  Ours will display everything from motivational statements to agenda for the day and news about commute; thus works quite well for a practical Internet Of Things (IOT) project. There's some really cool magic mirrors out there built with raspberry pis. The goal of those projects is to do something that displays a message of encouragement or displays an agenda. For our version, we're going to do a Magic Mirror that does something a little more advanced than just di