Code Kills

I picked up an Arduino yesterday, and I was quite dismayed by how much work it took to build/flash from the command line.

After some hours of Googling, though, I finally found an up-to-date Makefile, and it didn't take too much to make it "just work" with the default install of Arduino.app on the Mac.

To use this Makefile, simply drop it into the project sketch directory, then run make then make upload. You may need to tweak some variables (eg, it assumes Arduino.app is located at /Applications/Arduino.app), but that is fairly straight forward.

Get the Makefile from: http://gist.github.com/273821.

Just a note: I haven't had much time to tinker with this system yet, so it may have some serious issues... If so, drop me a comment below.

Also, leave a comment if you want me to let you know if (when?) I update this.

I was not impressed when I tried to check out a UTF-8 encoded file with SVK, then got the helpful message Can't encode path as ascii:

$ svk up
Syncing //drp/trunk(/drp/trunk) in /home/wolever/Trunk to 5388.
Can't encode path as ascii.

I was even less impressed when I searched Google for svk unicode and this blog was the first hit.

Fortunately my Google-foo is high today, and I was able to find a page that gives a solution: Making sure that your locale is set to something similar to en_US.UTF-8.

On Debian, here's how I do it:

$ sudo apt-get install locales # Ubuntu 6.06 didn't have it...
...
$ export LANG="en_US.UTF-8"
$ export LANGUAGE="$LANG"

And, of course, it may be good to put those two exports in ~/.bashrc.

Oh, but wait!

$ svk up
Syncing //drp/trunk(/drp/trunk) in /home/wolever/Trunk to 5388.
Can't encode path as ascii.

It still doesn't work!

It turns out that, for what ever reason, something was upset. Eventually I got it working by deleting the offending directory, then using svk revert to revert it:

$ rm -r hacking/
$ svk revert -R hacking
...
Reverted hacking/utf8_爱的

Hurra!

I got the game BioShock when it came out and had no issues when I started out and happily started playing through the game. Then as usual, I started screwing with things that I shouldn't have and updated my BIOS just so I could have the latest version. The update worked fine and everything was alright until I tried to continue with BioShock upon which I discovered there was no more sound in game. I have a MSI P965 Platinum motherboard and currently use its onboard sound controller. After rolling back the BIOS a few times I determined the breaking version was the 1.03 which has a change list indicating changes related to the north and south bridge were made and these changes seem to have screwed up my sound. Reverting to 1.02 fixed all problems and I was able to finish the game. After the breaking update I noticed that Vista (Home Premium x64) recognized sound as a new device. Maybe new drivers got screwed up, but I'm not sure. I didn't explore it in much detail. The sound worked in Windows and for the loading of the game, but once DirectSound (or whatever it is now called in DirectX10) started, the sound was gone. I didn't compare with other games though so I can't comment on how they handled it.

Hopefully the search engines will catch this and help anyone with similar problems.

The dead Linksys power supply

Well, not quite a 'ring' but one red LED.

A few months ago my internet decided to cut out while I was working on a project in the middle of the night, so I went through the usual diagnostics of trying to reset everything, but with no luck. Closer inspection of the router revealed that only the red diagnostic light was on, and it was dimmer than usual. I assumed my router was toast but, decided to make a few attempts to get my internet restored that night.

I can't recall how, but I eventually reached the conclusion that the power supply had crapped out, so I went looking for another 5V power supply. Fortunately I discovered another old router that had one. A bit of soldering later, I had the connectors on the power supplies swapped and voila! It worked! So my internet was back up and I could finish the work on the project.

Now that was a few months ago, so why do I bring it up now? Well, Dave mentioned he had a dead WRT54G and explained the red light just blinked. It sounded like it could be a similar problem, so we plugged it in and the red light came on rather dim -- just like mine. Chances looked good that it might be the same problem. Checking the power supply with a multimeter we found it was 5V as it should of been. Not yet convinced the power supply worked, we popped open the router and checked the voltage when under load and sure enough it was 4V... Too low to power the router. To confirm the router itself works, we temporarily hooked up the 5V from a molex connector of a computer power supply to the router and it started up normally. Problem solved! Now we just need to locate a new 5V power supply for it...

So if you have a dead WRT54G in your closet with only a faint red light showing when you turn it on, you should try another power supply and see if you can give the beast a second chance at life.

Now, while we're on the topic of routers... I feel like I should mention Tomato -- the firmware Dave and I both use. It's got the nicest interface I've ever seen on an embedded device (complete with pretty graphs and smart use of Ajax). It also boots much faster than DD-WRT (although I've heard rumors that things like VPN don't work very well).

The red light of doom

For the summer I'm working on adding features to, cleaning up, and making algorithms more generic in a academic research tool. Overall the algorithms and data structures are well planned out and have been generally quite friendly to improvement. As part of my work, I'm integrating derivative versions created by people in their research so it isn't surprising when certain things are hacked together just to get them working, but sometimes it is a little overkill.

The fun example I've found that convinced me to write up this post was using a FIVE dimensional dynamic array to store some information. While I can see some reasons for it, there was quite a shock when i noticed the typecast to (short*****). Here is the code if you dare! (I replaced the variable name with a much shorter one)

foo = (short *****) my_malloc ((nx+1)*sizeof(short ****));
for (i = 0; i < nx+1; i++){
  foo[i] = (short ****) my_malloc ((ny+1)*sizeof(short ***));
  for (j = 0; j < ny+1; j++){
    sblock_pattern_init_mux_lookup[i][j] = (short ***) my_malloc (4*sizeof(short **));
    for (from_side = 0; from_side < 4; from_side++){
      foo[i][j][from_side] = (short **) my_malloc (4*sizeof(short *));
      for (to_side = 0; to_side < 4; to_side++){
        foo[i][j][from_side][to_side] = (short *) my_malloc (nodes_per_chan*sizeof(short));
        for (itrack = 0; itrack < nodes_per_chan; itrack++){
          foo[i][j][from_side][to_side][itrack] = UN_SET;
        }
      }
    }
  }
} 

I really don't believe this was the best answer and I can hopefully cut this out.

EDIT: Apparently there were so many *'s it broke the blog software...