Planet Linux-to-go

I didn't post "Links" topics for a while - that's of course not because there're no interesting projects around, but because there're too many and you can't keep up with them ;-). Anyway, not collecting links to them doesn't help either, so:

• openFrameworks - C++ framework to glue together ~20 well-known technologies and libraries, mostly for visualization, UI and multimedia (all collectively "creative arts coding")
• Cinder - Another C++ contender from the similar area
• Emscripten - "An LLVM-to-JavaScript Compiler" (C, C++ compilation to JavaScript)
• asm.js - "An extraordinarily optimizable, low-level subset of JavaScript", from Emscripten authors.
• "List of languages that compile to JS"- from CoffeeScript authors.

Following up with reviewing capabilities of various build systems in previous post, recently I looked how to build all packages with custom --prefix and friends values. This is continuation of Optware for Android project, where I'd like to achieve ability to install on non-rooted device.

Here are the results:

• I was surprised at first, but OpenWRT has --prefix hardcoded as /usr when calling configure. Fortunately, that call is in common file, so it would be easy to introduce configurable variable instead. However, it turns out that install routines, which are individual for each package, have /usr hardcoded either, so each recipe needs to be patched still, which is problem for maintainability and/or upstreaming.
• Looking at Optware, situation is even worse - there, there's even less common infrastructure, and even configure call is hardcoded in each script with --prefix=/opt.
• Buildroot, being prototype for OpenWRT, has the same hardcode at /usr.
• I obviously turned to OpenEmbedded at that point (well, I tried Yocto this time) - it for sure always have had nice configurable variables for prefix and all other layout variables (--sysconfdir, etc.). Turned out, while variables are there, OE/Yocto is not ready out of the box to full configurability of both prefix and base_prefix. There were few issues seen:
• Compiler search path issues. Some aspects of search paths (mostly related to shlib linking) appear to be not stored by gcc when configured during cross-compiler, and require command-line overrides. OE passes --sysroot on each invocation, but I had to add few -rpath-link directives to get it right. While it took some time to figure the need for -rpath-link, I'm still not sure I figured where to put them (well, per upstreamability criteria).
• Some packages still hardcode paths, especially related to base_prefix. Sometimes it's a bit harder than trivial to patch (like with busybox).
• Ordering issues. Some packages implicitly assume that base_prefix and prefix are different, and filter filesets during packaging by file prefix. This doesn't work if base_prefix==prefix, so requires reshuffling filtering patters and/or package order (fortunately, OE has well-defined package splitting order).

When I bought Samsung ARM Chromebook few months ago I had no idea about UCM profiles and burnt speakers (left is dead, right is resting)…

This was good lesson. I learnt more about how UseCase Manager works, took profiles from ChromeOS and added them into Ubuntu so other users will be a bit more safe (due to lack of testers it took months to merge it into “precise” and “quantal” releases).

During last months I had discussions with some Debian, Ubuntu, Fedora developers about how to solve such problems and how to keep UCM profiles shared between distributions.

In meantime Liam Girdwood pointed me to (not used) UCM git tree at ALSA Project server. So finally I spent some time and sent Ubuntu ones for merging.

I also got newer profiles for OMAP4 devices and some updates for Chromebook ones.

The idea is to collect UCM profiles, keep them in one place and share in each distribution packages. So if your hardware has profiles created then join us to make users life easier.

---

All rights reserved © Marcin Juszkiewicz
Call for ALSA UCM profiles was originally posted on Marcin Juszkiewicz website

As I will leave Linaro at the end of May I would like to write a summary of current state of Linaro layers for OpenEmbedded.

At Linaro we have 3 layers:

1. meta-aarch64
2. meta-linaro
3. meta-linaro-toolchain

First one is BSP kind. I know that it had some issues which affected each build which had it in BBLAYERS but I fixed those issues. I would like to thank Khem Raj for pointing me at those.

We have git version of binutils there due to some changes which were not present in 2.23 line. But use of this version is not required as builds are fine with OE Core one.

We have “tune-armv8.inc” in this layer as well. There was attempt to merge that into OE Core but “/lib or /lib64″ discussion started and at that time I decided to skip it. There are similar discussions at GCC and Glibc mailing lists. Once they sort that out OE tune file will be adapted by someone (I hope).

Rest of recipes can be split into 2-3 types. Few (like sysprof, emacs) just disable recipes for AArch64. Other have extra patches to add missing functionality or defines. And we have Linaro kernel for AArch64 there.

Second layer has ARMv7a(b) machine definitions used for our machine independent builds and some recipes.

There are no patches for OE recipes here. The only exception is busybox where we enable “dpkg(-deb)” command which we need for our tools used to merge rootfs with hardware support.

We have “recipes-extra” where we keep new recipes which may not be in a nicest state so are not yet merged into OpenEmbedded (or have no use there like “meta-toolchain-hhvm” one).

“recipes-linaro” is for our stuff. Images, automatic root shell on serial port etc.

And finally is toolchain layer. Everything here is related to gcc-linaro and Linaro binary cross toolchains (armv7a and aarch64 ones). GCC 4.6 and 4.7 is there but 4.6 one will be removed when 4.8 will be added into OE Core.

Who will maintain those layers after my leave? This was not decided yet. There are few guys at Linaro who know how to use OpenEmbedded but I think that most of them is outside of Builds and Baselines team.

If you have any questions then better ask now.

---

All rights reserved © Marcin Juszkiewicz
State of Linaro layers for OpenEmbedded was originally posted on Marcin Juszkiewicz website

Since I’ve been running archlinux on some of my systems, one thing I’ve found useful is systemd-nspawn. systemd-nspawn containers (or chroots on non-systemd systems) give you a quick way to install a Linux distribution, that can run inside an existing Linux system.

Some cases where systemd-nspawn containers (referred to as containers in this document) are useful:

1. Currently OpenEmbedded won’t build with GCC 4.8 (included in archlinux).
2. For product build systems (may live for many years), typically OE will eventually break as you upgrade the workstation distribution.  For projects that need a long-lived OpenEmbedded build system, setting it up in a chroot makes a lot of sense.
3. Someone might be having a compile or build problem with a distribution you don’t currently have installed.  With containers, you can quickly set up a test distribution to reproduce problems.
4. I’ve had cases where I need an older version of Qt for a project, but my workstation includes a newer version.  Again, setting up a OS container is sometimes simpler than getting two versions of Qt to dwell together peaceably in the same distribution.
5. Backing up or replicating your entire build system is very easy — simply rsync the OS container directory to another machine.

So the solution is to select a relatively stable, long-lived distribution to host your product builds. Debian is good choice.  Because the container is simply a directory in the host workstation filesystem, you can use host workstation tools (editors, git, etc) directly in the container filesystem.  The only thing you need to use the chroot for is the actually building.  If you make sure the user ID is the same between your workstation and nspawn container, then permissions are seamless — you can easily access files in the container from the context of your host workstation.

To set up a nspawn-container:

1. host: sudo debootstrap –arch=amd64 wheezy ~/debian-wheezy/
2. host: sudo systemd-nspawn -D ~/debian-wheezy/
3. container: apt-get update && apt-get install ssh
4. container: edit /etc/ssh/sshd_config, and set port to something other than 22 (23 in this example)
5. container: /etc/init.d/ssh start
6. container: set up users, ssh keys, etc.

(This systemd-nspawn man page gives examples for setting up other distributions.)

Now, on the host system, you can simply “ssh -p23 localhost” any time you want to log into the container.  Soft links between the project workspace on the host system, and the container can also make shifting between the two easier.

An alternative way to start the container once its set up is:

sudo systemd-nspawn -D ~/debian-wheezy /sbin/init

Its also handy to make the shell prompt in the container slightly different than the host OS so that you can easily tell the difference.  To accomplish this, add the following to ~/.profile in the container OS:

export PS1=”[\u@wheezy \W]\$ “

Hopefully this gives you a quick overview of how OS containers can be set up, and used in your OpenEmbedded build systems.

Good things have one ugly part in common — they have to end one day… For me that day will be 31st May 2013 when contract between Canonical and Linaro will end.

Those 3 years were great. I wrote a lot about it half year ago so those of you who are new – go to my previous “good bye Linaro” post before reading rest of this post.

Half year ago I was going to Canonical but got hold at Linaro for longer. Then I made a mistake by agreeing to postpone my move to Linaro instead of joining as soon as possible — my fault…

Last 6 months were full of interesting things. We went from just bootstrapped AArch64 port to fully working LAMP and SDK images built with OpenEmbedded. I integrated all Linaro layers into one repository and reorganized in a way that those who want only our toolchains can have them without using any of our changes. This move was greeted by lot of maintainers and users from OpenEmbedded community. Wherever new toolchain components were provided for tests I had them checked on first day to see how AArch64 situation got improved and provided fixes when they were needed.

Recent release of Yocto Project has several changes done by me and Riku Voipio integrated. OpenEmbedded project also made release and has even more our changes in it. Most of those were AArch64 related, some were software updates or fixes to low level stuff.

Linaro Enterprise Group has Owen Yamauchi from Facebook working on porting HipHopVM. He is using SDK created by OpenEmbedded to not worry about any build dependencies or missing libraries. With my work (and work from porters like Riku Voipio, Steve McIntyre, Yvan Roux and others) he got not only libraries but also tools he needed for his job.

Andy Johnson started OpenJDK porting — also with OpenEmbedded. Riku provided instructions which I merged into our ‘jenkins-setup’ scripts to make live easier for Andy.

Due to all that work I am often contacted by random people (not only from Linaro) wherever they have some AArch64 related questions. Sometimes even with ARMv4/EABI related like post from Nicolas Pitre a day after RMK wrote that FPU emulator has to be removed from the Linux kernel. I provided him instructions how to make such build and just to be sure that I did not made any mistakes I tried one on my machine. IIRC none of main distributions support EABI for ARMv4 (no thumb) processors.

But looks like all that has to end. Unless someone from Linaro member companies (or who knows, maybe even Linaro itself) wants to hire me. I am open for offers.

If I go outside of @linaro.org then I would like to stay around and check how things go — probably as ‘community member’ or how it is called.

And one more thing at the end. As usual when I end my work at one place I gather recommendations on LinkedIn. If you have few spare minutes and want to write something then it will be appreciated.

---

All rights reserved © Marcin Juszkiewicz
Looks like it is time for me to say good bye again was originally posted on Marcin Juszkiewicz website

Linus Torvalds released Linux 3.9 and many websites published summaries what’s new in it. One of common entries is support for ChromeOS laptops. But what that means for Samsung ARM Chromebook users?

