obligatory obscure reference

I’m really liking Adafruits “Metro Express” version of the Arduino Zero.

Except for one thing.

The UF2 boot loader.  Every time I compile and load a sketch I get a whine notification from OSX about how I’ve unmounted a volume without the proper Steve Jobs NeXT dance.

The fix is actually pretty simple — tell fstab to stop mounting the filesystem in the first place.  Apple has one solution but it needs a few tweaks for the UF2 boot system.

I'll use Adafruit's METRO as an example.  

First, use diskutil to find the UUID of the METRO:

$ diskutil info /Volumes/METROBOOT/
 Device Identifier: disk3
 Device Node: /dev/disk3
 Whole: Yes
 Part of Whole: disk3
 Device / Media Name: Metro M0 Media

Volume Name: METROBOOT

Mounted: Yes
 Mount Point: /Volumes/METROBOOT

File System Personality: MS-DOS FAT16
 Type (Bundle): msdos
 Name (User Visible): MS-DOS (FAT16)

Content (IOContent): None
 OS Can Be Installed: No
 Media Type: Generic
 Protocol: USB
 SMART Status: Not Supported
 Volume UUID: CA043DAF-C1C3-33CC-A5C4-A4B0D2BFDE85

Total Size: 4.1 MB (4096000 Bytes) (exactly 8000 512-Byte-Units)
 Volume Free Space: 3.5 MB (3530240 Bytes) (exactly 6895 512-Byte-Units)
 Device Block Size: 512 Bytes
 Allocation Block Size: 512 Bytes

Read-Only Media: No
 Read-Only Volume: No

Device Location: External
 Removable Media: Yes
 Media Removal: Software-Activated

Virtual: No
 OS 9 Drivers: No
 Low Level Format: Not supported

Now, use vifs to change the fstab file:

$ sudo vifs

and add this line to the end of the file using the “Volume UUID” field to replace [Volume UUID]

UUID=[Volume UUID] none msdos ro,noauto

save and quit, then run

$ sudo automount -vc

to update your mac with the new fstab file.

This should stop the device from automounting under OSX and make the METRO work like a “normal” Arduino.

Only tested on OS X


git diff -p --no-ext-diff
diff --git a/qmake/library/qmakeevaluator.cpp b/qmake/library/qmakeevaluator.cpp
index e9da45c..dbe8f41 100644
--- a/qmake/library/qmakeevaluator.cpp
+++ b/qmake/library/qmakeevaluator.cpp
@@ -1475,7 +1475,11 @@ void QMakeEvaluator::updateFeaturePaths()

feature_roots += m_qmakefeatures;


Under OS X 10.9 I was unable to get hp_ltt to find the newest firmware for my tape drive in interactive mode. For some reason it couldn’t verify the signature on the file or map it to the installed drive.

Here’s my workaround using the CLI version of hp_ltt:

First, run:
./hp_ltt -f scan

This will create the file ~/Library/Application Support/Hewlett-Packard/LTT/saved_scan.txt

This file contains two lines, the second has the device path at the start and the current driver version at the end

HBA_5383_65524:HP:DAT72X6:B312
path HBA_5383_65524
version B312

Then force a firmware load:

./hp_ltt -f firmware -p=HBA_5383_65524 file=/path/to/your/firmware/LTT_HP_DAT72X6_B604.frm

This has no feedback, all it does is blank the screen until the process finishes and the drive is rebooted for self testing.

Using scan again we can see that the driver was updated to B604:

HBA_5383_65524:HP:DAT72X6:B604

My security/game review from 1990 is somewhat oddly quoted in boing boing.

But one can find my original in RISKS and the obligatory chatter.

When I was a kid, I liked writing BASIC on the TRS-80 at school so much that we eventually got a C64 in the house. After that I took CS classes in colleges for fun (that is, “a minor”) and instead of going into the writing business as planned I went into the computer biz.

Twenty years in consumer electronics and a Master in Design later, I still like learning languages and new ways of thinking about computing. Last month I read the Erlang book out of curiosity and last year I started playing with machine learning using Mallet.

Through all manner of trickery I managed to avoid Python. Fixed column formatting like COBOL and Fortran? A mixture of English and symbols for logic? Typeless unless it’s not? An object-oriented scripting language that doesn’t have a two pass compiler so there’s no way to do forward references? Screw you, buddy, I’ll stick to PERL!

Then along comes Rhino 5.0 (an excellent package even in alpha) and their decision to replace Visual Basic (hack, spit) with Python so your scripts will run on both OSX and Windows installations.

Crap. I have to learn Python.

