Category Archives: OSX

How to get OS X 10.9 Mavericks and Arduino IDE to play nicely with each other

Apple tried to be smart with OS X Mavericks, developing their own FTDI drivers. Just too bad they don’t seem to work.

I have been getting nothing but “avrdude: stk500_recv(): programmer is not responding” errors when trying to upload sketches to various Arduino compatible boards.
In the end, the only thing that worked was programming the boards using a dedicated programmer (in my case an USBasp).

Some digging around forums and Apple’s support site, the following steps has solved the issue on all the OS X machines where I have tried it. In short, you need to replace Apple’s drivers with the ones from FTDI.

  1. Open a terminal
  2. cd /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns
  3. sudo mv AppleUSBFTDI.kext AppleUSBFTDI.disabled
  4. sudo touch /System/Library/Extensions
  5. Restart computer
  6. Install FTDI’s virtual COM port drivers from http://www.ftdichip.com/Drivers/VCP.htm. In version 2.2.18 this package contains two executable files, I have had success with the one named FTDIUSBSerialDriver_10_4_10_5_10_6_10_7
  7. Restart again (might not be needed, good practise though after installing drivers)

Voila – The Arduino IDE can now upload sketches to all boards I have tried, both with the old/legacy bootloader and Optiboot.

Burning ISOs to USB sticks on Mac / OS X

For some reason i cannot get the easy-to-use tools out there for burning ISOs to work… Command line to the rescue:

First, make sure Homebrew is installed. It is strictly not needed for the burning-to-thumb-drive process, but will enable the progress indicators, which are quite nice to have for long running tasks. Now install Pipe Viewer from Homebrew:


$ brew install pv

Now we need to figure out the device name of our USB drive. In a terminal window (you are using iTerm2 – right? Infinitely better than OS X built in Terminal app):


$ diskutil list

#: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *251.0 GB disk0
 1: EFI EFI 209.7 MB disk0s1
 2: Apple_HFS Macintosh HD 250.1 GB disk0s2
 3: Apple_Boot Recovery HD 650.0 MB disk0s3
/dev/disk1
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *320.1 GB disk1
 1: EFI EFI 209.7 MB disk1s1
 2: Apple_HFS SSD backup 180.0 GB disk1s2
 3: Apple_HFS Temp 139.6 GB disk1s3
/dev/disk2
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *1.0 TB disk2
 1: EFI EFI 209.7 MB disk2s1
 2: Apple_HFS Macken_Ext Backup 999.9 GB disk2s2
/dev/disk3
 #: TYPE NAME SIZE IDENTIFIER
 0: FDisk_partition_scheme *8.0 GB disk3
 1: DOS_FAT_32 WHEEZY 8.0 GB disk3s1
$

/dev/disk3 is the USB thumb drive. I previously had another Wheezy image on it, thus its name.

Now unmount it:


$ diskutil unmountDisk /dev/disk3
Unmount of all volumes on disk3 was successful
$

Nice. Now let’s write the ISO to the drive:


$ pv -petr ~/Desktop/debian-7.2.0-amd64-DVD-1.iso | sudo dd of=/dev/disk3 bs=128k
Password:
0:00:38 [4.94MiB/s] [====>                  ] 3% ETA 0:16:55

Now let’s wait. Looks like it will take approximately another 17 minutes..

When done, just eject the thumb drive as usual, remove it and you have a bootable Debian install drive. Mission accomplished.

Reverse engineering Macbook Air FaceTime camera, part 1

A severely cracked 13″ Macbook Air display came my way some time back. The LCD panel was obviously damaged, but it would be interesting to see what makes such a great display tick, and maybe parts of it could still be used? I believe the display came from a Late 2010 Macbook Air (which would indicate an A1369 type construction), but can’t be sure. Anyway – ideas included

  • Keeping the back lighting (assuming it works) and camera, mounting the whole display on a flexible arm next to the work bench. Given the high intensity of the back lighting, it could then (maybe) provide ambient lighting AND video recording of whatever was being worked on. Maybe with a LED light and camera on a separate flexible arms.
  • If the LED backlighting drivers were toast, there should still be some nice white LEDs in there for scavenging.
  • Same thing for the camera, I believe it to be a 640×480 pixel device, nothing too exiting but could still be useful.

Turns out it’s not entirely easy to disassemble these displays. They are sealed together with very strong tape. Heating the bezel helps a lot, but it’s still a fair amount of work – and given the delicate components beneath the bezel, you might want to think twice before doing this on a laptop you care about.. Some good instructions found here, btw. Results so far:

2013-02-19_10-41-22_smallPrying the bezel open…

…before applying heat with a hot-air SMD rework station (regular heat gun would probably also work, if you are careful):
2013-02-19_10-44-38_small

