Pigbox – Boombox for the pigroast

Current idea is to use the following as the main component.  It’s powered via 12v DC and has some decent power for driving a load.  The TPA3116 is fairly well regarded as a decent sounding Class D amp, so it’s looking like a good match for a 12v car battery.  The best part is that it’s only $24.

The AMP:



The other element is the method to stream over the audio.  I was looking at streaming via the Bluetooth A2DP spec, which provides 2x stereo sound.  The mp3->a2dp->whatever compression doesn’t leave me feeling good about the effect of all that excess transcoding on the audio product.

A couple of good resources I’ve discovered so far indicate that it’s possible tell the bluetooth stack to use an optional codec, such as mp3 to stream.  If the optional codec is available on both sides, it can thus be used.

Android should also be able to stream over the audio:https://source.android.com/devices/bluetooth.html

Still looking into what all that entails.  If i go the mp3 direct route over Bluetooth using the optional codec tech, then I’ll have to dig deep into that stacks config.

Bluetooth spec:


Laser cutting on a Trotec Speedy 300

So the kids and I was playing around with this sweet laser printer we got in:

The general workflow is to develop a vector image on your desktop, transfer the file to the laser workstation via usb stick, open it up in illustrator and print to the Trotec.

To startup we made a simple circle which ended up being my beer coaster:

You can see the MDF used is obviously sensitive to water, so ideally you’d varnish it up to last.

The next step we brought out some .141″ mystery wood to cut and practice some more etching. The wood adjustments in the Trotec library left something to be desired, so we just picked oak and went for it. The overall result was pretty sweet:


The main issue I ran into was the bird didn’t initially cut through, so I had to make a quick had to the original file to delete the inner etching fill so it would just rerun the cut and not re-etch.

The bird design came from one of the Ponoko template designs available at ponoko.com.

Structuring cross platform builds

Most of my work is focused on embedded targets, many of which have oddball inconsistencies in either the stdlib or os available. So, if your like me, you’ve had to experience the pain of wading through source that’s become a mishmash of #ifdefs in the name of portability.  If another platform was added, yet another set of #ifdef’s would need to be added to add support, and woe to the develop who had to maintain the codebase.

A straightforward example would be part of the openssl codebase:


In thlock.c, You basically have the following configuration:

Implement pthreads_locking_callback
<blah blah>
#ifdef WIN32
Implement win32_locking_callback
#ifdef SOLARIS
Implement win32_locking_callback
#ifdef IRIX
Implement win32_locking_callback

The above code covers only 4 operating systems in somewhat of a simplistic way, with little margin for wide variation between platforms. With a little imagination, one can also see where additional branches would eCos, uCos, bare-metal (no-os). In particular, the bare metal or embedded os implementation would pull in quite a bit more code, further muddying the waters.

I think there’s a better way to manage this via the build process. The #ifdefs can be replaced by a clean platform-based folder structure.

, another ifdefthe original project are added without Managing cross platform code falls into a couple different camps.  The default mode is to utilize the #ifdef PLATFORM_FOO idiom to manage differences between platforms.

Platform dependency handling can fall into two camps.

The problem – ifdef discussion

Bad Examples


Source tree structure

Marginal to good examples

http://svn.apache.org/repos/asf/httpd/httpd/trunk/ – makes an attempt to factor out os specific code to the os library/

Gumstix network doodad

So I have this scheme to come up with an inline packet sniffer that can be ruggedized, and dropped in place anywhere and just work.  Since the advent of switches, it has become quite a bit more difficult to drop a tee on a deeply embedded network for debugging.  The solution usually involves either a ghetto 10/100 hub (which sends each packet out all ports), a switch with port mirroring($$$), or a linux rig with iptables(lots of config time).  None of those solutions are really ideal.

So, what I really want is something I can just plug in between 2 nodes on the network and get a copy of everything, and optionally tee it off to another computer.  Everything should be preconfigured to work, so no blowing yet another evening configuring iptables.  The gumstix Tobi DUO seemed to be a potential solution.  And, if not a solution, a cool toy at the least.  So no matter which way it ends up, it’s a win.

Navigating the morass of Gumstix products took quite awhile. I eventually settled on the IronSTORM because it had  extended range components, which seemed better suited to the ruggedized device I eventually wanted.  It also has wifi and bluetooth capability, which I initially disliked, but am coming around, as it supports the network tee requirement nicely.  It has an OpenGL graphics accelerator, which just seems really odd to me to have on such a device, but ok, and it has a DSP, which is pretty neat, although I don’t plan to use it for anything, yet.

So I ordered the Overo IronSTORM COM plus the Tobi Duo, which has dual network interfaces, and was stoked when I got my new gumstix in the mail last week.  This was just in time for supplying some nerd fun over the long memorial day weekend, but lo! I discovered there’s no serial console on the Duo.   The documentation suggest that I should order the Tobi expansion board, as that has a usb serial console, and can be used for image update and debugging.

The COM does have serial console coming out of J1 (pin 31 and 26), but it’s buried when connected to the Duo, and I suspect is used for something.  Using bluetooth for console after kernel boot is an option, but I don’t have bluetooth.  Headscratching ensued, but a solution soon emerged.

How to interface with new Overo/Duo combo:

  • Connect one of the ports of the Duo into your LAN.
  • Let it DHCP
  • Refer to your router/dhcp server logs to determine the assigned address
  • ssh root@<assigned address> (Note: there is no root password, so you skate right on in.)

I would like to see the gumstix come with a quick start guide for the Duo that has just that information.