2014 November 01 14:37

It seems Google have changed their tune about Nexus devices.

The Nexus program used to be a good way to get a “pure Android” experience for essentially a wholesale price. I have, for example, an original Nexus 7 (the 2012 edition) that is still going strong and that I use every day. It cost me a bit more than $200; the prices came down a bit just after I bought it (oh well).

The 2013 Nexus 7 was an even better device, with a nicer display and a rear-facing camera.

But it’s gone from the Nexus site, as is the now “aging” Nexus 10. (They are still available through some retail channels, like Amazon and Best Buy.) The only tablet now available from Google is the new Nexus 9 – and it costs more than an iPad mini 2 ($399 vs $299 for the 16 GB versions of each). The specs of the two devices are roughly comparable, but given the differences in the app ecosystems – I’ve been less than impressed by Android apps, and mostly just use the stock apps on my phone (a Moto G) and tablet – and the $100 premium to get an Android tablet – it doesn’t really make sense to buy the Nexus 9 over an iPad mini 2.

And, while you can still buy a Nexus 5 phone for a reasonable price ($349 for the 16 GB device), the new Nexus 6 “phablet” costs at least $649 – as much as a normal, retail “flagship” Android phone.

I’m not sure I understand their motivation here. Initially it seemed like they wanted to populate the space with solid offerings to get developers excited about writing apps for Android; now, it seems like they are targeting the mainstream, but without the discount (or subsidy, if you like).

I’m a bit saddened by this new approach. But maybe it will flop and next year we’ll see another crop of affordable Nexus devices.

(BTW – I (mostly) love my (first generation) Moto G. Can you beat $200 for an unlocked global GSM smartphone? That has a great screen and snappy performance? And that just updated to Kitkat 4.4.4 and is slated to update to Lollipop? Maybe Motorola will continue the great Nexus tradition independently of Google.)

2014 June 27 19:27

A few days ago I rediscovered an interest in ultralight flying machines when I stumbled over this breathtaking video:

One note: you may want to turn the sound down or off. Pretty much all the videos that I’ve watched of this kind have terrible soundtracks!

Music choices notwithstanding, all of the videos on Henry’s channel are amazing. He’s flying in a French-made Air Création Tanarg. This kind of vehicle is technically known as a weight-shift control aircraft. It is closely related to a hang-glider. It uses a modified hang-glider wing, under which is suspended a so-called “trike” – a three-wheeled vehicle consisting of an open cockpit with one or two seats, the engine and propellor, ground steering gear and suspension, and whatever storage and instruments are built-in. Trikes can be totally bare-bones (and somewhat affordable), or deluxe (and consequently rather more expensive).

In the USA, the Federal Aviation Regulation (FAR) Part 103 rules allow an unlicensed pilot to fly an “uncertificated” aircraft, as long as the aircraft meets all of the following criteria (these are for a powered craft):

The trike that Henry is flying is heavier and more capable than that. It is classed as a special light-sport aircraft (SLSA) if flown unmodified, or as an experimental light-sport aircraft (ELSA) if modified by the user. Both designations require that the aircraft be “certificated” (the FAA’s term), and the pilot licensed (as a Sport Pilot).

I think his trike costs in the ballpark of USD 60,000! The engine alone – a Rotax 912 – costs around USD 17,000.

To round things out, here are a couple more of Henry’s amazing flights.

Over Lake Tahoe:

Over Priest Lake (Idaho):

Now to Queensland, Australia. These are shot from an Australian craft: An Airborne XT.

And, finally, a taste of flying in a Part 103-style vehicle: An Airborne T-lite.

This seems like an amazing – if potentially life-threatening – sport! Who doesn’t want to fly?!?

2014 April 12 13:20

Another Forth for the MSP430?

I’ve had an interesting week. Between Friday, April 4, and Friday, April 11, I worked feverishly to add support for TI’s MSP430 microcontroller to muforth. The work is not quite done, but I’m very pleased both with the results, and with how quickly it came together. During that time, I wrote:

What is currently missing is the rest of the kernel, and a working meta-compiler (sometimes called a cross- or target-compiler). Because the MSP430 instruction set is so well suited to Forth, building an indirect-threaded code (ITC) Forth is easy and efficient. NEXT is two instructions (two words) and four cycles. A call/return pair takes three words and eight cycles; so ITC is smaller, and faster by a factor of two!! Crazy.