Voila! Bezel is free:
2013-02-19_10-56-14_small

Now the tricky part. The cable from the cable is a thin wire with some kind of textile cover, for strengths I assume. It goes through the hinges and there is no way (as far as I can tell) to get the cable through there, without cutting off the (very small) connector that normally connects to the computers Left I/O (a.k.a. LIO) board. Cut.

Now the whole camera assembly can be removed. It also includes the ambient light sensor, which communicates over I2C. Unknown protocol for that one though – one for the future to investigate..

2013-02-23_22-55-38_small
Very tiny 6-pin connector, normally going to the LIO board.
2013-02-19_13-11-34_smallCamera module exposed in the top part of the screen. Held in place with 2 small screws.


2013-02-23_22-32-08_smallCamera board. 

2013-02-19_13-17-59_smallThese things are small – fingers included for scale reference.

With six wires in the cable it’s pretty clear that 4 are for USB (+5V, Gnd, Data+, Data-) and 2 for I2C. That cable is however crazy small – it’s about 2 mm diameter. Once the outer layer is off, you see 6 even thinner cables. 2 are black, 4 transparent. Which ones are which?

Google is your friend. Turns out there are schematics to be found if you Google long enough. Turns out you need schematics for the LIO board though, in order to get the pinout of the camera/ALS cable, and it’s nowhere to be found for the A1369. Did find a schematic for the A1370 model though (same computer but 11″ screen), with a bit of luck that cable is the same between models.

The 2 black ones are prime candidates for +5V and Gnd. Cutting away the insulation revealed that the cables are shielded, with a center wire that is barely visible to the eye. It took several attempts before I had separated the wires from the sheilding, and then done the same with the other 4 wires. Soldering these onto an old USB cable was then easy (but ugly!!):

2013-02-28_14-09-48_small

Still, it doesn’t work. The camera is not recognised on an iMac with latest OSX, nor on a Windows 8 laptop. Happened to have a Raspberry Pi lying on the work bench, tried it too with same result: nothing.

But wait… doing a “tail -f /var/log/messages” on the RPi showed that it DID recognise the camera, but that the camera wanted more power than a non-powered USB hub could provide! Placing the camera into the RPi’s regular USB port made it appear nicely when doing a “lsusb” command.

Still, it didn’t work when I connected the camera to the Windows or iMac machines – strange.

Also, the RPi loose contact with the camera after a while – no idea why. Could maybe be a bad USB cable (it’s from an old mouse using USB 1.1 – maybe that’s a problem??), or is there too much noise introduced by the ugly splicing of cables that I’ve done? No idea… More investigation needed. Anyway, the camera enumerates with USB id 05ac:850a, which indeed is an Apple FaceTime camera – nice!

iTerm2 + tmux + Fish = looks great!

If you spend any time at all at the command prompt in OSX or other Linux-ish systems, tmux is a must. Basically it gives you persistent shell sessions, once using it you’ll wonder how you ever got by without it… 

For OSX the easiest way to get tmux is via (the also excellent) Homebrew. After installing Homebrew, just do a 

brew install tmux

from a OSX prompt (you ARE using iTerm2, right? …Rather than OSX’s rather horrible built-in Terminal app…?)

Add to the mix the nice Bash replacement Fish, which gives you all sorts of command line goodness (color coding, auto-completion, …). Very nice!

 

Dell’s WinXP installer messes up OSX partitions when using Boot Camp

A few days ago I decided to install WinXP on my Intel based iMac, using Boot Camp.

Boot Camp assistant worked great, it created a new Boot Camp partition on the hard drive just as planned with a 32 GB partition. Popping in a Dell WinXP SP2 CD (from a now long gone computer) as instructed, but when prompted to select where to install XP the Boot Camp partition was gone. In fact, so was the OSX partition…
The weird thing was that the XP installer suggested I should install it to a 131 GByte partition on the disk – where did it get that from?

Luckily I have a nightly Carbon Copy Cloner job scheduled for the iMac, so restoring the OSX disk was pretty straightforward (even though it took some 5-6 hours to restore 500 GB of data).

Tried the same procedure twice more. Once with the same result, and once I the OSX partition was actually intact. But XP still suggested I’d install it to the non-existing 131 GB partition.

Fourth time I tried another XP disc, and this time also slipstreamed it with SP3 using nLite (awesome product!). And now it worked flawlessly.

After doing some research it seems that some people are having trouble using Dell XP CDs with Boot Camp. Not sure why, but using that other, generic XP CD made the problem disappear. Or if it was the SP3 slipstreaming – either way it now works. I guess you could argue that the Dell CD was intended to be used with Dell machines only, and in this case that  turns out to be true.. Anyway, with the problems sorted out, dual booting works great!