I thought we had a good thing going; I thought we could trust each other. I wouldn’t play with her heart, and she wouldn’t let me down. We seemed to be in a stable, long-term relationship. Then she just stopped trying and completely locked me out. I couldn’t figure out why her behavior just changed overnight, and I didn’t know what else to do. So I had someone follow her, to find out what was really going on.

While I would never hire some sneaky character to follow a person, I have no such qualms about having something stalk a misbehaving application. A problem came up with a Mac program that I had written in C. It would run great for a while, and then after some random number of days or weeks it would simply stop producing output. Not only would it apparently stop doing anything, it would also use all available CPU cycles. It was furiously doing nothing.

It was difficult to debug, since I couldn’t really set breakpoints to try to catch something that might not happen for weeks. And there didn’t seem to be a way to just break into the current instruction, like I am used to doing in embedded programming.

Lucky for me, my boss Alex happened to notice an interesting function of the Activity Monitor while experimenting on his Mac. Though I had used that utility before, I had completely overlooked the intriguing button at the top labeled “Sample Process”. Using this understated gem, you can select any running process on your machine and take a peak at what it’s doing with its time. There are a few different ways to have the information displayed, but I found the most useful to be “Percent of Thread”.

What I did was take a sample of my application while it was running normally, to get a baseline. There wasn’t anything too surprising in there; CPU usage seemed to be widely distributed among a variety of function calls. Then I sat back and waited for it to lock up, as I knew it eventually would.

So a few weeks later the application became unresponsive again. I took a new sample and what do you know? There was one function call that was using 99.7% of the CPU cycles. It turns out that there was a problem with the hardware drivers I was using. They would get in a bad state in which a particular asynchronous process would never complete. The interface was such that I had to poll to check if the process had completed. It was never completing and I was polling as fast as I could, which maxed out the CPU usage. Long story short, it was a recoverable problem and I just had to put in a timeout to give up waiting after a reasonable amount of time.

If you think your application is running around behind your back, sample it and find out what’s really going on.

Previous step — Getting started in part 1

Install day. Pull the car in from the 20 degree November day to the garage with the big space heater going. Numb hands and warming surfaces with a heat gun to make them pliable or to get adhesives to actually stick definitely slows things a bit.

Disassembly is the first step. We (the dynamic duo of my Dad and myself — he’s the automotive and analog electrical expert while the digital side is my domain) pull out the center console & radio, pull the spare and pop panels as we route wires. Next comes building out the cozy, safe and secure home for the mac mini. To help with the vibrations in the car we’ve placed two 1/2 inch layers of sorbathane foam padding (expensive stuff but well worth it) under the mini (cut just smaller than the mini’s base so the air intakes can still pull air in). This stuff is amazing at damping vibrations. The car had a hard styrofoam case already in place previously so we drilled out access and air holes in that and then built out supports around the mini using the blue foam padding you see in the pictures. We made sure to allow air channels to flow around all sides and out into the trunk through the styrofoam.

After the mini is secure we finagle the power, audio and USB wiring under the back seat, under the driver’s side door frame and around under the dash. The power supply is then attached to the base of the trunk and the rest of the wiring tested out and cleaned up. Lots of heat shrink tubing goes in place to make sure there’s no chance of disconnects or shorts.

Now comes the time I’ve been waiting for — connecting the audio and touchscreen. First the AUX audio cabling and switch goes into the back of the Bose system. We then plug in the VGA and USB to the screen and fire everything up (yes, we’ve routed cables for both that are about 20′ long including a distance extender for the USB to make sure there aren’t any signal drops). After some rechecking of settings on the power supply it all comes to life.

Now back to the Xenarc 7″ touchscreen I mentioned before. It works really well — it’s just large. It’s about an inch think and has a good sized bezel around the outside. Rather than completely chopping up the console to fit it in we decide to attach it to the front of the console for this initial version. I think a smaller screen will be a better fit in the future.

Finally everything gets buttoned up again, tested and re-tested. It’s working and I can drive the audio from the mini through the car audio system. Version 1.0 is a success.

Next, it’s on to the development of a simple GUI that is a whole lot easier to use than selecting things in iTunes using a touchscreen.

Next step — Touchscreen GUI software in part3