Let’s start with Kernel Newbies summary which lists 5 commits:

• Platform: x86: Add Chrome OS Laptop driver
• Platform: x86: chromeos_laptop – Add Acer C7 trackpad
• Platform: x86: chromeos_laptop – Add HP Pavilion 14
• Platform: x86: chromeos_laptop – Add Pixel Touchscreen
• Platform: x86: chromeos_laptop – Add Taos tsl2583 device

None of them are for ARM Chromebook. But that does not mean that nothing was done for it. Touchpad driver was merged, many Exynos platform changes were made but yeah — still lot to do.

But that’s a curse of ARM platforms…

UPDATE: Arnd Bermann wrote a comment on my Google+ post that Olof Johansson has “linux-next” bootable on ARM Chromebook. YAY!

UPDATE: I got ChromeOS 3.8 kernel running on my Chromebook. Needs some testing and then will land in “saucy” as default one probably.

---

All rights reserved © Marcin Juszkiewicz
Linux 3.9 and Chromebook support was originally posted on Marcin Juszkiewicz website

Today I can celebrate 3 years of working for Canonical.

First days

I was supposed to start from 1st May but as I had vacations already planned for that week (in Poland 1st and 3rd May are national holidays) they asked me to start work one week earlier — on 26th April 2010.

First week was usual learning about company rules, structure, reading wiki etc. Then I went for vacations and right after I was going for UDS-M (somewhere around Brussels, Belgium) where I met a team of people of unnamed project. Some days after event that team got a name: Linaro.

Linaro Developer Platform

I am a member of Developer Platform from beginning. Our team was changing, we got more people than we lost some as they moved to newly created teams and we had few renames. First it was Foundations (like Ubuntu Foundations at Canonical), then Developer Platform, then just Platform. Now we are Bold & BeautifulBuilds and Baselines.

We work on delivering components done by other teams (like ARM and AArch64 cross toolchains, Linux kernel), provide test images created from Ubuntu packages or built with OpenEmbedded (soon also Fedora).

Since September 2012 I am working on AArch64 (64-bit ARM) bring-up with use of OpenEmbedded (as at that time none of distributions had anything working to base on). Updated toolchain, fixed many issues with different software packages, patched some applications/libraries. Cooperated with few teams at Linaro and with several upstream projects.

Canonical or Linaro?

As some people remember there was a moment last year when I was supposed to leave Linaro and go to Canonical. But someone decided to keep me for longer…

But such things does not last forever. At the end of May I will probably end my journey at Linaro cause contract for Canonical’s engineers will end. Unless someone wants to keep me for longer…

---

All rights reserved © Marcin Juszkiewicz
3 years at Canonical was originally posted on Marcin Juszkiewicz website

I plan to visit London and Cambridge on 16-22 May. Just for sight-seeing and meeting friends — no business this time.

Plan is to meet old OpenedHand fellows, some old friends from Poland, maybe visit Canonical office just to see it (as I work for them for nearly 3 years). And of course see something cause I was few times in London but managed to see only train/metro stations and nearly nothing more.

Then Cambridge for 40th Cambridge Beer Festival. There are friends to meet as well and maybe see something as well (but here I saw far more things than in London).

As usual flights from/to Berlin to one of London airports (plan to return from Stansted as it is the easiest to get there from Cambridge). Need to sort out some places to stay.

Also have to check which UK prepaid is useful today. I need few gigabytes over HSPA — previously Giffgaff was fine for it for just 10 GBP but they have changed rules. Tethering required due to tablet and Chromebook (which I plan to get repaired or replaced).

Any suggestions for 3G or place to stay?

---

All rights reserved © Marcin Juszkiewicz
Time to visit UK again? was originally posted on Marcin Juszkiewicz website

As of version 1.8.2, Git submodules can now track branches instead of specific commits.  This is good news as in many cases, this is exactly the behavior we want.  However, Git submodules are still not as flexible as Google repo, but since submodules are built into Git, the submodule command is a good solution in many cases.

The “git submodule update –remote” command is the key to tracking branches with submodules.   The following is from the Git man pages:

–remote
This option is only valid for the update command. Instead of using the superproject’s recorded SHA-1 to update the submodule, use the status of the submodule’s remote tracking branch. The remote used is branch’s remote (branch.<name>.remote), defaulting to origin. The remote branch used defaults to master, but the branch name may be overridden by setting the submodule.<name>.branch option in either .gitmodules or .git/config (with .git/config taking precedence).

This works for any of the supported update procedures (–checkout, –rebase, etc.). The only change is the source of the target SHA-1. For example, submodule update –remote –merge will merge upstream submodule changes into the submodules, while submodule update –merge will merge superproject gitlink changes into the submodules.

In order to ensure a current tracking branch state, update –remote fetches the submodule’s remote repository before calculating the SHA-1. If you don’t want to fetch, you should use submodule update –remote –no-fetch.

So, if you already have a Git submodule set up, its a simple matter to run git submodule update –remote to update the submodule to the latest master branch.  If you want a different branch, simple edit .gitconfig.

[submodule "meta-bec"]
   path = meta-bec
   url = git@github.com:cbrake/meta-bec.git
   branch = test

Now, if you run git submodule update –remote, Git will update the meta-bec submodule to the latest on the test branch.

This functionality is purely a convenience feature in the submodule update command.  In the actual repository, Git still stores submodules pointed to a particular commit.  The same thing could be accomplished with something like git foreach “git fetch && git checkout test”.  The branch option in .gitmodules functions more as documentation and convenience.  It is very handy to be able to look at .gitmodules and quickly determine that submodule X is tracking branch Y.  Normally, this would have to be documented elsewhere, or figured out in some other way.  Also, for build systems where you want the build to always track the production branches of various projects, update –remote gives you a convenient way to update the build tree.

As guys from/around Texas Instruments promised there is new Beaglebone Black on a market. Faster, cheaper, with video output and other extras. For me it looks like Raspberry/Pi killer done right.

What is on board?

There is a lot of goods:

• 1GHz TI AM355x cpu with ARM Cortex-A8 core supporting ARMv7-a instruction set
• PowerVR GPU with OpenGL ES support (closed source driver)
• HDMI output (with audio)
• 512MB ram
• 2GB eMMC
• 92 expansion pins
• USB Host
• USB device
• Ethernet
• microSD slot
• user controlled LEDs
• serial port header

And it still supports (most of) expansion boards from the original Beaglebone which can add extra functionality so possibilities are uncountable. All that for only 45$.

But why it is better?

1. ARMv7-a cpu core. It means that you can run any Linux distribution on it. Think Ubuntu/armhf, Debian/armhf, Fedora/armhf. No need to reinvent a wheel (aka armhfv6 done for Raspbian distribution).

2. No dependencies on closed source components. You can boot board and use it with what ever you want and still have control on all sources used. Sure, there are some binary blobs for OpenGL ES but if you do not need this then you are fine. Try to boot R/Pi without binary blobs…

3. Texas Instruments level of support. Sure, we heard that they abandoned mobile market but Sitara line of processors is still in development, there are new CPUs and they provide documentation and source code for product. Also amount of work done in mainline kernel is not something to be ignored.

4. Expansion headers. Compare 26 pins of R/Pi with 92 of Beaglebone… Then add capes to this.

So which one to choose?

Beaglebone Black of course ;D

As people on IRC told there are other cheap devices made in China with faster cpus and more memory. But for me Beaglebone is not ‘yet another ARM computer’ but rather ‘yet another microcontroller on ultra steroids’ and this is where the true power of this board resides.

---

All rights reserved © Marcin Juszkiewicz
Death to Raspberry/Pi — Beaglebone Black is on a market was originally posted on Marcin Juszkiewicz website

I am subscribed to many mailing lists. Creating filters for them was usually pain but keeping all in one folder was also not useful. So I decided to make it more automatic.

There are many pages which will tell you how to use maildrop, how nice it is etc. But as I am used to “autofolder” set of procmail rules written by Kamal Mostafa from Canonical I had some requirements already and some ideas how to handle few things in other way.

So what I did? Maybe not so much so far:

• handle @list[sy].DOMAIN servers
• autocreation of folder structure (/ML/{DOMAIN}/{LISTNAME})
• all GitHub projects are handled as folders of github.com

There is a lot of work to do but for now I am happy with what I did.

You can see it in hrw/dotfiles-mailfilter repository on github.

If someone finds it useful then please comment, fork, send merge requests, patches etc.

---

All rights reserved © Marcin Juszkiewicz
Automatic sorting of mailing lists with maildrop was originally posted on Marcin Juszkiewicz website

Around week ago courier brought me Nexus 7 tablet (32GB, wifi only) as kind of upgrade to my Archos G9 80 ‘so called’ Turbo one.

First steps

Charged a bit, booted into Android 4.2 and was greeted by “upgrade to 4.2.2 is possible” soon after wifi connection. But decided to go my way instead ;)

Fetched Clockworkmod touch recovery, CyanogenMod 10.1 nightly image and Google Apps 4.2.2 pack and booted into bootloader. Quick ‘OEM unlock’, flash of new recovery and few minutes later I had CM 10.1 running just like I wanted.

Restored apps from Archos with use of TitaniumBackup and after some configuration I had tablet which responds fast and behaves properly.

Multiuser stuff

As my daughter was main user of Archos I waited for Android 4.2 to get multi user capabilities. Played a bit with them on G9 (with Paranoid Android installation) but 512MB ram and OMAP4430 gave my terrible experience with far too many moments when I wanted to crush tablet into pieces…

So when Mira had come from kindergarten I shown her Nexus 7, made a photo with internal ‘want to be a camera’ thing and gave instructions on how to turn device on and switch to her configuration. She had no problems with understanding it ;)

There are some issues with multiuser stuff. Each user is expected to have Google account, applications are not shared etc. I understand why but in my case it was annoying.

But there is Multi-User App Share app which allows to share applications with different users. So Mira has all her children apps and games available and is not able to spend real money on in-app payments due to lack of Google account (and credit card). I was able to remove them from my configuration as well.

Sharing files is more complicated as so far I did not check is there a shared space for them. So each of us has own music/movies.

Do I miss something?

There are few things which Archos G9 80 has and Nexus does not:

• HDMI output
• microSD slot
• USB Host port

I may miss video output sometimes but had not used it for over half a year now. MicroSD would be nice so I would not have to buy 32GB version. But ~20% of tablet (50$) was sponsored by Tizen ;)

And by USB Host port I mean normal EHCI host port. Not an OTG one present in Nexus 7.

