Small KBUS utility

Just committed errno.py to kbus/utils - this is a simple utility to conver Unix error numbers into their corresponding mnemonic and text, or vice versa:

 $ errno.py EPERM
EPERM is error 1 (0x1): Operation not permitted

but also, if the error is one used by KBUS, to give the appropriate text from the KBUS documentation:

$ errno.py 32
Error 32 (0x20) is EPIPE: Broken pipe

KBUS:
On attempting to send *to* a specific replier, the replier with that id is no
longer bound to the given message's name.

because I can never remember which magic number corresponds to what particular usage.

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.