I recently had the pleasure of a hard disk crash on my MacBook, and only a month earlier had started backing up to a Samba-share via Time Machine.  I had the “how to restore” question nagging in the back of my head when I set it all up but I figured someone had it figured out, otherwise why would so many articles exist to show you how to set it up?

I’ve been trying to find out how people using the TMShowUnsupportedNetworkVolumes hack to use Time Machine on smbfs shares have been restoring and it would seem that the answer is “they aren’t”.  That, or they’re simply using it as an “oops” fixer, restoring a file here and there.

When booting from the Leopard DVD, firing up the terminal and attempting to mount the share, the following delightful message shows up:

mount_smbfs --> mount_smbfs: failed to load the smb library: Unknown error: 1102


Searching for that was even more disappointing.  Other people running into the issue, no solutions.  It seems smb support is just not available on the boot DVD.

I ran into a possible solution, copy the Time Machine sparse bundle onto a removable hard disk, and hook it up to the laptop. Unfortunately all my external storage is formatted ReisferFS or ext3, neither are supported filesystems, and I didn’t feel like changing one just to fix this.

So in comes the hack.  Luckily the Samba share is on an Ubuntu 9.04 (Jaunty) server, so adding support for something Apple does support on the boot DVD is tragically easy. This is a fairly specific solution, but variations on it will work for many different servers.

Enter AFP

Looking through the other available mount applications, we also have mount_afp available.  This mounts Apple Filing Protocol-based shares, and it works too, bonus!

So it boils down to enabling AFP on the server and sharing the same volume via AFP.  AFP on Linux (BSD, etc) is supplied by netatalk, and here’s a step-by-step of how I wrapped it all up.

On the server:

• sudo aptitude install netatalk
• Edit /etc/netatalk/AppleVolumes.default
• Add entry for the volume, such as:
  • /mnt/time_machine "tmachine"
• Save the file
• sudo /etc/init.d/netatalk restart

On the Mac:

• Boot from the Leopard install DVD
• Enable Airport (if on WiFi), join your network
• From the menu bar, select Utilities -> Terminal
• Navigate to /Volumes
• Create a new mount point for the Time Machine volume
  • mkdir /Volumes/tmachine
• Mount the AFP share on the new point (details)
  • mount -t afp afp://username:password@server.hostname/tmachine /Volumes/tmachine
• Quit Terminal
• Back at the main menu bar, select Utilities -> Restore System From Backup…
• You should see your Time Machine backup volume listed
• Select it, and select the date from which you wish to restore
• Wait a considerable amount of time for it to determine the space needed
• Enjoy the hours and hours of restore time!

Aftermath

The basic AFP installation added to the server is likely pretty insecure, I purged it as soon as the restore completed.  Read this for a more formal treatment on setting up an AFP server on Linux.  It is likely that the real solution is to stop suggesting people use Samba as a file server for Time Machine backups, instead switching to AFP altogether.

A few things of note. en0 is the WiFi interface. There are others. Instrument the following code w/some debug to get them all out. The ip/netmask methods return nil when the WiFi interface is not active. I would also be shocked if there were no corner cases I am ignoring…

#include <arpa/inet.h>
#include <net/if.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <errno.h>
#include <ifaddrs.h>
#include <stdio.h>
 
static NSString *kWifiInterface = @"en0";
 
@implementation NetUtil
 
+ (NSString *)broadcastAddressForAddress:(NSString *)ipAddress withMask:(NSString *)netmask {
    NSAssert(nil != ipAddress, @"IP address cannot be nil");
    NSAssert(nil != netmask, @"Netmask cannot be nil");
    NSArray *ipChunks = [ipAddress componentsSeparatedByString:@"."];
    NSAssert([ipChunks count] == 4, @"IP does not have 4 octets!");
    NSArray *nmChunks = [netmask componentsSeparatedByString:@"."];
    NSAssert([nmChunks count] == 4, @"Netmask does not have 4 octets!");
 
    NSUInteger ipRaw = 0;
    NSUInteger nmRaw = 0;
    NSUInteger shift = 24;
    for (NSUInteger i = 0; i < 4; ++i, shift -= 8) {
        ipRaw |= [[ipChunks objectAtIndex:i] intValue] << shift;
        nmRaw |= [[nmChunks objectAtIndex:i] intValue] << shift;
    }
 
    NSUInteger bcRaw = ~nmRaw | ipRaw;
    return [NSString stringWithFormat:@"%d.%d.%d.%d", (bcRaw & 0xFF000000) >> 24,
            (bcRaw & 0x00FF0000) >> 16, (bcRaw & 0x0000FF00) >> 8, bcRaw & 0x000000FF];
}
 