But I do not miss crazy upgrade scheme invented by Archos. Also do not miss I Scream for Sandwitch version of Android they offered. We have XXI century and their upgrade path is from previous millenium.

Complains?

So far I did not find something to complain about. OK, screen could be more square (4:3 Archos, 16:10 Nexus) but it is fine for me. Ask me in few months ;)

---

All rights reserved © Marcin Juszkiewicz
Nexus 7 — upgrade or complain? was originally posted on Marcin Juszkiewicz website

I think that most asked question about Chromebook in last months was about hardware acceleration. So let’s write something about it.

OpenGL ES

There is a driver for OpenGL ES for Samsung Exynos5 Dual cpu present in Chromebook. But there are two versions of it: Week35 and Week45. Both require different kernel versions.

Ubuntu 13.04 has 3.4.0-5 kernel package which was built from R23 kernel branch. Week35 OpenGL ES driver works with it and you have to grab it from ChromeOS (but maybe it got updated there already).

I still have to find time and get R25 (or R26 or R27) kernel working so we could upgrade to Week45 driver. This one is available in ChromeOS as well (beta or dev).

Where are my packages?

There were packages which provided OpenGL ES driver binaries (week45). I removed them due to license issues as it looks like Samsung bought Mali T604 license from ARM Ltd. and got it working with Exynos5 Dual. Then they sub licensed it to Google for use with ChromeOS.

So Samsung does not distribute the driver — Google does. And even when they give tarball with files there is no license in it — just standard “Google Terms of Service” note.

No redistribution license == no packages. Sure, someone can make “chromebook-opengles-driver-installer” like package which would grab binaries from ChromeOS (I did such for week35) or will fetch them from network. Feel free to do it — you can use my chromebook-mali-driver repository as a base. Once you will get it working I can put it into Samsung Chromebook PPA.

Multimedia decoding

Other thing is hardware accelerated multimedia decoding (maybe also encoding). Under ChromeOS it was done with OpenMAX stuff. Google even had some binaries available but they crashed badly under Ubuntu.

How situation looks today? No idea as I did not had time for Chromebook stuff in last months.

---

All rights reserved © Marcin Juszkiewicz
Hardware acceleration on Chromebook was originally posted on Marcin Juszkiewicz website

It took me a while to find out, but it is possible to fix a Siemens NCDC 2015 car radio (ok they call it “entertainment system”) suffering from the “0khz” problem quite easy.

The story: I usually drive old cars… my current one is an Opel Omega from 2001 and that one came with the NCDC 2015. Actually its the kind of retro technology I like: No iPod connector, no USB and similar interfaces but two CD drives for five CDs in total and in combination with the Bose speaker system the sound is quite good… the usability has some limits: Using it I tend to ask myself questions like these: Why do I have a way to display the balance settings but not for the volume setting?

Anyway, one common failure of this device is that they have a problem with power loss (e.g. flat battery or removal from the car without removing fuses before. The symptoms in most cases are that you see “0 khz” in all station entries and no sound at all (neither from tuner, navigation or CD). I found a hint how to fix it in a Polish electronics forum (elektroda.pl). Obviously the device ends up with data in an 24LC16 EEPROM it is not able to andle and the firmware does not know ti recover from. I have seen some hints that the successor of the 2015 has a maintenance mode with an option to reset the EEPROM.

The most simple solution seems to be to replace the EEPROM with a new and empty one. Its quite easy to do and a replacement EEPROM is cheap, less than EUR 1 if you are lucky. I made a little bit more detailed description in the hope it might be useful for someone else.

So what do we need?

• Tools for removing the device from the car
• T8 Torx crewdriver
• Soldering equipment
• 24LC16 EEPROM (SMD, SO8 case)

The hardest part is to remove the device from the car… there is no way to do it without cursing ;) Important: Disconnect power before removing it, it is reported that removing these with the battery connected caused

There are two screws that hold the upper cover which are easy to find. Just remove the cover and you will see something like this:

Now remove the four marked screws in order to remove the CD drive. Take care of the FCC cables below. Remove the cables after unlocking them by moving the black mount of the socket in the direction of the cables (not by lifting them!).

Now you can see the cause of the “brain damage”:

Unsoldering the EEPROM is a little bit tricky. If you have access to hot air soldering equimpment it is going to be easier. Take care about orientation and not to damage the pads replacing the IC.

Put the pieces together and the NCDC 2015 back to the car.

For me this procedure worked pretty well. I still see some strange effects like that the tuner did not fill the station list completely and maybe the sound has changed a little bit. Maybe some input sensitivity setting was hardcoded in the EEPROM. Is there any one out there who knows some details about what gets stored in there?

 

Debugging problems which mean init goes crazy is tricky, especially so on modern Intel hardware that doesn’t have anything resembling a serial port you can connect to.

Luckily this isn’t a new problem, as Linux supports a network console which will send the console messages over UDP packets to a specific machine. This is mostly easy to use but there are some caveats that are not obvious.

The prerequisites are that netconsole support is enabled, and your ethernet driver is built in to the kernel and not a module. Luckily, the stock Yocto kernels have netconsole enabled and the atom-pc machine integrates the driver for my hardware.

Then, on the target machine, you pass netconsole=... to the kernel. The kernel documentation explains this quite well:

netconsole=[src-port]@[src-ip]/[],[tgt-port]@/[tgt-macaddr]

   where
        src-port      source for UDP packets (defaults to 6665)
        src-ip        source IP to use (interface address)
        dev           network interface (eth0)
        tgt-port      port for logging agent (6666)
        tgt-ip        IP address for logging agent
        tgt-macaddr   ethernet MAC address for logging agent (broadcast)

The biggest gotcha is that you (obviously) need a source IP address, and netconsole starts before the networking normally comes up. Apart from that you can generally get away with minimal settings:

netconsole=@192.168.1.21/,@192.168.1.17/

Note that apparently some routers may not forward the broadcast packets correctly, so you may need to specify the target MAC address.

On the target machine run something like netcat to capture the packets:

$ netcat -l -u -p 6666 | tee console.log

If you get the options wrong the kernel will tell you why, so if you don’t get any logging iterate a working argument on an image that works, using dmesg to see what the problem is.

Finally instead of typing in this argument every time you boot, you can add it to the boot loader in your local.conf:

APPEND += "netconsole=@192.168.1.21/,@192.168.1.17/"

(APPEND being the name of the variable that is passed to the kernel by the boot loader.)

Update: when the journal starts up systemd will stop logging to the console, so if you want to get all systemd messages also pass systemd.log_target=kmsg.

This one is nice and simple, to fix the sensitivity of the touchpad back to what you were used to under ChromeOS.

xinput set-prop 7 "Synaptics Finger" 5 5 256

If I could work out where xfce4 keeps its autostart files then I could get this to run at startup.

I blame ‘hrw’ for showing off his Chromebook at Connect, but when I returned to the UK I obtained one.

Running chrome itself is of little interest to me, much more interested in using it as a laptop. So first of all I used ChrUbuntu to get a 12.04 on it. Then I followed hrw’s instructions how to upgrade to 13.04. I messed it up a couple of times but eventually succeeded.

I will say two tips before rebooting, make sure you have ssh server running, and make sure you have a /etc/X11/xorg.conf working. Also if you are doing internal its really helpful to already have a valid install on external SD card you can boot in emergency.

It seems at the moment armsoc Xorg driver prevents suspend by crashing on VT change and then forcing a VT change when it restarts. So if you actually want to use the device you might need to switch to fbdev driver for now!

Very nice little device, I hope more of this sort of low power laptop appear to replace the now killed netbook market.

 

The question of mutually exclusive streams in PulseAudio came to mind earlier, and thanks to Arun and Jens in #gupnp I discovered the PulseAudio supports them already. The use-case here is a system where there are many ways of playing music, but instead of mixing them PA should pause the playing stream when a new one starts.

Configuring this with PulseAudio is trivial, using the module-role-cork module:

$ pactl load-module module-role-cork trigger_roles=music cork_roles=music

This means that when a new stream with the “music” role starts, “cork” (pause to everyone else) all streams that have the “music” role. Handily this module won’t pause the trigger stream, so this implements exclusive playback.

Testing is simple with gst-launch

$ PULSE_PROP='media.role=music' gst-launch-0.10 audiotestsrc ! pulsesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstPulseSinkClock

At this point, starting another gst-launch results in this stream being paused:

Setting state to PAUSED as requested by /GstPipeline:pipeline0/GstPulseSink:pulsesink0...

Note that it won’t automatically un-cork when the newer stream disappears, but for what I want this is the desired behaviour anyway.

This is probably not the cleanest or the neatest way to do this but until LXDE gets a synaptic applet of its own its one way to configure your touchpad on login so it functions how you want it.

First create a file $HOME/bin/touchpad.sh with you configuration set using synclient.

#! /bin/sh

synclient TapButton1=1
synclient TapButton2=3
synclient TapButton3=2

And make it executable chmod 755 $HOME/bin/touchpad.sh

Now create a file to autostart this on login $HOME/.config/autostart/touchpad.desktop.

[Desktop Entry]
Name=Touchpad
GenericName=Touchpad Config
Comment=Personal Touchpad Settings
Exec=/home/someone/bin/touchpad.sh
Terminal=false
Type=Application
Icon=xterm
Categories=X11;
StartupNotify=false

This is probably not standards compliant .

Now if you logout and login your touchpad should be configured correctly. If you copied my setting one finger tap for left button, two finger tap for right button, three finger tap for middle button.

I always considered animation in GUI a whimsical feature wasting resources (in particular, power in mobile devices) and oftentimes just covering triviality of contemporary software for mobile systems (IPhone and Android, hello), and inconveniences user with slow, repetitive, boring effects.

Live and learn, I found usecase where lack of animation makes user interaction unobvious and complicated. It's not about going from one square page to another though, but about applying transformation to graphs.

It all started with my desire to study dependencies among Android modules (which is task towards my "Packaged Android" project). I found adepends.py tool (my fork), which is very nice and dumps dependency info in .dot format for rendering with Graphviz. Looking at few graphs it became obvious that for comfortable browsing there should be interactive graph viewer with few capabilities which I summarized in Stackoverflow question.

My searching didn't turn suitable viewer, but fortunately I found xdot.py, which is extremely cool graph viewer app written in Python, which was suitable base for easy implementation of needed features.