I made the mistake of starting with the Rhino tutorial, which is more of a tutorial on Rhino than a tutorial on Python. I asked my “pythoneer” friends what to read and pointed out some of my goals and favorite ways to learn. I also I had a few planes to ride, so I tried the electronic version of “Learn Python the Hard Way“. It’s an excellent book for someone who has never written a program but can be a bit of a tedious read if you’re fluent in C++ or Java and try to do all the exercises. (I did none of them. :-)

So by “too late”, I mean long after everyone else has learned it, and long after they’ve worked through all the dev problems related to moving a language up to 3.x over the space of 20 years. I’m making notes as I learn and asking some of the obligatory “why is this so stupid?” questions that come from people who either expect better or are just used to the ANSI problems in C++. (Trigraphs. Fucking trigraphs.)

I’ve written a few scripts in the past week and it feels very much like when I learned Lisp after learning C, “Interesting language, but what would I do with it?” Looking at tasks I’ll do in Rhino I think Python makes a lot of sense as the scripting language.

One place where I think it leads other languages is the class-based operations on lists and hashtables of objects. In the 3D world, your model is often nothing more than a list of (probably complex) objects, being able to write scripts that process these lists is a basic requirement.

One of my next 3D projects is to generate a model using code, and instead of OpenSCAD I can just rack a Python script and have it generate the model for me. Rather than send you the model, I can just send you the script and you can tweak it as needed then generate your model. If I decide it needs to be %5 larger to account for shrinkage, just tweak a variable in the script and run it again.

I guess reading about Erlang really was just for fun, I don’t think I’ll use it to write any model generators or filters any time soon.

Well, not open source as much as legal clone.

I’m not naming names until I test it, but for less than half of the cost of replacing the cartridges for my Epson R2400, aka “the big ass printer”, I got:

• A new set of “never empty” cartridges that never go to %0 and can’t be re-used
• An insultingly huge amount of UV dye. I got less hair dye than this in a bottle of Manic Panic, and now I have nine bottles of dye.
• Refill syringes so I can not make a huge mess refilling things

The problem we R2400 owners have is tiny cartridges that cost $20 each and that dry out, die, or get eaten by grues when they’re not used. I’ve spent over $80 on ink in the past month and made only a couple dozen prints. My studio is too dry or my printer is broken or I dunno, but I’m ready to jump ship if this ebay purchase works out.

I think it’s been 10, maybe 15 years since I’ve actually worked on open source software as an author. I’ve helped fix bugs in things like Arduino and ReplicatorG, but I haven’t done anything major on my own.

Until Friday, when my frustration with a certain class of software got the perspective and skill of my being a professional engineer. Instead of complaining, instead of getting frustrated with how someone else managers their project, instead of not being able to pull rank and make them do it my way, I can just go write my own and hand it out.

It’s a nice feeling. I don’t think I’d have gotten here without writing it-cannot-fail code for security and privacy projects as a day job. That sort of rigor is like daily exercise for the brain, like daily exercise or workouts only for the brain.

I’ve been using open source software at work since the late 80s and have spent the past couple of years experimenting with Arduino, Reprap, Makerbot, and I’m getting involved with early lasersaur development.

It’s my strong opinion that over the next year open source hardware will really start making an impact in the local and small-scale fabrication space. While there are plenty of shops using EMC2 in large-scale fabrication, the learning curve is steep and EMC2 is focused on subtractive machining operations. There are no fundamental patents on things like mills or lathes to deal with, but a lot of the control circuits and interfaces used are proprietary or at least closed source.

With lasersaur using grbl, Makerbot using (and supporting) ReplicatorG, and the increase of quality tools like Inkscape and OpenSCAD I think we’re finally seeing small-scale manufacturing with a toolchain almost entirely made of open source hardware and software. (I’m not going to wade into the argument about whether or not it’s “real” open source if you’re still buying steppers or power supplies or other COTS items. :-)

In order to help move this process along, I’ve created a new mailing list, opensourcefab, and am working on a wiki/web forum as well.

My goal for this list (and for the forum that will soon go online) is to create a space for those of us who want to use these tools for serious fabrication. Maybe you make/sell model railroad components or build big skeery robots or work at an in-house shop making spares but we’re all interested in the same thing — using open source tools in a production environment.

–jet

Turns out my boards were dead, MakerBot RMA’d them and the new ones seem to be working just fine for manual controls and temp settings. Will do some test runs, get some end-stops made, and post a how to in the next week or so.

Well, that didn’t go so well. After a couple of weeks of fussing and fighting with Gen 4 electronics it appears I have a bad motherboard. Countless hours of diags down the drain because of a bad board.

Something we in the open source hardware need to adopt is the idea of standardized tests / QE. If I were at work, the first thing we’d have done was toss the mobo in the “to be re-tested” pile and grabbed a fresh one to see if we could replicate the problem.

On the up side, while researching the problems I was having, I stumbled across a great blog that every Makerbot owner should read.