The Raspberry Pi Raspbian distribution is a pretty nice way to go. I am currently working on some stuff using Qt and the Raspberry Pi camera and decided that the easiest thing was to get things going natively. Raspbian comes with Qt4.8.2 so the easy way to get started was to do:
sudo apt-get install libqt4-dev qtcreator
Unfortunately, QtCreator does not find the toolchain for some reason. This has to be configured by hand. Go to Tools > Options and select Build & Run. Then, select the Tool Chains tab and click on the Add button. Select the GCC option. This will add some stuff to the dialog. The compiler path should be set to /usr/bin/g++ and the debugger to /usr/bin/gdb. This should complete setting up the tool chain.
Another problem I had was that it wanted to do a remote deployment. To change this, click on the Projects icon in the toolbar on the left of the QtCreator window and select the tab Run Settings. The deployment method should be set to No deployment. Do this by clicking on the Add button and selecting Deploy configuration. Click the Add button for the Run configuration and select Custom executable. On the Executable: line below, enter the relative path to the executable.
Then everything should pretty much work!
I often need to clone a private Git repo from GitHub onto an embedded Linux system for native compilation. The only problem is that, to clone a private repo from GitHub, there must be a public key registered for each system. To do this for every embedded system is a total pain. However, a Linux machine that has the repo on it already can act as a local server very easily.
On the embedded system, clone the repo using this command:
git clone ssh://user@
git clone ssh://firstname.lastname@example.org/home/richard/veryinterestingrepo
would clone the repo veryinterestingrepo from the directory /home/richard on the machine at 192.168.10.2 using user name richard. At some point Git will ask for the password for user richard. Once this is entered, the clone should work as expected. Pulls and pushes will work as normal as they use the remote from which the repo was cloned.
This blog entry has a very neat way of grabbing screenshots from Android mobile devices. It boils down to a one liner (reproduced here just in case that blog vanishes for some reason and so it’s easy to find):
adb shell screencap -p | sed 's/\r$//' > screen.png
on Linux and
adb shell screencap -p | perl -pe 's/x0Dx0A/x0A/g' > screen.png
on the Mac.
Works perfectly. Thanks!
Finding PCM audio devices using the ALSA interface from software isn’t always completely trivial. On some builds for the BeagleBone Black, PCM audio devices appear as /dev/audio, /dev/audio1 etc. But this doesn’t seem to be generally true. Plus, this doesn’t definitively identify which device is which. A good way to find out is to open the pseudo file /proc/asound/pcm as it lists all the PCM devices in the system. To see what’s currently active, just cat the pseudo file:
UbuntuDev$ cat /proc/asound/pcm
00-00: ALC889 Analog : ALC889 Analog : playback 1 : capture 1
00-01: ALC889 Digital : ALC889 Digital : playback 1
00-02: ALC889 Analog : ALC889 Analog : capture 2
00-03: HDMI 0 : HDMI 0 : playback 1
01-00: USB Audio : USB Audio : capture 1
02-03: HDMI 0 : HDMI 0 : playback 1
02-07: HDMI 0 : HDMI 0 : playback 1
02-08: HDMI 0 : HDMI 0 : playback 1
02-09: HDMI 0 : HDMI 0 : playback 1
The first two numbers are the plughw card and device numbers. So, if you wanted to connect to the USB audio source for example, you could do:
snd_pcm_open (&m_handle, "plughw:1,0", SND_PCM_STREAM_CAPTURE, 0);
Prior to Android 4.0, how to do this was obvious. Now, however, you have to explicitly enable the developer options in a highly opaque way. The trick is to go to Settings > About phone and tap Build number seven times (some people say five, seven is from the Android documentation). Then Developer options will appear in Settings.