Just before I leave for Christmas ..

There should probably have been more of these updates, but we've been a bit busy here and so the blog hasn't been getting the attention it deserves. That'll hopefully be rectified soonish.

Anyway, the news in brief:

• Advanced STB: we have a prototype OMAP3530-based STB design for which we've got boards back now, based on the ever-popular Beagleboard - SD only, but if I can fire up the DSP we should at least be able to decode SD versions of all the obscure codecs that no-one's ever heard of. Now all we have to do is write the firmware.. (and work out how the HD version will work).
• USB IR widgets - would have been on sale except that someone's gone and bought all my spares. So: if you want one, do comment here or drop me a line and I'll get one sent out as soon as the next batch is ready. They'll hopefully be available via convenient web shop early in the New Year.
• I've recently been doing quite a bit of work with GWT and Hadoop; both seem fairly sane and sensible. Something of an odd feeling to be back in a development regime not dominated by the cost of bugs - you start to realise that project planning does work for some people, somewhere.
• Site of the day: http://www.h265.net . The idea of H.264 performance / 3 frankly scares me - especially in 3D. Time for those parallel-decode assurance flags people have been muttering about.
• tibs has been doing some work on muddle, with the result that it's now faster, better, shinier, etc. Domains now work in a meaningful way and I've now churned out enough build trees that I'm pretty confident it's not going to fall over on anyone immediately.

Anyway, a good Christmas and New Year to everyone (anyone?) reading this; I'm off for a few days' relaxation (see, I told you I would one day..).

maintaining muddle feels a bit like being davros

As a result of some recent changes to muddle - mainly tibs's code - you can now merge two build trees (which we call domains) into a single overarching build tree.
I've now added a couple of bits (check out r243) and I have a bit of a port of an ASTB build tree and a client's STB stack running.
With the addition of a couple of simple hooks on each side, I can write 100 lines of python which automatically checks out two entirely unrelated build trees, merges them together, builds them both (on demand, checking out code from various repositories in git, svn, and bzr, and supplying the right kernel includes across the boundary) and then merges the resulting filesystems. On demand.
It's not finished yet, but it's quite impressive to watch it go.

USB widgets are go (part 2)

Well, we're getting there on the USB IR widgets - we now have Creactive doing some industrial design for us on the casings and the second spin of prototype PCBs is at the shop - back next week, hopefully.

Our core consumer functions are as they always were - will work with any RC5 remote control, programmable via USB serial port, no install on any major platform. As a result of having sourced some cheap remote controls, we'll also be supporting a proprietory NEC remote protocol and selling moderately cheap dedicated remotes to anyone who wants them (to control your model railway, for example).

We've managed to cram on a few new features for the geeks this time:

• Boards can be made using 3.3V or 5V parts.
• SOT-23 LDO so you can power the boards from somewhat unregulated supplies - eg. to use them without being plugged into a USB port.
• UART, I2C and SPI brought out so you can use them as bridges (not all at the same time, though).
• More I/Os brought out so you can have ADC inputs and control pins.

And we should be able to open-source both the schematic and the software, though as the software is still encumbered by Microchip's licence for the USB code it sadly can't be GPL.

Oh, we've lopped a couple of millimetres off the size in each direction too :-).

Anyway, watch this space and do get in touch if interested - early product should be available soon and if you ask us nicely we'll sell you some of the pre-production batch.

