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/