+ (NSString *)ipAddressForInterface:(NSString *)ifName {
    NSAssert(nil != ifName, @"Interface name cannot be nil");
 
    struct ifaddrs *addrs = NULL;
    if (getifaddrs(&addrs)) {
        NSLog(@"Failed to enumerate interfaces: %@", [NSString stringWithCString:strerror(errno)]);
        return nil;
    }
 
    /* walk the linked-list of interfaces until we find the desired one */
    NSString *addr = nil;
    struct ifaddrs *curAddr = addrs;
    while (curAddr != NULL) {
        if (AF_INET == curAddr->ifa_addr->sa_family) {
            NSString *curName = [NSString stringWithCString:curAddr->ifa_name];
            if ([ifName isEqualToString:curName]) {
                char* cstring = inet_ntoa(((struct sockaddr_in *)curAddr->ifa_addr)->sin_addr);
                addr = [NSString stringWithCString:cstring];
                break;
            }
        }
        curAddr = curAddr->ifa_next;
    }
 
    /* clean up, return what we found */
    freeifaddrs(addrs);
    return addr;
}
 
+ (NSString *)ipAddressForWifi {
    return [NetUtil ipAddressForInterface:kWifiInterface];
}
 
+ (NSString *)netmaskForInterface:(NSString *)ifName {
    NSAssert(nil != ifName, @"Interface name cannot be nil");
 
    struct ifreq ifr;
    strncpy(ifr.ifr_name, [ifName UTF8String], IFNAMSIZ-1);
    int fd = socket(AF_INET, SOCK_DGRAM, 0);
    if (-1 == fd) {
        NSLog(@"Failed to open socket to get netmask");
        return nil;
    }
 
    if (-1 == ioctl(fd, SIOCGIFNETMASK, &ifr)) {
        NSLog(@"Failed to read netmask: %@", [NSString stringWithCString:strerror(errno)]);
        close(fd);
        return nil;
    }
 
    close(fd);
    char *cstring = inet_ntoa(((struct sockaddr_in *)&ifr.ifr_addr)->sin_addr);
    return [NSString stringWithCString:cstring];
}
 
+ (NSString *)netmaskForWifi {
    return [NetUtil netmaskForInterface:kWifiInterface];
}
 
@end

NSURLConnection *c = [[NSURLConnection alloc] initWithRequest:[NSURLRequest requestWithURL:url]
                                                     delegate:self
                                             startImmediately:NO];

Apparently when not using the simpler initWithRequest:delegate:, or even startImmediately:YES, the connection does not get scheduled in the current run loop. And again apparently, this causes unhappiness to occur when you eventually get around to calling start.

Simple fix, just stuff it in the current run loop before calling start and everyone gets along just fine.