And here story comes to the topic of the post - once I implemented prototypes of  those features, they indeed proved to be really helpful, but didn't give aesthetic satisfaction - that's because when hiding a node for example, Graphviz's dot completely overhauls rendering of a graph, so user loses track of context he used with. Having shape of a graph morph from old to new state would help a lot.

Actually, animation can help even with simpler graph operation, for example going from one node to another in a complex graph - seeing a ride over an edge which connects them helps intuitive understanding a lot. See ZGRViewer's "link sliding" feature in a video on Youtube:

Simplified form of going from node to node is implemented in xdot.py, except that it moves between nodes via shortest path, which doesn't capture context of curved edges. (Btw, ZGRViewer may be full of cool ideas, but its UI grossly sucks comparing with XDot, literally, it's outbreak from last century). I seriously consider implementing non-linear animation approximating Bezier curves for XDot.

So that's it - going from hating animations to wanting implement non-trivial animations myself in couple of days ;-). (That's also the first time I embed video?)

If you are a Transformer user you will have noticed that the latest updates of the youtube app from Google busted fullscreen while you are docked with keyboard.

This has been well discussed on xda-developers forum and it seems for now the only way to restore functionality is to roll back to the latest working version.

The latest version is on the forums here.

Just uninstall all updates then install this package instead. It is a bit unfortunate that you also lose the nice clean interface of the newer app.

Did you ever need a quick way to share files from a directory on your computer?  Or perhaps transfer a large file to another person?  With nodejs and express, you can easily set up a temporary web server that allows users to browse and access a list of files in a directory.  For convenience, I created a simple github project that can be cloned into any directory, and then a server started in a matter of seconds.  Yes, you could upload files to a server, or share them with a file sharing service, but if you can expose a random port on your computer to the person who needs the files, then this is faster, and does not require any intermediate steps.  Check out https://github.com/cbrake/http-file-server for more information.

And today we return to narrow gauge trains with Billy Jones Wildcat Railroad. This is a cool little narrow guage in the Oak Meadow Park at Los Gatos. They have a steam engine and two diesel engines. Unfortunately the steam engine does not run in the winter months. Guess that’s an excuse to come back in the summer.

At only 2$ a ticket it’s a bargain for a 15 min ride around the park on the train.

At the end of every run the engine has to be turned around. The have a little turntable just off the end of the platform for this task.

When using OpenEmbedded for product development, there are several reasons you may want to consider setting up a source mirror for your OpenEmbedded build:

• over time, sources disappear from download locations
• various servers for source packages may be off-line at the time a build is run
• some servers may be very slow, which slows down your build
• occasionally the checksums of a source package will change

For a production build system, you want the build to be reliable and consistent, so this means not depending on 3rd party web sites/servers for a clean build to complete.  Fortunately, OpenEmbedded makes it easy to set up a source mirror with the PREMIRRORS variable. When bitbake tries to fetch source code, it tries PREMIRRORS, the upstream source, and then MIRRORS.  There are several advantages to using a PREMIRROR variable over a MIRROR for your source mirror:

• your source mirror will be used first, thus slow web sites are not an issue
• if the checksums of the package change, the build will not fail because its still using the original source package from the mirror.  You are guaranteed to be always using the same source package.

Setting up a source mirror is as simple as copying the contents of your downloads directory to a web server, and then populating the following variable in local.conf:

PREMIRRORS_prepend = "\
     git://.*/.* http://my-server/sources/ \n \
     ftp://.*/.* http://my-server/sources/ \n \
     http://.*/.* http://my-server/sources/ \n \
     https://.*/.* http://my-server/sources/ \n"

The Poky reference manual has more details.

• Energy Micro EFM32 "Tiny Gecko" Developer Board - Impressions and open source tools usage thinking
• EFM32STK linux toolchain - Blogpost on using EFM32STK under Linux
• https://launchpad.net/gcc-arm-embedded - Cortex-M targeted toolchain from Ubuntu developers, binary tarball releases
• J-Link downloads -Tools/drivers for JTAG/SWD controller as included in EFM32STK boards, including for Linux
• EnergyMicro downloads - Official EnergyMicro downloads, including Linux tools

Hi folks!

Obviously I don’t manage to update this blog more than a few times a year. I must confess that – for smaller status messages – I find Facebook and Twitter working quite well. So if you want to stay in touch a bit more, hop over to my page @ Michael Lauer or follow my Tweets @ DrMickeyLauer.

The biggest tasks this year was getting Lara Marie to sleep well and buying a house, both which we finished successfully. Right now we have a hole in the ground, but it’s supposed to be finished by October 2013. I’m going to report about the progress now and then.

FOSS-wise I didn’t manage to do anything meaningful more than visiting FOSDEM and the OHSW this year. I tried to catch up with what’s happening in FSO, Vala, and OpenEmbedded though. Since I do no longer use OE on a frequent basis, I decided to not run for re-election as OE board member, thus also resigning from being OE e.V. president. I’m quite happy to hand the paperwork over to someone else

With Lara Marie growing older (she’s now 18 months), I enjoy being a father more and more. While mommy was #1 in the first year, it becomes apparent that I’m #1 in the 2nd year, helping the little one to form her individuality and her will.

Company-wise 2012 was a bit of a ride as due to the economy some of our biggest clients postponed their app updates and we struggled a bit getting enough contracts to keep the four of us busy. Then again, we worked on our own apps in the free time and I’m happy to announce the next major version of Volksradio / Just Radio, which is going to ship soon.

I wish all of you a merry 2013!

Yours, Mickey!

Many people thinks that it is difficult to report a bug found at Intel Graphics Stack. It is not.

1. Forget about difficult how-tos and tutorials.
2. Get latest Intel GPU Tools from git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
3. Compile it: ./autogen.sh; make;
4. Reboot your machine adding drm.debug=0xe log_buf_len=4194304 to Kernel cmd line.
5. Run: sudo ./tools/intel_gpu_abrt
6. Get intel_gpu_abrt.tar and template generated and publish it at https://bugs.freedesktop.org/ at the correct category:
   • For 2D driver bug: Product=xorg. Component=Driver/intel.
   • For 3D driver bug: Product=Mesa.
   • For chipset i8xx/i915/i945/Q33/G33/Q35: Component=Drivers/DRI/i915.
   • For chipset i965/G35 and later: Component=Drivers/DRI/i965.
   • For DRM kernel bug: Product=DRI. Component=DRM/Intel.
   • For Libva bug: Product=libva. Component=intel

I expect to remove steps 2 and 3 once my new changes arrives at your Linux distribution.

Now on, I’ll try to write more here about news from our gfx land. Some news listed here might not be so new to you, but I just came back from a 20 days vacations and I’m still jumping back.

Intel 2012Q4 gfx stack released.

Highlights of this release: New features: basic 2D and 3D Haswell support with all the PCI IDs, ValleyView support, OpenGL support for Haswell, hardware accelerated video decoding, and encoding for Haswell. Since the last release, there were major improvements and bug fixes in all the areas of our drivers.

HSW is already in a good shape right now on  drm-intel-nightly branch from our official development tree maintained by Daniel Vetter at: http://cgit.freedesktop.org/~danvet/drm-intel/ and it is being pushed upstream landing in 3.8 to be released early next year.

There are more stuff besides HSW going on on the kernel side. Daniel Vetter has written a good post about new stuff comming to 3.8.

We also had a Internal Kernel Summit activity in London, before my vacation were we defined tasks for next year and created a rotating Bug Team responsible for take special attention to all bugs filed on kernel and freedesktop bugzilla agains drm/i915. The intention is to avoid having bugs there not updated for a long time and the reports are already been sent to intel-gfx@lists.freedesktop.org mailing list.

On  2D side my highlights go to

- XWayland updated to work with Wayland 1.0 by Daniel Stone

- Added missing gtf modes  allowing games to use low mode trough panel fitter to upscaling to fill screen in a better shape.

- SNA Performance. Benchmark by Phoronix.

On  3D side, Intel devs are working on OpenGL ES3, and just merged ETC2 texture compression, as already described at this Phoronix post. Phoronix also perform benchmarks at Mesa 9.0 x Mesa 9.1.

On  Media side, I’ll just paste updates from Gwenole Beauchesne:

* libva-intel-driver 1.0.19 released on 09.Nov.2012

- Add support for Haswell (decode, encode)

- Add support for raw DRM, e.g. display-less pipelines

- Additional bug fixes for improved stability

* gstreamer-vaapi 0.4.1 released on 27.Nov.2012. Major new features include:

- Add support for H.264 interlaced streams

- Fix memory leak in MPEG-2 decoder for empty user-data packets

- Fix H.264 decoder with MMCO-based reference picture marking process

- Fix decoders to honour end-of-stream messages (i.e. flush pending contents)

- Fix pixel-aspect-ratio reported to downstream elements

Requirements for supporting Wayland 1.0/x:

- libva from git master (1.1.1.pre1)

- libva-intel-driver from git master (1.0.20.pre1)

- gstreamer-vaapi 0.4.1

 

Last month our friends at Codethink were guests on FLOSS Weekly, talking about Baserock. Baserock is a new embedded build system with some interesting features/quirks (depending on your point of view) that I won’t go into. What caught my attention was the discussion about build times for various embedded build systems.

Yocto, again, if you want to do a clean build it will take days to build your system, even if you do an incremental build, even if you just do a single change and test it, that will take hours.