ITC is elegant and beautiful, and is the perfect embodiment of Forth. I’m excited that it will work well on this chip!

Meta-compiling an ITC Forth is almost trivial, unlike meta-compiling native code. Finishing the meta-compiler is maybe one more day of work.

The rest of the kernel could take some time, depending on what I decide I want to add. A small multitasker? Fancy math support? Those are both probably coming, but the timeframe is unknown.

One more gotcha: None of this code is publicly available at the moment! I’ve been struggling with how I want to license muforth, and since deciding that I was no longer sure I wanted to share it via a BSD license – the current license on the code available at Github – I’ve been doing development in private on Bitbucket. I really want to push the work I’ve been doing – on the MSP430, the Cortex-M ARM, and the AVR – to Github, but I have to finalize my licensing decision first.

Why did I do it?

A friend was struggling to get his Launchpad to do much of anything. The debug story on the 430 Launchpad is pretty crazy. First, there is the TUSB3410 – an 8052 clone with a USB interface. This chip implements a USB CDC-ACM interface, bridging between the host and the serial (UART) port of a second chip – an MSP430F1612, which does some JTAG/Spy-Bi-Wire heavy lifting to talk to the target chip (in our case, an MSP430G2553). The protocol is, as far as I understand, undocumented, so we couldn’t easily just target that from muforth, which was my first thought.

Why not use the available tools? Well, they are Windows-only, for one. And they are also closed-source, limited (esp IAR Kickstart), and/or bloated (CodeComposer). We wanted to be able to talk to the chip from muforth, on Linux and OSX.

After reading about the target chip, we decided to target the BSL – a ROM-based bit-banged-serial bootstrap loader that is built-in to almost every MSP430 chip. We tossed out the Launchpad (figuratively, if not literally), breadboarded a G2553, tickled it into the BSL using jumper wires, connected an inexpensive USB-serial convertor, and tried talking to it from muforth. This took a few iterations – esp since, for all of this development, I have been writing code with no access to hardware!! To test, I push the code to my friend, he pulls and tries it out and tells me what happened. This would have been excruciatingly painful without audio chat, which we had going the entire time that we were debugging. Being able to talk hands-free while coding and brainstorming – to say nothing of fee-free! – was really liberating.

Once we could talk to the BSL, I wrote my chat stub, using my newly minted MSP430 assembler. Using the BSL, we copied this code to RAM and executed it, then switched some wires around – the BSL does not use the UART interface – we could talk via the chat protocol to the debug stub. Once I added a tiny piece of code to write a word to the flash memory, we could program the flash, and reboot into our own bootloader.

This all went suprprisingly well. At first we weren’t getting anything out of chat – but then quickly realized that we had forgot to switch the wires around, and also to change the serial port settings. The BSL runs at 9600 bps, with even parity. My chat runs at 115,200 bps, with no parity. Once we remembered to switch the wires and the host-side serial port settings, everything worked.

But why write another MSP430 Forth?

This work differs from other efforts that I’m aware of – such as CamelForth, 4e4th (German site) (English site), and mecrisp – by being a “tethered” Forth that compiles headless code – code without names – onto the target. This allows much bigger programs to fit into the flash. All the code to do the compiling and text processing is on the host, and leaving out the names saves a lot of space as well.

The MSP430G2553 – the chip that this work initially targets – has 16 KiB of flash. A lot of headless Forth code will fit into that space. ;-)

2014 March 19 00:01

I discovered that Google had hosted a Chrome OS firmware summit. Two of the talks I found of particular interest:

The EC project is especially interesting, as it’s a permissively-licensed (BSD I think) tiny OS with several useful i/o drivers (timers, UART, I2C, etc). Sure, it’s intended to be used to read the keyboard of a Chrome device, but it could be repurposed for anything, or used as a template for starting a completely different project.

The EC code is here. In addition to the EC video and slides, there is also an (older) intro to doing EC development on a Chrome device.

2014 March 05 13:28

I’m hating Linux again – a lot. Especially Arch Linux.

