On animation in user interfaces

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?)

Overriding install prefix in build systems

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).

Links for December 2012

• 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

Links for September 2012

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

Links for August 2012

• 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.

TI Launchpad 1.4 vs 1.5 pin swappery

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.

KiCAD the schematic/PCB design suite

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.