(source: FLOSS Weekly #230, timestamp 13:21, slightly edited for clarity)

Now “days” for a clean build and “hours” for re-building an image with a single change is quite excessive for the Yocto Project, but also quite specific. I asked Rob Taylor where he was getting these durations from, and he corrected himself on Twitter:

I’m not sure if he meant “hours” for both a full build and an incremental build, or whether by “hours” for incremental he actually meant “minutes”, but I’ll leave this for now and talk about real build times.

Now, my build machine is new but nothing special. It’s built around an Intel Core i7-3770 CPU (quad-core, 3.4GHz) with 16GB of RAM (which is overkill, but more RAM means more disk cache which is always good), and two disks: a 250GB Western Digital Blue for /, and a 1TB Western Digital Green for /data (which is where the builds happen). This was built by PC Specialist for around £600 (the budget was $1000 without taxes) and happily sits in my home study running a nightly build without waking the kids up. People with more money stripe /data across multiple disks, use SSDs, or 10GB tmpfs filesystems, but I had a budget to stick to.

So, let’s wipe my build directory and do another build from scratch (with sources already downloaded). As a reference image I’ll use core-image-sato, which includes an X server, GTK+, the Matchbox window manager suite and some demo applications. For completeness, this is using the 1.3 release – I expect the current master branch to be slightly faster as there’s some optimisations to the housekeeping that have landed.

$ rm -rf /data/poky-master/tmp/
$ time bitbake core-image-sato
Pseudo is not present but is required, building this first before the main build
Parsing of 817 .bb files complete (0 cached, 817 parsed). 1117 targets, 18 skipped, 0 masked, 0 errors.
...
NOTE: Tasks Summary: Attempted 5393 tasks of which 4495 didn't need to be rerun and all succeeded.

real 9m47.289s

Okay, that was a bit too fast. What happened is that I wiped my local build directory, but it’s pulling build components from the “shared state cache”, so it spent six minutes reconstructing a working tree from shared state, and then three minutes building the image itself. The shared state cache is fantastic, especially as you can share it between multiple machines. Anyway, by renaming the sstate directory it won’t be found, and then we can do a proper build from scratch.

$ rm -rf /data/poky-master/tmp/
$ mv /data/poky-master/sstate /data/poky-master/sstate-old
$ time bitbake core-image-sato
Pseudo is not present but is required, building this first before the main build
...
NOTE: Tasks Summary: Attempted 5117 tasks of which 352 didn't need to be rerun and all succeeded.

real 70m37.298s
user 326m45.417s
sys 37m13.304s

That’s a full build from scratch (with downloaded sources, we’re not benchmarking my ADSL) in just over an hour on affordable commodity hardware. As I said this isn’t some “minimal” image that boots straight to busybox, this is building a complete cross-compiling toolchain, the kernel, X.org, GTK+, GStreamer, the Matchbox window manager/panel/desktop, and finally several applications. In total, 431 source packages were built and packaged, numerous QA tests executed and flashable images generated.

My configuration is to build for Intel Atom but a build for an ARM, MIPS, or PowerPC target would also take a similar amount of time, as even what could be considered “native” targets (targeting Atom, building on i7) doesn’t always turn out to be native: for example carrier-grade Xeon’s have instructions that my i7 doesn’t have, and if you were building carrier-grade embedded software you’d want to ensure they were used.

So, next time someone claims Yocto Project/OpenEmbedded takes “days” or even “hours” to do a build, you can denounce that as FUD and point them here!

The white horse enduro was on Sunday and I’d been invited to marshal. I’ve never held any illusions about my ability regarding an enduro, its something I’d just never do but this was a chance to see one up close. You know it will be interesting when you’re told which bike to bring and to put low gearing on it.

The view from the top of the hillside, one of the few spots with phone signal

The first part of Saturday was spent cutting out forest and marking out bits of course, hammering in road pins, putting up tape, stapling arrows and so on. It was hot work and I was using a heavy branch to smash through deadwood when the club like head on it it snapped and hit me hard in the nose which was the first incident of the day for me. I managed to embarrass myself stalling repeatedly in front of people in one section. Once you’re stopped on a slope, its a nightmare to get going again.

Later in the afternoon, after marking out was completed, they needed some course times. A group set out and I decided to tag on the back, at least I could check the marking out. In short order, I’d stalled the bike and they disappeared off into the distance, I never did see them again, several didn’t complete the course either. I continued on, coming across some interesting features like a nice decent with a steep, tree rooted climb on the exit to a stream. I gave this a go, mostly made it up but had to help the bike over a root. Later, people pointed out that this was the “expert” route and there was an easier alternative to the right but there was no track going that way visible at this point. This was taken at the stream crossing showing the choice of two routes on the Sunday after the signs had been tweaked:

So far the terrain was unknown and full of surprises, I then came to the bits we’d marked out and/or already ridden so this gave some let up. I was taking breaks periodically since otherwise, I was going to get tired and make more mistakes. I made a phone call on the top of the hillside with great views of the valley where there was phone signal. Shortly after than I managed to catch a rut badly, laid the bike down on its side and barrel rolled off it and down an incline. No damage to anything thankfully as I was going slowly. At some point I also ended up upsidedown on an incline with the bike on top of me which was fun. Periodically, there were interesting features like steep drop off sections. Again, apparently there were easier bits but I wasn’t understanding the marking of these correctly. In the special test section there was an interesting incline you had to go up which for some reason scared the living daylights out of me. They ended up taking out the crazy downhill then uphill section just after this as even though a few of us had made it around, it was going to cut up too easily with a few bikes around it.

Around this time, someone passed me and we exchanged a few words about me taking it easy and them suggesting “the best bits are to come”. I came to the piece of the course I’d been around so far and knew I could head back to the start from here. Since by this point I was suffering exhaustion, the sensible thing to do was to head back. I’d heard stories about having to jump ditches and a dry stone wall but I thought I’d done that part (that seemed easier than they were suggesting). There was definitely some steep hill climbs ahead though. Since I’d likely never do it again, I decided to continue, slowly and carefully. I soon came to the uphill section which was a relentless steep climb for a few hundred meters. Amazingly for me, I did make it to near enough the top without stopping. The bike was trying to stall, bogging down badly and I was determined we were not stopping and its probably one of the few times I’ve ever found the throttle stop. A decent followed, followed by what looked like more hard hill climbs but the hardest climb turned out to be behind me. A boggy trip through the trees brought me back to the start. I’d taken somewhere over two hours, the clubman time was about an hour. Experts would do four of the 12 mile laps, one was enough for me.

It was an early start on Sunday and I’d left the bike outside the van overnight so it was covered in frost. I had to scrape ice off the van windscreen too.

The start area

As a marshal, the idea was to roam around your section making sure everyone was ok, repair the route where possible and generally help out as needed. The section assigned to our group included the downhill section into the stream and another steep downhill section just after it. I did my best to roam around, yet keep out the way of the competitors and help out where needed. We’d also been asked to send people periodically to the starters point to help. I picked a good time to be there under the gazebo for the short downpour we had!

On the steep downhill, I managed to lose my balance on one trip down and ended up “choosing” a head-on collision with a tree into the headlight as the alternatives would have involved clipping the bars against a tree and leaving the bike. As it was, I stopped against the tree, restarted the bike and continued before the marshal behind slid into me (as there was no way he’d have been able to stop and I was conscious of this). Amazingly, there wasn’t too much damage as the light itself stayed intact:

This should be a straight bracket with the tax disc pointing outwards

The day’s activities were then complete and it was then time to demark the course and collect in all the arrows and tape. I helped out, ending up at the back of the group with a heavy paperbag filled with collected in material. I was about to set off once again, tried to kick the engine over to start it and found the kick start lever ended up on the ground. The kick start shaft itself had sheared leaving the casing in a mess too

Not how you expect a component to fail

Cracks = Not Good

I waited around but nobody came back far enough to find me although I did hear someone in the distance so I was on my own. No problem, I found a hill, bump started the bike and rode fire roads back to the start. Having a GPS on the bike helped!

It was a good weekend and I enjoyed it. I doubt I’ll ever enter an enduro, I think this weekend determined that for sure but I might marshal again if they’ll have me back though.

I can’t be the only “computer geek” who has someone tell them they need to get more fresh air or that they look pale and need some sunshine. In my case this got to the point my parents were making crypt and vampire jokes. it turned out there is a serious side to those comments which I’ve been meaning to write about for a while.

About this time last year, I was noticing that my joints were unhappy about something. In particular stairs were hard to climb up with my joints feeling at least twice my age with tearing sensations in my knees. This was along with various other aches and pains which were slowly getting worse. I’d also fractured my hand 9 years ago and ever since it had a dull ache at the fracture site, particularly after stirring gravy, painting or hammering in nails to a fence or similar activities.

On a different matter and nearly in passing, my GP suggested checking my vitamin D blood level and the test came back as borderline deficient suggesting Osteomalacia (in childhood much more commonly known as Rickets, eek!). Vitamin D is the “sunshine vitamin” being generated by exposure of skin to UV light. You get very little from food sources. A low level made sense in that I work indoors and when I do go out into the countryside and get exercise on the bike, I’m wearing layers of protective clothing and skin exposure is a bad idea. Sunlight exposure generating enough vitamin D in northern latitudes is questionable at the best of times and with a pale skin, any strong sunlight would trigger me to use suncream and hence block off the UV that would generate the vitamin.

Thankfully the “cure” is simple, either sunlight exposure (which here at this time of year isn’t going to work) or supplements. Having taken some supplements, I have to say it was amazing the difference they made with my joints no longer experiencing the tearing sensations and generally feeling a lot better. Also, totally unexpectedly, the fracture which ached when provoked stopped aching and has not done so since! There shouldn’t be any long term issue since the deficiency was mild and any issues reverse themselves with normal vitamin levels.

So if you spend lots of time in front of computers, make sure you get some sunshine too!

This may come as a shock to some, but I’ve just tagged Devil’s Pie 0.23 (tarball here).

tl;dr: don’t use this, but if you insist it now works with libwnck3

The abridged changelog:

• Port to libwnck3 (Christian Persch)
• Add unfullscreen action (Mathias Dalh)
• Remove exec action (deprecated by spawn)

I probably wouldn’t have ever released this as I’m generally not maintaining it and tend to push people towards Devil’s Pie 2 which funnily enough had a 0.23 release two days ago, but Christian asked nicely and I was waiting on a Yocto build to finish.

• Arduino-IRremote multi-protocol IR library
• MSP430G2xxx parametric search (also, parametric search for other TI MCU families)

Everyone knows that AVR is the king of open-hardware/hobbyist hill, as well as one of the most available MCU family, with most popular MCUs easily sourceable around the world in the nearest half-decent electronic component shop/martetplace. Why would you want to swap Arduino-thingy for something else? Many factors would need to play for that to happen, like price, availability again, and some issues with AVR.

Texas Instruments with Launchpad devel board for MSP430 value line pushes edge on price and availability, shipping candy to almost any country in the world for unbelievable price. And one of the issue I had with AVR MCU is inconsistency in their implementation (pin and register maps), which complicates MCU upgrade and code portability among the models.

So, MSP430 delivered with Launchpad felt like fresh air, and overall pretty cleverly and attentively designed MCU. Well, as folks who watch that space know, TI replaces the original Launchpad 1.4 model which shipped with MSP430G2231 with 1.5, shipping with MSP430G2553, without changing the price, which felt like generous move, and their desire to become real Arduino competetor.

Well, one of the issue which came with 1.5 was that it turns out that MSP430G2553 uses swapped assignment of RXD & TXD pins in its hardware UART comparing to (completely software-based) UART implementation with MSP430G2231. That could raise some eyebrows: because 1) couldn't Launchpad designers be attentive and design it originally as being compatible with entire MSP430G family (i.e. use hardware UART pin assignment right away); 2) if it really happens that MSP430G2553 was designed after Launchpad 1.4, couldn't TI engineers be so attentive to be compatible with existing UART pin assignment in their advertisement product, based on which quite a few people may judge entire MSP430 family.

