My father, Dr. Robert Bugg Quattlebaum, was born on November 23rd, 1923. To put things into prospective, he was an army medic in World War II. By the time he got around to having me he was 57 years old. There was clearly a bit of a generation gap between us.

In early 2001, my father was diagnosed with terminal liver cancer. He passed away that summer. It was a bad year. I miss him greatly.

Fast forward a decade or so and the world is now a totally different place. Star-trek-like computing gadgets are common. Video phones actually work and work well. You can even spit in a tube and get your DNA analyzed, giving you important information on your disease risk, for less than two-hundred dollars.

Which brings me to 23andme.com. If you've never heard of 23andme.com, it is a relatively inexpensive chip-based genetic profiling service. You start by ordering a kit, spitting in a tube, and mailing it off to them for analysis. There is a strong social aspect to the website which allows you to find both distant and close relatives. My wife and I got a great deal a while back and signed up.

During the sign up process, I found some of the warnings to be curious. Stuff to the effect of, 'you can't unlearn what you find out from this, so if you can't handle the truth then you may not want to consider this service'.

This got me to thinking: I bet a few people learn some rather startling information. Imagine signing up and then finding that you have a 25% genetic match with... A childhood friend who lived down the street. Oops. Someone just got busted.

There are many variations but they all cause a bit of an identity crisis—and potentially a strong sense of betrayal. Clearly, the 23andme.com experience has the potential to be profoundly shocking and life changing. But, hey, I'm not one of those people, right? No worries here.

It very much saddens me to discover that the comments table from the MySQL database has for some reason disappeared during the migration process. Poof. Gone. I have no idea what happened to it, but it is gone without a trace. As a result, all of the comments on this website have been lost. This is quite distressing, especially considering the immense value the comment threads on variousposts added.

If I somehow manage to recover the comments I will do so, but at the moment it looks like a total loss.

Late last week, my web and email hosting provider decided to switch servers. It was a total cluster-fudge. My server-side email sorting script (via procmail) totally broke. SSH logins were no longer allowed. And let's not even go over the website itself—I couldn't even figure out where it was serving files from.

With my patience running low and my annoyance high, I decided that this was a good opportunity to switch to a VPS at a different company. It has been a slow process, but things are now starting to slowly come back online. Comments are still busted, but I'll get those back online soon.

Anyway, In light of this mess, I hope to totally revamp the website at some point over the next few weeks so that it will be easier to maintain and nicer to look at.

Over a year and a half ago, I put some money into the Hexbright Kickstarter and promptly forgot about it. Earlier this week a box appeared on my doorstep with a brand-new Hexbright Flex, "the world's first open-source LED light".

This flashlight is probably one of the most over-engineered devices I own, and I love it, but I'm sure you are wondering, "It's a f'ing flashlight. Why bother programming for it? There is only so many things you can do with one button and 500 lumen LED..."

Well, I thought that, too. But after trying the factory firmware and a few of the samples, I realized that this is actually a very interesting human interface problem. Just how should a flashlight behave? What behavior makes it feel right? What is the bare minimum that a flashlight needs to be able to do to be considered seriously?

As some of you know, I've been working on a CoAP stack for embedded devices for some time now. Things have gotten to the point now where I'd like see if other people are interested in using it and/or contributing. So today I am announcing that I am making my first release: SMCP-0.6.

I seem to be one of those rare people who don't actually work for Google, but love Google Plus anyway. (We do exist!) In case you've been wondering what I've been up to, your best bet is to follow me there. Unlike my Facebook account, my Google Plus profile is public: so everyone should be able to follow me.

I'll make longer, more detailed, more formal posts here when I have time, but for the vast majority of my posts, comments, and pictures will be available only via Google Plus.

A while back I informally proposed the radio-frequency URI scheme,
x-freq. I've since written a simple parser for this scheme so that if anyone wants
to adopt it that they can do so as easily and correctly as
possible. I've released this code into the public domain1. You can find it
here on Github.

The incentive for using this code instead of rolling your own
x-freq URI parser is that implementing a correct URI parser is a
deceivingly difficult task. I wrote this because I didn't want
everyone who wanted to use the x-freq URI in their programs to
end up writing their own slightly broken parsers. People invariably
tend to not read specs for this sort of thing and just go on their
gut. I'd like to avoid that by providing this canonical implementation
to the public domain. You are free to use and abuse this source
code to your heart's content, with or without attribution.

To put it bluntly, this code is far more likely to be correct than
what you would likely write in a short period of time. If you want
to use x-freq in your C program, at least use this code as a starting
point.

I am really getting frustrated by the fact that the development tools for just about every embedded platform are Windows only. No Linux support, and most certainly no support for OSX. (The same thing applies to amateur radio software, but that is a rant for a different post)

Writing and compiling the code isn't (usually) the problem—GCC and SDCC are both well supported on Linux and OSX, and between the two I can write code for nearly every architecture I would ever need to. The problem I'm talking about is support for devices like programmers and debuggers—devices necessary for actually getting the code onto the chip I'm trying to develop for.

Nothing quite dampens my enthusiasm for a platform like having to fire-up VMWare to upload new code or debug a problem. For example, I recently picked up an STM32F4-Discovery board from ST Microelectronics, which is a development board for their nice 32-bit ARM Cortex-M4 STM32F4 microcontrollers. The board has two USB ports: one connected directly to the STM32F4 microcontroller, and the other dedicated for in-circuit programming. What software do you use to program this lovely demo board? The ST-Link software. What is the only platform it runs on? Windows.

What a waste of time.

I understand that development resources are limited for things like this, and that these companies want to target the platform that they perceive is used by the majority of their customers. However times are changing.

The thing is, the majority of my frustration could be relieved by manufacturers doing one simple thing: document the USB protocols for their programmers and debuggers. If I had this, I could write the programs necessary to program and debug their platforms on Linux (or OSX) myself.

I found this situation so frustrating that I was actually considering snooping the USB traffic of these devices so I could reverse engineer the protocol. I've since realized that there are much more interesting things that I could be doing with my limited free time. If the manufacturer can't even take the simple step of documenting their protocol then their platform just isn't worth my time.

Hey, TI and ST: If you are listening, please make an effort to at least document the USB protocol that your USB-based programmers and debuggers are using. If you could do that, then people like me will fill in the gaps in your development environment for you. Sounds like a good deal, no?