Interesting facts about USB, number 2312 in an occasional series.

Ah, USB 2.0. How I don't love thee in any way at all.

I've recently been hacking the USB drivers on an SoC we have here. The initial problem was that a USB mouse connected via a high-speed hub was acting erratically.

[Update: for what it's worth, it turns out that none of the below actually works. But I do now have some nice clean traces showing a high-speed USB hub apparently blatantly failing to report transaction results back to the host. Hey ho. Work continues.. ]

Muddle version 2.2 now available

I have just merged my "new_vcs" branch of muddle into trunk. This is tagged as "2_2", and thus is muddle version 2.2. Changes include:

So: this Android thing...

Y'know, one day I'm going to post regularly. When that happens, watch out for snowballs from the sun.

Anyway, I've been quietly porting Android 2.2 to one of the dev boards we have lying around recently

CELF Embedded Linux Conference Europe

I shall be at the Embedded Linux Conference in Cambridge next week, on Wednesday and Thursday. On Thursday I shall be sitting at a desk in the Technical Showcase session between 12:35 and 14:30 (hmm, I assume there's some time for lunch in there as well), available to talk about KBUS, muddle and tstools.

I'm assuming my badge will say "Tony Ibbs" rather than "Tibs"...

Muddle FAQ: Efficient minimal rebuilds

"I've made a change deep within some package. How do I perform an efficient minimal rebuild?"

Coming to muddle from a mostly make-driven world, I really wanted to be able to stand at the top of a tree, type make and have it rebuild only what has changed. Unfortunately, life isn't as simple as that: it only works properly if package dependencies are correctly defined. This sometimes seems to be beyond individual package developers with their own software, let alone complicated inter-package dependencies, so clearly we need a different plan.

Pretty pictures

I keep meaning to write the "introduction to muddle labels" article, and I keep not having time.

I did, however, get round to drawing some diagrams (using OmniGraffle, which is really good). So it is probably worth putting them somewhere that other people can see them.

"with Directory" makes testing easier

One of the problems with writing tests for muddle was finding a clean way to write them in Python.
Testing muddle involves a lot of directory creation and moving between directories. Using os.chdir() and friends doesn't lead to easily readable code, and there is always the problem of forgetting to move back out of a particular directory.
My first attempt to make this easier was to write simple pushd() and popd() functions, which maintained a stack of directories. This was a little better, but still didn't solve the "forgetting" problem.
Of course, the solution is obvious -- use with.

New verson of muddle

Today I have merged my development branch of muddle back into the trunk. This is the same version of muddle that I was using as "m3" in previous posts. There are a few new commands, but on the whole this is a change for maintainability, and progress towards muddle3, rather than user features.

See the main muddle page (http://code.google.com/p/muddle/) for information on new tags and branches.

muddle and its directories - part 7 - end

If you've read all of that, and it made some degree of sense, then I really do recommend you also go and read "Welcome to Muddle", online at:

http://muddle.googlecode.com/svn/trunk/muddle/docs/_build/html/README.html

If you've read it before, it should now make a different sort of sense, and if you haven't, you really should. Really.

It also mentions several topics that have not been addressed in these posts.

muddle's help is meant to be useful (muddle help), although it sometimes lags behind reality. If you find problems or inaccuracies in the help, please do raise an issue on the muddle issues page describing the shortcomings - these do get attended to.

Also, I am contactable by email, and will try to help with specific problems.

Finally, if all else fails, we will develop muddle for money!

muddle and its directories - part 6 - domains

Contents

• Domains
  • What domains are for
  • How domains work
  • A worked example of using domains
  • Version stamps and domains

muddle and its directories - part 5 - adding and stamps

Contents

• Adding a new checkout/package
• Version stamps

muddle and its directories - part 4 - building

Contents

• Building a package
• Deployment
• Rebuilding things
• Do what I say, not what I do

muddle and its directories - part 3 - mechanics

Contents

• The mechanics of the build - the build description
• Some naming conventions
• Introspection of the dependency tree
• Checking out the source code
• The mechanics of the build - the makefile

muddle and its directories - part 2 - example build

Contents

• A simple example build
• The .muddle directory
  • The Description file
  • The RootRepository file
  • The tags/ directory
  • Other contents
• The src/builds directory

muddle and its directories - part 1 - introduction

This is a look at how muddle works, specifically looking at the directory structure of a muddle build.

Since it is quite long, I am splitting it into a series of 7 posts, of varying lengths. The whole thing will also ultimately be integrated into the "proper" muddle documentation.

If you are just going to use muddle to check out and build an existing build tree, then this will probably be much too much information, although the short section An overview of the directory structure (at the end of this introductory post) may be useful.

If you are going to be developing new muddle builds, then this text should enable you to do so more effectively.

If you are going to be reading the muddle source code, or developing muddle itself, then it should explain much of the intent behind muddle's workings.

Contents

• Introduction
• Notation in this text
• An overview of the directory structure

Some notes on cross-compiling in a muddled world

Obviously one of the main aims of developing muddle has been to make it easier to build cross-compiled systems, since that's what I spend a lot of my time doing.

Lately I've been taking a DEB-based build and turning it into a source-based build. This article is some notes on things I've learnt (or had reinforced) in the process.

We shall be at EuroPython 2010

Both Richard and I are giving talks at EuroPython 2010 in Birmingham. Richard will be talking about muddle, and I shall be talking about Kbus, starting (as currently scheduled) at 17:00 on the afternoon of Monday 19th July.

I'm intending to be at the conference all four days (Monday through Thursday), whilst Richard may only be there on Monday.

Hope to see you there...

Interesting times for OTT video

So it looks as though we're about to be living in interesting times for OTT video.

Why KBUS?

So why are we developing KBUS, rather than using some other messaging system?

(I'm going to assume you've seen the previous blog items on KBUS, and/or read the KBUS documentation on its Google code page.)

Saving and restoring the state of a muddle build

So over the last week or so I've been working on adding commands to muddle so that we can store and restore "version" information for a build tree.

The basic idea is to be able to save enough information to a file to allow reconstructing the main build structure, and the content of every checkout.

A build description doesn't necessarily suffice for this, firstly because you don't actually have to specify a revision id for a particular checkout (one can default to HEAD), and secondly because the user of a build might have updated checkouts since the build description was first used to extract it.

So, here is some documentation for the result (so far, at least).

KBUS Limpets - an introduction with goldfish

This is a metaphorical goldfish called A.

A simple introduction to using KBUS

This is intended as a very simple introduction to the basics of how to use KBUS. As such, I'm sure I could improve it, but it's been waiting for long enough now that I think I should publish it anyway.

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.