But OK, stuff happens. TI was kind enough to provide a workaround to swap pins using a jumper trick. And well, you mostly use UART to communicate with "big" computer, so that jumper there was the only thing need.

And few days ago I ported my code to communicate with an SPI device (using a shield) from G2231 to G2553. First issue is that former vs latter use completely different SPI (etc.) communication controllers - USI vs USCI (yup, could have been named clearly to emphasize their difference). So, I was hit by the same issue I blamed on AVR - well, there at least if there's SPI controller, it works the same, even if some register addresses/bits might be different.

But once I ported software, I still couldn't get my device working, and it took few hours to check thru datasheets and manuals to find out that G2231 vs G2553 have also MOSI vs MISO pins swapped! Now, that's something to really frown about. It's not some random software-emulated UART pins misplaced on G2231 and corrected on G2553. In case of SPI, both MCUs have hardware SPI, so swapping pins is just that - big unfriendly "surprise" delivered in hardware developer's face. It would be too naive to think that it again happened by accident or mistake - conspiracy theorist would say it was carefully managemented and engineered incompatibility within family, designed to make users keep buying old low-power stuff and disallow easier upgrades. It's pure wonder they didn't get an idea to swap VCC and GND - indeed why not, few hundreds/thousands MCUs/devices burnt, and happy customers come back to buy more.

Aftermath of SPI swap is actually more serious than UART swap - again, UART is mostly used to connect to host, so you can set needed jumper position on it and forget (scalable solution is to keep using software UART and original pin assignment, as hardware UART is absent on quite a few devices and Launchpad is limited to 9600 baud anyway). But SPI is peripheral interface and the whole idea of Arduino and which TI also seems to push to Launchpad is extension modules aka shields. And SPI swappery means if you "just" make a shield for SPI device, it won't compatible with either old or new device (on hardware level). Would be pretty serious issue for folks who try to support Launchpad ecosystem, but surprisingly I found only one post on the issue, which again, means that folks are not aware, and unhappy customers may follow.

So, it's hard to say if TI should be blamed or vice-versa, thanked for being fare and show with Launchpad not only boons, but also drawbacks of MSP430 family. What's important are lessons learned (not just with this case, but with few other Launchpad hiccups):

1. Launchpad is not an Arduino.
2. Launchpad will not be an Arduino.
3. If you want nicely-working and user-friendly devel board, Arduino is always there.
4. If you want something cheap, Launchpad so far there too.
5. Expect Launchpad to bring issues and surprises, and break with new versions (ultimately, its price may break).
6. MSP430 is unlikely to displace AVR.
7. If you want to try MS430, check its availability. For example, in this part of the world, it's not possible to source small quantities of MSP430 value line, because well, nobody will get an idea to replace trusty ATtiny, so it makes no sense to bring them to shops. And nobody would get an idea to replace ATtiny because:
8. "Didn't break - didn't fix it." If ATtiny can do it, why bother with something else. That's not just inertness of thought, which industry/experienced people possess, that's actually proved by experience, as we saw. To change that, new product should do it much better than existing, but MSP430 doesn't want to do that.

• Using native Android USB Host API - kind of libusb within Android.
• USB Host for Nook Simple Touch Reader
• ELLCC - Project to bring decent cross-compiling support to LLVM (currently cross-compiling is rather neglected by LLVM mainline)
• Blueman - GTK+ Bluetooth Manager
• hidclient - Forward local input devices via Bluetooth HIDP
• Using the PlayStation 3 controller in Bluetooth mode with Linux - This is about "Sixaxis" game controller, not BD Remote, but confirms that PS3 likes adhoc pairing stuff instead of true Bluetooth one.

As some people know, I’ve had a little bit of a health scare recently as the first knuckle on my index finger was swollen with a variety of other pains occurring in my hand joints. This combined with some long running unanswered questions and a family history had my GP say effectively “eeek, rheumatoid arthritis?” just from showing him my hand with no other comment. Thankfully blood tests for RA are negative, as are the other blood tests for more exotic diseases they decided to run just in case.

Six weeks on, this raises the question of what is wrong with it since its not really much better and one side of the joint is still swollen. The conclusion is its literally collateral damage, specifically a torn collateral ligament. Its likely this was pressuring tendons causing problems elsewhere and generally confusing things. Treatment is to keep it moving, gentle use. Time to heal, up to 18 months. It could be worse,at least I know what it is now.

Knowing what I do now, how do I suspect I did this? I have a suspicion trying to undo the front sprocket nut on the YZ might have been the trigger. That saw me jumping on a 2m pipe over the ratchet to loosen it in the end.

Thursday and Friday was Ixion@Cadwell 2012. Cadwell Park is a race track suited to motorcycles in the middle of rural Lincolnshire. The way it makes use of the natural landscape to form one of the UK’s most technical motorcycle circuits is to me, beautiful, I’ve loved it since I first saw it as a spectator. The event consists of a day, an evening and another day of track time in three groups (Tiggers, Piglets, Eeyores) and this was the eighth time I’ve been. As a piglet, I know my way around the circuit but am schizophrenic often showing eeyore tendencies to admire the scenery and only occasionally showing signs of the bouncy fun of the tiggers who tend to like the scenery so much they are known for engaging in close examination of it. This year they colour coordinated the wrist bands so mine was a lovely piglet pink.

The view from the clubhouse showing the track entry, the top of the mountain with the pit straight and the entry to the mountain in the background

I missed the event last year so it has been a while since I’ve been to Cadwell and I’ve not done as much riding of the Daytona as I’d like having given priority to the trail riding. Thursday was red hot sunshine. The first session is the infamous “no-brakes” drill where you ride around the circuit without touching the brakes. I love the fact you can still go over 100mph down the straight, scrub the speed off up the hill into Coppice and not have to touch the brakes, that has to be my favourite corner. I also discovered you can go around Mansfield quicker than I’ve typically done so in the past. It helped being as hot as there was no worry about any moisture affecting traction and the tyres were extremely sticky. Since I’m not commuting on the bike it does have sports compound tyres on it which helps (dual compound commuting tyres on the VFR were never as sticky).

It took some time to remind myself which gear to be in where on the track, I quickly remembered not to use first gear anywhere after I attempted it. Some corners I seemed better on (Hairpin, Mansfield), others I seem to have regressed (Charlies 1, Barn). In the first proper session I was surprised to find the front end going light over the mountain (front wheel in the air) as I hadn’t intended it and try and avoid it. The offroad riding does seem to have helped as I was much less unhappy about it than I would once have been.

The Hairpin

Hall Bends

I had a session with one of the new instructors following and then leading me which was interesting. It highlighted that I was disjointed between Coppice and Charlies which is something I tried to work on without an awful lot of success during the day. Other than that, the usual advice still applied, “just go faster”, my lines were basically ok.

At lunchtime I topped off the fuel tank with 10L from the cans which I was hoping would see me through the day which it did (the fuel light came on for the last two laps of the evening session). The evening session was split into two groups, Pigores and Tiglets of which I opted for the former. It highlighted that whilst I could circulate at a faster pace than some of the Eeyores, I have little experience of overtaking and was very reluctant to do so other than down the straights where I could use the 675’s acceleration and straight line speed to my advantage. Right at the end there wasn’t enough time for two sessions so they announced an open pit lane. I took a short break, then went back out for a final session. The organiser came past me at the end of park straight and I was quite interested in his line and the way he went into Park. The trouble was I was so busy paying attention to that I forgot to brake myself and steamed into the corner at a much increased speed. I did touch the brake slightly on the apex but managed to force myself to leave it alone and hope the bike would go around the corner which it did, being capable of much more than the rider. In total I covered 186 miles on the track on Thursday, which is quite some mileage given the concentration required for that kind of riding. I added a further 10 miles to refuel the bike at the end of the day.

Friday started with another no-brakes drill which I have to say are a useful learning exercise. The day was cloudy and the temperatures were much lower. After the no-brakes drill the front tyre didn’t look well, covered in peeled rubber that had stuck back on (“cold tearing”?). After the first session it was much worse and also I realised rather cold compared to the temperature it should be. I ended up dropping the front tyre pressure quite considerably to get it to match the wear and temperature of the much healthier looking and warmer rear.

Whilst I have no evidence of it, I think I did slowly make improvements to my speed around the circuit through out the day. Towards the end of the day, I was talking to someone about improving and whilst I could do some things they mentioned (e.g. find the throttle stop on the straight and avoid braking for coppice at least some of the time) there were other things I could definitely work on. They also mentioned an interesting tip about going deep into charlies 1 so that you could accelerate for park straight earlier. In the next session I went into that corner knocking off 15% speed to try the different line which did seem much nicer. It was so much nicer I arrived at the end of the straight with much more speed than I’d ever done before and had to brake considerably harder for park which made life interesting. They happened to be circulating in that session and I followed them into coppice as they overtook me at that point, roughly carrying the same speed at entry. What was clear was that I was losing speed at the corner apex at which point they steamed away from me at a point where I do feel I want to go faster but I’ve lost momentum. It showed exactly where I’d need to carry more speed and another rider who overtook there demonstrated the same effect. Something to work on next time. In the last session of the day, the fuel light came on again, beautifully timed.

I covered 285 miles on the track over the two days and 370 miles in the van getting there and back. There were a few crashes although thankfully it was mainly damage to people’s wallets. It was noticeable how many other 675s there were this year, they’re becoming common with about six of them there! They still look best in red to me though and despite being repeatedly told otherwise, there was only one red 675 there (which people were confusing with a red CBR600).

At work I received a request to figure a gstreamer pipeline that streams uncompressed raw videodata over the network. I couldn't get that to work, but I did get jpeg streaming to work.

On the beaglebone:

root@beaglebone-cam:~# gst-launch -v v4l2src ! video/x-raw-yuv, width=320, height=240 ! jpegenc ! rtpjpegpay ! queue ! udpsink host=192.168.2.12 port=1234
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)YUY2, framerate=(fraction)30000/1001, width=(int)320, height=(int)240, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)1/1
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)YUY2, framerate=(fraction)30000/1001, width=(int)320, height=(int)240, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)YUY2, framerate=(fraction)30000/1001, width=(int)320, height=(int)240, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstJpegEnc:jpegenc0.GstPad:src: caps = image/jpeg, width=(int)320, height=(int)240, framerate=(fraction)30000/1001, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstJpegEnc:jpegenc0.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)YUY2, framerate=(fraction)30000/1001, width=(int)320, height=(int)240, interlaced=(boolean)false, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstRtpJPEGPay:rtpjpegpay0.GstPad:src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG, payload=(int)96, ssrc=(uint)718095921, clock-base=(uint)3383403273, seqnum-base=(uint)55954
/GstPipeline:pipeline0/GstRtpJPEGPay:rtpjpegpay0.GstPad:sink: caps = image/jpeg, width=(int)320, height=(int)240, framerate=(fraction)30000/1001, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstRtpJPEGPay:rtpjpegpay0: timestamp = 3383404627
/GstPipeline:pipeline0/GstRtpJPEGPay:rtpjpegpay0: seqnum = 55954
/GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG, payload=(int)96, ssrc=(uint)718095921, clock-base=(uint)3383403273, seqnum-base=(uint)55954
/GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG, payload=(int)96, ssrc=(uint)718095921, clock-base=(uint)3383403273, seqnum-base=(uint)55954
/GstPipeline:pipeline0/GstUDPSink:udpsink0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG, payload=(int)96, ssrc=(uint)1629878785, clock-base=(uint)3913073808, seqnum-base=(uint)17913

Change the IP-address marked in red to the host you want to stream to and write down the caps marked in bold at the bottom.

On the client, paste in the caps you wrote down earlier:

[koen@Angstrom-F16-vm-rpm ~]$ export VIDEOCAP='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG, payload=(int)96, ssrc=(uint)1672478509, clock-base=(uint)3352394115, seqnum-base=(uint)22369'

And launch the viewer:

[koen@Angstrom-F16-vm-rpm ~]$ gst-launch -v udpsrc port=1234 caps="${VIDEOCAP}" ! gstrtpjitterbuffer latency=100 ! rtpjpegdepay ! jpegdec ! cogcolorspace ! videoscale ! autovideosink

Last weekend should have been the Northumbria TRF Forest Trail Ride. Unfortunately that got cancelled by the Forestry Commission due to the amount of water logged ground. We offered the attendees a trail riding weekend instead.

Friday night wasn’t promising with rain pouring down all night. The camping field drains really well but even that was covered in pools of standing water. Its times like this I appreciate having a decent tent. Saturday morning arrived and amazingly whilst everything was wet, it was not raining. I had a choice of leading a group of four other locals or taking some visitors out and opted for the locals. We set off and on the second trail, one of the members bikes stopped and wouldn’t start. We spent a while dismantling various bits of the bike, draining off the float bowl and ended up changing the plug. It started and seemed to be working again. At the next short trail, I reached the end and there was nobody following. I had seen them turn off for it. I headed back to find the bike had died again. We ended up arranging for him to get picked up and we continued with the route.

We soon ran into the another group who were basically doing a similar route. They’d given time to let us get ahead but the breakdown had set us back. We devised a plan to overtake them by filling up at a different fuel station and this went to plan and we overtook. We were also skipping some of the trails due to the amount of water and the likely bad ground conditions on them.

After a few more trails, I noticed on a road section that the bike was revving a lot more freely than the changes in speed would suggest. Either the wheel was slipping, or the clutch was. The next trail proved interesting with the bike not behaving as it should being hard to pull away, stalling and generally being snatchy. I also noticed the clutch cable had no slack in it, in fact being more like a banjo string. I stopped and checked the adjusters which were all maxed out, never a good sign.

I’ve had a complete clutch failure before and I vowed then that if I ever had signs of one again, I’d stop and head home whilst I still had drive. I therefore made my apologies to the group and headed back to the camping field on my own. I was back there by 1pm. Thankfully, because the group were locals, they could find their way to the lunch stop without me where they joined with group we were trying to stay ahead of. If I’d been leading the visitors there would have been a more significant problem.

The problem also meant that I was out of action for Sunday although with the light drizzle falling on Sunday morning, I wasn’t too upset about that. At least the problem should be a simple fix with a new set of clutch plates likely to resolve the problem. I did have a look at the clutch when I got back and the steels are in good condition with no notches on the clutch basket either.

Today, North Tyneside was hit by the kind of storm you usually only hear about or see on the news. I watched from my office window looking out over the bay as the sky got darker and darker to the point cars started using headlights, the sky was like a stroboscope and there was the gentle rumble of thunder in the background. The rain then arrived, hammering down and soon there was a river flowing down my street, on both the road and pavement. I couldn’t stop grinning, I can totally sympathise with storm chasers!

The police were soon on the scene to block off the road since it was flooding on the corner just down the road. I wasn’t too worried, there is a cliff and the water can only get so high. The back of the house is more of a risk but they’ve just put new special storm drains in there.

Its not often I get interrupted by a phonecall when in a meeting but I was, by my Mum who after discussing sausages mentioned in passing she was worried about their house and car and the rising water levels. With my Dad being away, I agreed to go up there. If its that bad out there, my only car option, a Mazda MX5 isn’t really appropriate. Easy, I’ll just use the YZ. I grabbed my road bike gear, put a change of clothes in plastic bags which in turn went into the backpack and set off. Traffic was chaotic as cars are allergic to more than 3″ of water and were driving all over to avoid it. I just rode through it all no problem, maybe 12″ on one roundabout.

So far so good until I tried to get into my parent’s estate to which the entrance was flooded. If I’m put off on a YZ, it must be bad. I did ride into it and made the mistake of going too slowly and carefully and the bike stalled. No chance of restarting it in water that deep (say 2.5-3ft) so I pushed it around to my parents house, rather annoyed with myself. The photo above is of the junction after the levels dropped a bit. Its hard to picture without knowing the area but the roads under there drop quite a bit level wise.

My Mum’s car, parked in the road was certainly at risk if the water got any higher so I moved it onto the drive. The house itself seemed to be ok, the risk would be flooding from the rear and the drains were holding up and draining.

The street around the corner was where the water was coming from and was also like a river. Basically, water off the fields behind the estate had nowhere to go other than through the estate.

I think a lot of people were lucky. Here it looks like the water made it up to the air bricks in the underfloor space but with any luck it didn’t make it into the house itself.

I went for a look around. This pond is where all the water above flowed to about half a mile away. There would be some very underwater houses here

Here, the road has been blown out by a sewer pipe bursting. When I rode over this on the way to my parents, there was water flowing through those cracks.

No surprise that this underpass was flooded. I didn’t try the bike through it, its deep in there even for the YZ.

The remains of the flood at the bottom of my street. I did ride through this one even it was cordoned off.

I went for a walk on the seafront and came across this on the upper promenade. Under Whitley Bay sea front, there is a 3m diameter storm sewer/storage pipe which runs for several miles. The idea is simple, when it rains, this gets used as a giant tank which fills and they can then slowly process the water later. Here, one of the access points to this huge sewer has been blown open. You can only imagine what that implies.

Here is an illustration of what it must have been like on a small scale. This is on the lower promenade where some of the storm drains were still lifting the covers and overflowing onto it. It looked like some kind of large scale water feature from this angle.

The water patterns in the sand here indicate the water must have been seriously flowing off the lower prom onto the sand.

I couldn’t resist ending with a shot of the sunset. This is basically the view from my office, the camera not doing the colours justice. The bay sweeping around ending with the lighthouse. Blyth’s piers and wind turbines silhouetted in the background. Beautiful.

As many folks who start with hobby electronics design, I started with Eagle, because that's what most of other folks seem to use. I was able to produce a simple board, but fairly speaking, I have mixed feelings about it - both UI, structure, and functionality could be better.

I didn't try KiCAD right away because I read lot of (apparently old, or FUDish) notes that it lacks basic features, unstable, and complicated. I finally got to try fairly recent version of KiCAD and was astonished how logical, fairly easy to use, and well-performing it is. Yes, it is still could do better, for example, it's hard to understand what precludes to use direct manipulation GUI, where you can drag an object with ... dragging an object with mouse, but at least commands for manipulation are standard, complete, and available via context menu. So, doubts off, KiCAD should be *the* toolkit for Open Hardware.

So, what are the outstanding features of KiCAD?

• Separation of schematic symbol vs PCB footprint - they are not linked in the component library, but instead are linked as part of PCB design process
• Text-based formats for all files

One of the reasons why Eagle is advertized as suitable for beginners and community in general is availability of many component libraries. Indeed, some parties go out of their way to create own, adhoc, from-scratch, and thus hard-to-reuse libraries. But this problem is virtually not existent with KiCAD due to the design features above.

Of course, its standard library contains all/most discrete components. Next, for infinite number of ICs, you don't need to draw each of them in all possible and impossible packages - there's finite number of packages, KiCAD already has great selection of, and you can create missing once and reuse it for new chips very easily. Secondly, a schematic symbol for a chip is a rectangle with pins sticking out of it, so to "create" a new chip, only pin names needed, the rest can be easily scripted thanks to text-based format (and there're existing tools, albeit they don't seem to be open-source).

Now few notes about installing. Current version of Ubuntu ship rather old (one-year as of writing) version of KiCAD, only upcoming Quantal ships (as of now) 0.20120526+bzr3261-1, and that's what I downloaded and installed manually on Precise (12.04) without any issues. There's also daily builds from trunk, and that's what I'm going to try next, just wanted to start from a known stable reference. So far, I had one crash with 0.20120526+bzr3261-1, without any adverse effects.

Don't forget to install package kicad-doc-en. Unfortunately, Quantal's version still includes older version of tutorial, you need latest version called "Getting_Started_in_KiCad.pdf", you can find it here. Following the tutorial will give you complete walkthru of KiCAD workflow, enough to produce your boards, including custom components.

Part two of the coast to coast write up is now at http://www.rpsys.net/wp/rp/c2c/index2.

The day for the coast to coast arrived, we made it to the meeting point for 2am, set off in the Lake District from the west coast at 5:30am and headed for the east coast. The trip was not without incident although that wasn’t really a surprise.

People have been asking how it went and I’ve shared part one of a write up at http://www.rpsys.net/wp/rp/c2c. I’d warn its long and has lots of photos, mostly stills taken from the video footage. I took 20GB worth of video footage of the trip but there wasn’t time to stop and take photos, not that you could carry a decent camera trail riding anyway. Its taking some time to write up but I’ll try and get the rest of the write up completed soon.