Grr. Apologies if the code examples in the previous post are truncated at the right - this is because of the way blogger tries so hard to make the blog a nice column down the middle of your browser. Which is a laudable aim for a plain text article, but doesn't work so well for code examples. If I have time I'll look into it (some more) in the future (I've already tweaked the blog settings to try to make previous posts look sensible).

Update: OK, I think I've fixed that. Now on to trying to make "cut" work in posts...

muddle: Cross-compiling V8

So, I'm transferring a native (Intel) build of various things to a cross-compiled build for the ARM (specifically, for my beagleboard).

Today's tasks were sqlite (which was harder than I expected) and V8, Google's open source JavaScript engine.

We're hiring!

In case you hadn't heard:

Kynesim is urgently in need of developers to expand our team.

We're a small, friendly technology consultancy firm located on Castle Hill, Cambridge with strong links to the University of Cambridge, for which our Managing Director routinely teaches.

We provide top flight hardware and software development services to a variety of clients; mostly doing STB work, embedded Linux (although WinCE expertise welcomed), quite a bit of wireless/embedded micro stuff, but we have been known to do everything from soldering bits onto PICs to writing web applications. We have an outstanding track record of delivering complex and challenging technology on tight deadlines.

Code is mostly in C and C++ with a smattering of assembler, Python and Java and a surprising amount of Javascript and HTML. C# is hovering threateningly on the horizon. A good working knowledge of C and/or C++ is essential.

Starting as soon as possible, this role would suit Computer Science or Maths graduates. We aim to recruit bright, hard working people willing to muck in with challenging tasks they may not have met before.

In return, we provide a decent salary, free food including a pub lunch on Mondays, interesting work, a Playstation 3, proper flexitime and occasional soft toys.

Sound fun? Contact Richard Watts for further details.

The FOSS community finally gets a dose of China ..

I notice that the FOSS people are finally being bitten by the Chinese problem. The rest of us in CE have, of course, had this problem for years - there are manufacturers out there whose business model is to buy a new product, suck the software image out, reverse-engineer the hardware and then sell their own cut-price version - and more OEMs who do this on the side, selling off-label cut-price versions of the products they make for western consumers to the generic domestic market, from where they naturally turn up here.

There's no effective way to stop this short of tivoisation, which is why it's such a popular tactic and why GPL3 is particularly invidious in CE: none of us want to tivoise our products - it's stupid, time-consuming and difficult (plus we want to hack them ourselves). But if we don't, we get maybe two months' grace before our software gets knocked off and the product driven off the market.

This is a natural side-effect of Asian manufacturing economics: anything you make in the UK will always be more expensive than in the far east, because the far east has much lower regulatory compliance costs - they're allowed to run machines that no-one in the UK would countenance, under lax employment law and with no IP enforcement to speak of.

So perhaps the free software community will be a little more forgiving to those of us who lock them out of our products in future; we're really not that evil (well, some of us aren't) - just trying to get some sort of return on our investment before we're instantly outcompeted.

Marketing

At a team discussion yesterday, we realised the marketing potential of my cast. This is what we came up with.

IR Widget - the next step

Hello all,

Just a quick update on the IR Widget.

Trying to control games consoles has proved a little difficult - it appears that not all of the controls for video playback on the PS3 (for example fast-forward, rewind) can come from a keyboard. The only available controls are: bring up a menu, navigate around with the arrow keys and select the appropriate option. The situation is similar on the XBox 360. While this is functional, it's not so nice to use - we want now for the widget to pretend to be a games controller as well as a keyboard, as that has buttons to do what we want. However, this could take a little while to implement due to memory constraints. Richard has offered to solve this with some refactoring and buffer sharing tricks.

I have now added some functionality to allow us to send modifier keys (ctrl, alt etc) which it turns out are essential for some of the media controls in Linux.

I have also now made the programming interface work under OS X, although Windows is a little more fussy - I'm still messing around with INF files.

Work still in progress, so keep checking back!

muddle: Linux on the Beagleboard (part 0)