I updated Arch on my aging laptop (circa 2000, 600 MHz Celeron, 192 MB RAM!) and it slowed down so much as to be unusable. You may think I’m crazy to think that this machine, under any circumstances, is usable, given its paltry specifications, but it makes a perfectly good machine for writing and testing code – as long as the code isn’t huge. I did all of the initial muforth development on this machine; it compiles the C sources for muforth in a few seconds, and loads any muforth project instantaneously. The “only” difficulties are that it can no longer comfortably run a web browser or a PDF reader – both of which are sometimes needed, especially when doing microcontoller development.

But after that recent update, something was terribly wrong. The framebuffer console – which gets slow when something is eating the CPU – was unusably slow, even with nothing running. top showed three kernel worker threads, each using 5% of the processor. This was a new behavior, but 15% didn’t seem like enough to cause the effect I was seeing.

However, downgrading to the previous Linux kernel package – from 3.13 back to 3.12 – solved the problem.

This is at least the fourth time that Arch has done something that totally b0rked my machine, and it may be the last. I’m looking at other possibilities. I would love to ditch Linux entirely (for one of the BSDs, probably) but Linux has one thing, which I love and depend on, that they lack: a good framebuffer console. The FreeBSD implementation has a “pixel” mode, but it’s not terribly flexible – font sizes are practically fixed, for example. NetBSD’s wscons is unusably slow in graphics mode. DragonflyBSD shares FreeBSD’s console, so it likely FreeBSD’s behavior.

It’s too bad, because I really prefer the experience of both sysadmin and user on BSD, versus on Linux. (I’ve written before about why I like BSD.) The BSD philosophy of having a core system – kernel and basic userland – that are maintained together, in one place – just makes sense. It also (potentially) makes installing the system much easier: you partition the disk, and untar the core system. Done! (Sadly, it’s not that simple in practice, though.) I also find the BSD userland tools to be superior, and the manpages to be far and away superior, to those found on Linux.

But I’m stuck with Linux if I want my fast and flexible framebuffer console. (I especially like the fact that I can load a 16x32 font into it and have a colorForth-like environment, which is also potentially really nice for doing presentations.)

I spent a tiny amount of time revisiting the world of Linux distributions. So far the only one that even remotely appeals to me – largely because of its BSD-inspired philosophy – is Gentoo. But even small things like Which init do I install? make me crazy. NetBSD pioneered a Unixy, flexible, and reasonably fast init/rc.d system, which FreeBSD adopted. Unlike either systemd or upstart it retains the simplicity and flexibility of shell scripts. All of the Linux variants of this idea are, in one way or another, inferior to this simple system. And it’s things like this that make me want to ditch Linux – forever.

That time has not yet arrived – unless I want to write my own fast and flexible framebuffer console for BSD... Which I might very well do. ;-)

2014 February 26 16:15

I’ve been geeking out on Clojure again – which mostly equates to watching a bunch of awesome talks by Rich Hickey.

Here are a few highlights:

I discovered Clojure in early 2009 – the earliest emails to friends are from March of that year. I was “supposed” to be getting into Scala, which I had also just discovered, and had just spent some time evangelising to friends, but Clojure appealed to a certain part of my nature – the part that likes convivial tools and extensible languages.

I used to think that Scheme was the perfect language. I loved its clean semantics, simple syntax, terse specification (this was in the R4RS days ;-). I looked around for an implementation to play around with, and got frustrated by what I found: a huge number of implementations, and no guide to which were “serious” and which were weekend hobby projects. I didn’t want to try them all; I may have tried one or two. But I never did much with Scheme, and kind of gave up on it.

After the R6RS fiasco, I knew Scheme was doomed, at least for a few years.

Shortly after giving up on Scheme, I started reading Paulson’s book ML for the working programmer – a hilarious title, as the book’s example code consists of things like a lambda calculus evaluator, and a simple proof assistant – hardly the stuff filling the days of most “working programmers”. But it’s a great book, and I fell in love – again – with ML’s type system, and with the idea of strong, static typing. I also rather like ML’s (and Haskell’s) syntax. (Just to be clear, I’m talking about Standard ML here – I could never get excited about Caml or OCaml, for some reason.)

Never did much with ML, though. Scheme had seven thousand implementations of varying quality; Standard ML had maybe four, but all but one – MLton – seemed dead. (Development on Standard ML of New Jersey – aka SMLNJ – has picked up recently.) MLton is awesome, but it didn’t fit my needs: I wanted something with a friendly, exploratory interface. MLton is all about ahead-of-time compilation and raw speed.