[c scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
[c start];

If there is something I am doing wrong or something I can do to prevent this, I’d like to know. Alas, the API is fairly brief on NSURLConnection, I don’t think I’m missing anything. This seems consistent with Cocoa, Cocoa Touch.

First video is of 1 servo working with really jittery input.

Second video is 2 servos on X and Y axis with smoothed input.  Much nicer.

Using libwiimote on the host side for Wii Remote interfacing.

pysubwcrev is a Python version of TortoiseSVN’s SubWCRev app. SubWCRev is a windows-only console app, pysubwcrev is a command-line argument compatible replacement that is Python-based, and therefore runs on any platform with an available Python interpreter and pysvn. Currently only Linux is tested.

The code is hosted @ Google Code. Currently no packaged release exists but it is (should be?) feature complete in svn.

Note: This is just a hack at playing w/Python, jabs and criticism w/the style can come in the form of patches.

Currently only a few shots of some basic functionality, nothing concrete to announce or deliver unfortunately.

Screen Images

Splash screen	Fans
Lights	Temperatures

Application Screenshots

Main Menu	Fan Controls
Lighting Controls	Temperatures

Most MCU’s I’ve worked with before PICs had nice simple conditional statements… The mnemonic was usually to the effect of “branch if x to destination”. Not so on the PICs.

On a PIC, we have to do an operation between the data to test, then either skip the next instruction or not, based on the results of this test.

Take the instruction “BTFSS” meaning “Bit-test F, Skip if Set”. This instruction takes a register and a bit number, and will jump over the next instruction if that bit number in the register is set. For example:

We have 2 registers, REG1 and REG2. We want to know if the value in REG1 equals the value in REG2. A quick, simple way to do this is first to load one into W, then subtract the other from it, with the result going in to W as not to destroy one of the variables. This sets the “ZERO” bit in the STATUS register to either 1 if the operation resulted in a 0, or 0 otherwise. We know if the operation resulted in 0 the two values are equal, so we can code like so:

TESTIFZERO
  movf REG1, w
  subwf REG2, w
  btfss STATUS, Z
    goto NOTEQUAL
EQUAL
  ; they were equal
  goto DONETESTING
NOTEQUAL
  ; they weren't equal

So we can test for equality.

We can also macro-ize it for ease of use…

BEQ macro REG1, REG2, DEST	; branch if REG1 == REG2
  movf REG2, W			; W <- REG2
  subwf REG1, W			; W <- REG1 - REG2
  btfsc STATUS, Z		; if result was nonzero: skip out
    goto DEST			; otherwise jump
  endm

This gives us a macro we can call with 2 registers and a destination, and have it jump there if the condition ends up being true, and just pass on through if it’s not true. Much, much easier to use.

The other tests: inequality, less than, greater than, less than or equal to, greater than or equal to and so on follow a similar pattern. They are all covered in the “conditionals.inc” file I use quite often. I have both register-register comparisons and register-literal comparisons in there. Feel free to grab a copy and use it in your next project.

Downloads

• conditionals (zip)

Mr. Baybus had a few problems I wanted to take care of. One being price, it cost way too much compared to its utililty value, which is normal for projects like this, but still…

Mr. Baybus 2 uses a much more sophisticated microcontroller, a PIC 16F870. This is a 28-pin SDIP style chip, lots more I/O pins, an onboard UART, and even an ADC. This little guy also has twice the instruction memory, so I had more freedom to make the interface somewhat more sleek, and add more features. The benefit of more pins is CHEAPER LCD. The previous serial LCD ran about $42 shipped, which is semi-high for a serial LCD in general, but it was a CrystalFontz so at least it was high quality. Anyways, now I can move to a simple HD44780 based parallel LCD (by CrystalFontz, of course). These run around $20 shipped, and even less from other places selling generics.

Features

• Three On/Off Fan controls
• One 12V Light control (Neons, etc)
• Two centrigrade temperature sensors
• 20×2 screen (any HD44780 compatible will work)
• Simple, menu-driven style interface
• Stores fan status in non-volatile memory

Display Images

Splash screen	Fan status	Fan status w/selection
Lighting status	Temperatures

Unit Images

High view of the front	High view of the back
Back view	Underneath

Version 2.1

A slight update to the original. I decided I wanted to re-write it in C as an exercise. While I was at it, I figured I’d add a feature or two.

Pretty basic, a complete re-write in C, Hi-Tech PICC to be exact. It’s a great compiler for the PICs and gave me opportunities to re-write the LCD, ADC and DELAY libraries in C.

New Features

• New program-loop idea, worked well
• Strobe mode for Light output
• Temperatures in Celcius or Fahrenheit

Downloads

All files for Mr. Baybus 2 are distributed under a BSD-style license.

• Original
  • Assembly source code, and assembled HEX file (built for 16F870) (zip)
  • Parts list (OOo spreadsheet)
  • Screen prototypes (OOo spreadsheet)
• v2.1
  • C source code, and compiled HEX file (built for 16F870) (zip)
  • Screen prototypes (OOo spreadsheet)

Schematic

Previously, in PIC buttons (polling) we saw how to poll for the state of a line connect to a button, that is all fine and good but really that is not the best way to do them. The “real” way to interface with external components like that is through interrupts, a slick feature.

Interrupts provide you with lots of freedom in your code. They allow you to sit back, relax, and be told when an event occurs, and not be forced to sit and wait for it to happen.

For this program, the schematic and circuit are practically the same, the only thing that changed location is the button.

Instead of looping over and over again, we simply wait, using a goto $ we are essentially goto’ing the same address over and over, “goto here, goto here, goto here…” ad nauseum. A common technique is also to use a SLEEP command, which puts the PIC in a low power mode and halts the program counter. Same effect to the user though. You of course could do ‘real’ work too instead of just burn cycles.

Once the button is pressed and released, the PIC will generate an interrupt, forcing the program to goto memory location 4. This is labeled in the code as ISR (Interrupt Service Routine).

For this program we are using the RB0/INT Interrupt. This interrupt occurs when there is a low-high change in PORTB,0. It can also be configured for high-low as well.

To enable this, we set INTCON,INTE. This bit says we want to know if a change occurs. To enable interrupts in general, we must then set INTCON,GIE. This lets all enabled interrupts occur.

We then wait for the interrupt. Once it occurs, GIE is automatically cleared so we can’t have them inside each other, and blink the LED a couple times. We then clear the interrupt flag, saying we’ve handled the interrupt (INTCON,INTF). We then re-enable interrupts and return from the interrupt: retfie.

It should be noted that if we were using more than one interrupt type, we would have needed to check the flag bits to find out which one interrupted us. We then handle it, and clear its flag. The PIC is somewhat crippled in this manner. Any and all interrupts generated and thrown into address 4 and “we” have to figure out which one occured. Many higher end MCU’s will have a table of addresses to jump to for each particular interrupt type, we then code in each location the correct routine and the processor knows which to call based on what happens.

Downloads

• Source Code (zip)

Schematic

Polling for button input, how useful! This is pretty brief and gives a good idea how to let buttons control your programs execution.

In this tutorial I’ve switched from using an oscillator to using a crystal. This changes the design a bit. Using the 2 OSC pins, OSC1/OSC2 (CLKOUT/CLKIN) they hook to the crystal in parallel. Then the two sides of the crystal are connected to ground via two capacitors, in this case 18pF. The speed and capacitance needed varies, and can be seen in most any PIC MCU datasheet as to how to lay it out. It will also be in my schematic.

Please note this is essentially NO DIFFERENT than the oscillator. It is simply a different means of providing a clock signal. You can swap in the oscillator to the normal CLKIN pin and it will work just fine.

For this program, we’ll start the processor, and wait for a button to be pressed. After it has been pressed we’ll essentially execute the LED blinker from before.

Polling is extremely simple. Polling is the act of checking something for a certain state to occur. In our case, we poll PORTB,4 waiting for it to go low. Once it does, we continue on and start blinking.

Circuit Image

Another topic that needs to be covered is that of Pull-Up resistors. In order for a button to be able to change from 0 to 1 (Ground to 5V) we need a way to protect everything from a short circuit. We do this with a Pull-Up (or Pull-Down in some cases) resistor. For our case, we connect PORTB,4 to +5V via a 10k resistor. So when we fire up the program, the PIC sees PORTB,4 as HIGH. We then connect our button to PORTB,4 on one side, and Ground on the other. Now, when we press the button, PORTB,4 is connected to ground and is now LOW. A short circuit between +5 and Ground would occur if not for the resistor, which being 10k limits the current to a measly 500uA, nothing to worry about. Once the button is released, Ground is disconnected and the pin returns to a HIGH state.

Reading the code, you may also notice the _BANK macro has changed a bit. I’ve simply modified it to encompass all possible BANK configs instead of using 4 different macros for each. Reading through it can give you a little insight as to how the conditional assembler works. It’s a bit like C/C++ and a bit like BASIC. Quite nice and handy.

A final new bit is the _MCLRE_OFF in the __CONFIG line at the beginning. This frees us from having to pull _MCLR high to keep from a RESET condition. Just keeps our parts count down.

Now for the new section of code.

  btfsc PORTB,4
    goto $-1

That’s polling, yup, that’s it. All it is doing is a bit test on PORTB,4, waiting for it to become clear (Ground). The goto line is telling it to go 1 instruction back ($ means the address of the current instruction, $-1 means one before, the btfsc). Once that pin becomes 0 it skips the loop forcing it to check, and lets it continue on down to the blinker!

Downloads

• Source Code (zip)