“Coast to Coast” trips from the west to east coast of the UK are fashionable at the moment, be it walking, cycling or otherwise. For me, this weekend’s challenge is covering ~250 miles of green lanes by motorcycle, starting on the west coast near Ulverston and ending up near Alnwick on the east side, all in one day. Anyone with a map will notice this is a diagonal crossing, not a straight line and the route itself is even more convoluted to incoropate a good selection of lanes. There is a wide selection of terrain, including some deep fords which anyone reading this blog will know are associated with Alnwick.

All seemed to be going well with perparations, even my complete lack of transport for the bike on the day in question was to be resolved by dropping it off at a collection point in advance when I could borrow a van. I’ve decided to use the YZ over the CRM despite the CRM being the logical choice (better tank range, oil tank, comfy seat) mainly on fun factor although it also has the better tyres on it. I was about to put the YZ into the van to transport it and thought “I’d better just check it starts”. Turning on the fuel lead to a puddle forming under the bike with a continual stream of fuel flowing from the overflow pipes. Hmm, not good.

None of the normal tricks to resolve this helped so it was back into the garage where I removed the carb, along with half the bike or so it seemed after letting the person at the collection point know I’d be “a bit late”. I’ve never dismantled this part of the YZ before but that wasn’t going to stop me. There was gunge in the carb and the fuel valve seemed to operate ok with things cleaned up. The floats weren’t holed or anything nasty like that and once back together, it started and worked with no fuel leaking. I didn’t have any bits left over either which is always good.

I’m hoping this is my share of the mechanical gremlins and I’ve got them out the way now. The bike is waiting ready for us to meet at 2am on Saturday (tomorrow) at the collection point from where we set off to get dropped off in the Lake District. Then the fun begins!

One memory that springs to mind this evening is something tglx said at a plumbers conference about modern Linux hackers of the modern generation not being able to hold to traditional values, like properly enjoying beer!

I think this evening we proved that wrong. If the team here in Romania was trying to get me drunk, they’re going to have to try harder but it was an enjoyable evening and I think there are people who appreciate those traditional values, long may it continue!

Following cool solar experiments at jeelabs.org, I also got idea to attach something to a solar cell. But first, figure out what types of them exists and available. Regarding the first, you can read in Wikipedia. But that's example of dried-out wikipedia article, giving a lot of formal facts, but little practical knowledge. What I'd like to know is what types are typically available in small consumer products.

Here's what I researched. First type is brownish, with regular vertical or horizontal lines. It's the type of solar cell which have been see for at least 20 years in calculators. So, that's amorphous silicon solar cell, less expensive (explains why we had it for 20 years around) and less efficient, they say. But they also say that there're special subtypes, designed to work in low-light conditions (specifically, provide enough voltage, even though current may be miniscule). Here's how it typically looks:

Last years, another type became widely available in cheap stuff - crystalline silicon solar cells. In cheap stuff, they look like black (or dark) colored plate, covered with few millimeter of something like epoxy, in which you can clearly see metal wires - oftentimes in irregularly spaced groups. Looking closely, it can be seen that epoxy actually holds individual bars of crystalline silicon, and irregular spacing of builtin wires are in particular due to irregular cuts of these bars in the original wafer.

Here's close up:
They say that crystalline is more efficient than amorphous, but more expensive. Explains why we started to see it around much later than amorphous. There's also mono-crystalline and poly-crystalline varieties, the first being more expensive, so my guess is that in cheap stuff we have poly-crystalline. It appears that small-size crystalline are rated for smaller voltage (2v) than an amorphous, which you can find for ~5V.
They also say that under dimmer lighting, crystalline cells provides reduced voltage.

Here's what I've been hacking for some time now - a Python module which allows to run Arduino, etc. code on a host computer, while still allowing to access Arudino (etc.) hardware. Of course, this is very obvious idea, so announcement of such project should proceed with explaining why yet another one? Two requirements I had was: using human readable/writable underlying protocol for communication with the board and being as much as possible compatible with original Arduino API/syntax. Regarding the latter, Arduino wiki's Interfacing/Python lists few modules which allow to control Arduino from Python, but you may find it amusing how they go out of their way to deviate from standard Arduino API (I saw as funky stuff as "board.digital[13].write(1)", but even the humblest has digital_write() instead of digitalWrite()). On the contrary, with Arduino Hosted, standard Blink example looks like:

arduino.init(debug=True)
from arduino import *

def setup():
    pinMode(LED, OUTPUT)

def loop():
    digitalWrite(LED, HIGH)
    delay(1000)
    digitalWrite(LED, LOW)
    delay(1000)

arduino.run(globals())

That's pretty direct translation of C code (plus few idioms), and directly translatable back to C. And that's idea - you prototype and debug code in hosted environment, and then can easily translate it to native code (to keep debugging on, because latency of of hosted and native execution is quite different which hides/adds lots of timing issues).

Regarding the board communication protocol, I knew about BusPirate before that, and was really happy to find Joby Taffey's BusNinja implementation for Arduino. Even more, I found the implementation for TI Launchpad from the same author (Launchpad's version somehow named "SPI Explorer"). So, BusPirate's protocol with extensions is what I based on. Of course that doesn't too well, especially with TI Launchpad, which has particularly crippled UART support. Other issue is that BusPirate (even binary protocol version) supports working with only one bus at time. That's fine for BusPirate's original purpose, but limiting for a project like this (well, so far I didn't have to use I2C and SPI at the same time).

What about Firmata? First of all, it doesn't support SPI, and working with SPI devices was the immediate need behind implementing this module. Secondly... Well, there's a saying "If the only thing you know is a hammer, then any thing around looks like a nail." That's must have been the idea behind designing a MCU control protocol basing on MIDI protocol. NO WAI.

Tutorials

Have a look at these websites to get an idea of what people have been working on.

The Ångström website has links to various tutorials and projects, you can find it at http://www.angstrom-distribution.org/

Limor Fried of adafruit.com fame has started a colletion of beaglebone related tutorials of one which deals with wifi: http://ladyada.net/products/beaglebone/index.html

Dan Watts has a number of tutorial on how to use the GPIOs and PWM pins: http://www.gigamegablog.com/tag/beaglebone/

Graeme Gregory has published an example kernel development workflow: http://www.slimlogic.co.uk/2011/05/openembeddedangstrom-kernel-workflow/

Reinstalling

To reinstall the SD card image you can completely reimage the SD card:

Visit http://downloads.angstrom-distribution.org/demo/beaglebone/ and get the img.xz you want. Then find out which drive corresponds with your SD card reader:

$ dmesg | grep sd

The output should look something like this:

sd 8:0:0:0: Attached scsi generic sg4 type 0
sd 8:0:0:0: [sde] 7626752 512-byte logical blocks: (3.90 GB/3.63 GiB)
sd 8:0:0:0: [sde] Write Protect is off
sd 8:0:0:0: [sde] Mode Sense: 03 00 00 00
sd 8:0:0:0: [sde] No Caching mode page present
sd 8:0:0:0: [sde] Assuming drive cache: write through
sd 8:0:0:0: [sde] No Caching mode page present
sd 8:0:0:0: [sde] Assuming drive cache: write through
 sde: sde1 sde2

This shows that it detected a 4GB card and assigned it to /dev/sde. In the next steps replace /dev/sdX with the name from the previous step. Be very careful with this using the wrong name can result in an erased hard drive.

To reimage the SD card do the following:

$ sudo -s

(type in your password)

# xz -dkc imagename.img.xz > /dev/sdX

# exit

This will take more than 20 minutes, usually 45-60 minutes, depending on the speed of your card reader and SD card.

Rebuilding

The SD card image in the box is based on the Ångström distribution. All Ångström binaries are built using OpenEmbedded. This document describes the steps necessary to setup an environment where you can rebuild the images and packages yourself.

The build is managed by scripts to make things easier, so get the setup scripts:

$ git clone git://github.com/Angstrom-distribution/setup-scripts.git

If you are behind a firewalling proxy, have a look at the oebb.sh file, it has built-in proxy handling.

Configure the setup scripts for the beaglebone:

$ MACHINE=beaglebone ./oebb.sh config beaglebone

Start with a kernel build:

$ MACHINE=beaglebone ./oebb.sh bitbake virtual/kernel

Or a small command line image:

$ MACHINE=beaglebone./oebb.sh bitbake systemd-image

Or rebuild the SD card image:

$ MACHINE=beaglebone ./oebb.sh bitbake cloud9-gnome-image

I would like to quickly introduce the Poettering scale of software awesomeness. The scale appears to be number of features over time, the higher the number the better. Evidence has shown that this scale is the best to compare software and should be used whenever one needs to decide on competing projects.

OpenGL and Devices

Historic Approach

Device Profile Proposal

Key Features

Supported Devices

BlueCore4-Ext is a popular Bluetooth chip used in many Bluetooth modules, some priced below $10. The idea is to create Wireless Sensor/Control Network using this modules, as Bluetooth is really ubiquitous technology nowadays, so any smartphone can be used to provide user UI/control for such network. This is especially facilitated by the fact that BlueCore4-Ext is a SoC (system-on-chip) integrating microcontroller and peripherals in one package (small too), allowing it to be programmed with a user firmware for autonomous functioning with minimum of additional components. It even has built-in temperature sensor, so just add a battery and you have ready-made wireless temperature sensor (not too precise, granted, but you can calibrate it yourself ;-) ).

(Image by robocraft.ru)


BluTuNode is a firmware for such a Bluetooth Wireless Node, which allows to control it from a host over the air.

Source code: http://github.com/pfalcon/blutunode

Features implemented:

• Full control of GPIO: input/output, configuring direction, pullups/pulldowns, etc.
• Reading sampled from build ADCs.
• Reading of temperature sensor.
• Querying other system parameters.
• Querying Bluetooth parameters.
• Poll mode, when module automatically reads some sensor at specified period and sends information to host.

Features planned/ideas:

• UART control (note that this is generally not a priority, because UART is mostly used to connect to host/microcontroller, and this firmware is designed for autonomous modules).
• SPI/I2C/1-wire support to connect external sensors.
• More Bluetooth-level information and control.
• OpenSource tools to program/manage BlueCore modules.
• Flash access/writing, over-the-air firmware updates.

Appendix:

Some technical characteristics of BC4-based module:

SoC: BC417 (BC417143B full model ID)
CPU: XAP2+, 16-bit RISC (no special 8-bit data support), Harward architecture, 64Kword data space, 1Mword+ code space
Flash: 1Mbyte (512Kwords, 75% typically occupied by Bluetooth stack/OS)
RAM: 24Kword
Execution environment: Virtual machine, no native hardware access (later versions of firmware OS support "native" mode, heavily bounds-checked still).