I guess I just went back to Forth, which was not only a comfortable place for me, but also an inspiring one. Every time I return to it, I find its simple, extensible syntax liberating, and a joy to use. Forth has issues certainly: it is a stateful, imperative language with lots of global variables, and a global namespace. Sure, it has a functional core, if you can limit yourself to words that consume and produce values on the stack – but really, at heart, it’s a state mutation language.

Scheme appealed to me because of its simple, extensible syntax; but unlike Forth is also has a clean semantics. As I’ve mentioned, Scheme is, for me, off the table.

But what about Clojure?

Here is a language that combines

What’s not to love? Clojure may be, for me, the Scheme that never was. Maybe this time I should actually start using it. ;-)

2014 February 13 23:07

I wanted to share a few links – some cheerful, some, not so much.

It seems like it’s going to be a hot year for Chrome devices ...

The HP Chromebook 14 from Costco – its 32 GB SSD being the big draw – is currently sold out. (Actually, the link goes to a “product not found” page.) I was thinking of trading in my HP Chromebook 14 (a 16 GB version) for one from Costco, as they are otherwise identical machines. Now I may be sticking with mine. HP and Walmart remain good sources, with current inventory.

Google is pushing the idea of a Chromebox for meetings. I think they may be on to something, and this will (hopefully) mean wider availability of Chromeboxes, which strike me as awesome home machines – for email, movies, etc.

ASUS has announced a preview of their new Chromebox – a $179 device that seems basically like an HP Chromebook 14 without a keyboard or screen. These look great!

And LG is pushing its Chromebase – an all-in-one style desktop Chrome machine. Initial pricing seems to be rather high – it is suggested these will sell for more than $500 here in the US.

... but an increasingly shitty year for privacy

You should perhaps worry that Chrome is listening. While developing a Javascript library for speech recognition, programmer Tal Ater discovered a curious vulnerability in the Chrome browser that allows malicious code to keep the microphone on without the user’s knowledge, and with no visual notification from the browser.

Ater telling Google about the exploit, he waited four months for the fix to get pushed to users. Nothing happened, so he’s gone public with it.

I’d like to try his code on various versions of Chrome – especially the versions pushed to Chrome devices on the different channels (stable, beta, dev, canary). I haven’t done this yet.

There is also a damning story about RSA – for many years staunch privacy advocates and a sworn enemy of the government’s pursuit of private data – but now increasingly – and unsettlingly – cozy with the NSA. Key takeaway: Elliptic curve considered harmful! Deprecate with extreme prejudice!

Lastly, perhaps as many as 900 million Android devices are vulnerable to a “master key” exploit. Download the app and see if yours is. Good luck.

Ok, now back to our regularly-scheduled programming. ;-)

2014 February 03 18:18

After much ado, I bought a Chromebook – the HP Chromebook 14, to be exact. I’ve only had it for a few days, but my initial impressions are almost universally positive.

I’ve decided to keep a Chromebook diary. I’ll try to keep it updated with my thoughts about Chromebooks generally, and the Chromebook or -books that I end up trying out.

2014 January 06 23:22

Happy New Year!

I hope to write more here in 2014 than I managed to in 2013. In part I blame my tools – the steps for changing or adding content are just tedious enough and create just enough friction to slow down my writing to a complete stop... and once stopped it can be hard to get going again.

There were a bunch of things I had wanted to write about before the close of 2013 but never got around to. Here is a short list:

While thinking about the possibility of doing muforth development on a Chromebook I discovered the following:

Here are three Chromebook videos that are kind of fun:

Lest you think I’m a Google fanboy who thinks that Chromebooks (and the cloud) are the entirety of the future of computing, I should say this: I’ve yet to buy one, but I think they are interesting devices that deserve attention. As soon as there is a compelling mid-range Chromebook with a nice screen available – I’d happily pay $500 to 600 for such a device – I’ll probably buy one. I may buy one anyway, but the current low-end offerings don’t excite me, and the Pixel, while interesting, is too expensive. In the short-term I’ll probably be rocking a new Macbook Pro or Air instead.

As further evidence of my non-fanboyism, many of Google’s webapps make me crazy, and my Android phone daily makes me want to throw it into a river. Thankfully there none near where I live. ;-)

Read the 2013 journal.