I've been playing with a beagleboard at work, as part of the initial investigation towards an advance STB (set top box). It's based around TI OMAP technology (so it's got an ARM with a DSP on the side).

Anyway, my initial investigation put Android on it (in a fairly dumb manner), and I've spent the last couple of days getting the head-of-tree OMAP Linux to boot on it, with busybox. This last I hope, when it's a little more polished, to use as a replacement for the "simple linux" example in the muddle distribution.

Anyway, here as a teaser is today's version of the build description for OMAP Linux on a beagleboard:

Handy hints for debugging optimised assembly, number 2431

If you're trying to see what effect your optimisations have on assembly code, a useful hint is often to put volatile assembler labels at strategic points in your code.

asm volatile ("foo1:");

in GNU C/C++ source will turn into something like:

#APP
# 667 "src/iatools.cpp" 1
 foo1:
# 0 "" 2
#NO_APP 

in the assembler. This may have some slightly adverse effects on the optimiser (though not too many - labels have no side-effects), but it means you can bracket loops you're trying to optimise quite successfully without having to read the runes to work out which bits of assembler correspond to which bits of C.

USB, meet Infra-red

Been looking at this for a while now, and we've finally got something working.

This little widget will allow us to use an infra-red remote to control media playback (or do pretty much anything else) on pretty much any PC without the need for additional drivers (so long as it can support a USB keyboard).

It is programmable over USB using a simple command line interface allowing the user to configure it on a per-button basis. Currently working on configurations for controlling a PS3 for video playback.

More work being done, so watch this space!

XUL ain't so bad after all ..

I've been doing quite a bit of XUL hacking lately and I think it's actually beginning to make sense. The main problems seem to be a lack of documentation and Javascript's usual habit of trying to continue in the face of overwhelming odds which means you don't get told about errors at the point of error, but some unspecified time later.

In particular, it took me a while to work out that if you set your browser.chromeURL property to XUL without a browser marked as type=content-primary, your entire XUL gets replaced with the target window content. Any linked Javascript then runs twice - once just before the XUL gets replaced, tricking you into believing that your XUL is fine - and then again afterward for some reason.

There's also a slightly odd interaction of command-line arguments with windows: the primary window gets window.arguments[0], subsequent window.open()'d ones don't and if your content is doing the open, you need to resort to slightly nasty tricks like setting properties in window listeners. Ugh.

In other news, I'll be at ESC UK in October and at IBC on September 14th and 15th so hope to run into people there.

In case you hadn't guessed, I like muddle. I was formally convinced (i.e., by practice rather than theory) a few weeks ago, when I had to work on a system that already had a muddle description (in fact, the same system into which "george" was being incorporated). With muddle, it was quick and easy to add new software to the system, trivial to update all the packages (muddle update is your friend for updating all the packages in a system from their individual revision control systems - having worked with a "build" system that didn't have this facility, that is so refreshing), and easy to rebuild individual parts. If we hadn't had muddle for this system, we'd still have had to build Makefiles or some other ad-hoc scripting mechanism to make the builds reproducible (been there, done that, ick). With muddle, that step can be avoided (it saves time, in deciding what to do), and the same mechanism can be used for multiple projects (again, it saves time, in learning an individual setup).

(There's a lot to be said for a solution that is ready-made, and avoids the need for deciding what solution to use this time - it's where ASCII, UML and XML have all scored in their time. It's not that the solution need be perfect, just that it be a decent solution that you could have chosen independently, and that everyone is already predisposed to agree on. Such can save months of discussion and reimplementing the wheel.)

Using file-system based tags is useful, too. If you look in the .muddle/tags/packages directories, you'll find the status of each package made visible. Delete one of the tag files, and muddle will believe you that that step is undone (so deleting all of them is one way of making it rebuild a package from scratch). Since checkout and deployment are intrinsically separate from the normal building process, they have their own tags, outside the above. And that's the right thing, too. Perhaps the biggest lesson, though, is to keep going back to the muddle README (this is the first section in the sphinx-ified documentation). It's a good read (it's what made me think muddle2 was really on the right track), but it is also quite information dense - almost everything in there is stuff that you will want to refer back to.

Adding a new program to a muddle build description

So I have a program (which I shall, for the sake of argument, call "george", because that is not its name) which relies upon ffmpeg and tstools, and which I want to incorporate into an existing muddle build.

This article describes how I did it. The resultant code is that used in the real system (except that the names have been changed).

First post..

Welcome to Kynesim's blog. This will be mostly technology with a side-order of comments on the UK tech business and the odd useful Linux hint. .. or you can read our official website.