New in the NYCR vending machines are Teensy 2.0 boards. They have ATMega32U4 chips, which have the built in USB drivers and, via LUFA, can appear as any USB device, not just a serial communications device. Want to make a MIDI device show up as a USB keyboard? Or a core memory as a mass storage device? You can do that! The USB doesn’t consume a UART, so there is still a serial port available for interfacing with GPS or other external RS232 devices.

PJRC makes the Teensyduino plugin for the Arduino IDE and a set of compatible libraries so that you can use it with your Arduino sketches. Or you can drop into straight C and take full advantage of all of the AVR pins.

Update: They are very popular! Three were bought during Craftnight tonight.

As part of my on-going quest to fill my apartment (and hackerspace) up with semi-working 1970′s supercomputers, my effort to revive the Cray-1 supercomputer needs your help! Through the grapevine, I managed to get my hands on a genuine backup disk pack of the once-thought-extinct Cray Operating System (COS). Using my homebrewed disk reader I was able to make a copy of the disk, and the folks over at the internet archive (thanks Jason!) were kind enough to host it for me. Now is where you, kind reader, come in! Help me reverse-engineer the file system so I can recover the actual operating system files and take a step closer to towards booting this awesomely-useless machine!

Download it and get hacking!

Some friends at a local university reached out to us recently and offered to let us rescue a robot from a junkyard fate. Not being in the business of turning down free robots, we quickly agreed. Three of us showed up on Monday in a Ford Escape. We left in a U-Haul.

This beast of a machine weighs in at 550lbs. It’s a Gilson Cyberlab C400 Automated Plate Preparation Workstation. We’re not exactly sure what that is, but we do know that it has a huge robotic gantry meant to move at high speed with accurate positioning. And it has neuroprobes. What are we going to do with it? Maybe it will be the next BarBot. Or a 3D Printer. Or maybe some sort of exercise machine. We’re not sure yet. Check the vids.

Using Darrel Tan’s Programming the ATTiny10 instructions and a SOT-23 breakout board by Raphael, I was able to flash one of these very small MCU chips. Given the small package, these programmable devices can be dropped just about anywhere on a circuit that a transistor would be used.

Unlike Tan, my FTDI breakout cable does not have DTR, so the reset pin on the chip needs to be pulled low manually to put it into programming mode, and the pinout adjusted. Full instructions after the break…

TXD (Orange) --/\/\/--+
                      |   +----------------------+
CTS (Brown)  ---------+---| TPI DATA (1)   RESET | ------+
GND (Black)  -------------| GND              VCC | ---+  |
RTS (Green)  -------------| TPI CLK           NC |    |  |
                          +----------------------+    |  |
                                                      |  |
VCC (Red)    -----------------------------------------+  |
                        \                                |
GND (Black)  ---------   \-------------------------------+

In /usr/local/etc/avrdude.conf add:

programmer
  id    = "dasaftdi";
  desc  = "tiny10 no reset, sck=!rts mosi=!txd miso=!cts";
  type  = serbb;
  reset = ~4;
  sck   = ~7;
  mosi  = ~3;
  miso  = ~8;
;

Test program to generate a square wave output on pin D2. My version of avr-gcc doesn’t support the ATTiny10, so I’ve hardcoded the register assignments and pass in the wrong device name to the compiler.

#define DDRB2 2
#define DDRB 0x01
#define PORTB 0x02

.global main
main:
        ldi r16, (1 << DDRB2)
        out DDRB, r16

loop:
        ldi r16, (0 << 2)
        out PORTB, r16
        nop
        ldi r16, (1 << 2)
        out PORTB, r16
        rjmp loop

Compile and generate an Intel hex file:

avr-gcc -mmcu=attiny11 test.S -o test.elf
avr-objcopy -O ihex test.elf test.hex

Manually pull the reset line to ground and flash with this command (substitute the correct path to your FTDI device:

avrdude \
  -p attiny10 \
  -c dasaftdi \
  -P /dev/tty.usbserial-FTE531WL \
  -U flash:w:test.hex

If all goes well, release the reset line and put a scope on pin 4. You should see something like this:

Inspired by Ranjit’s instrument-a-day (Make coverage), I’m writing a new wrist watch face every day for my progamable inPulse watch (more background). The full sources are posted online for others to build on.

Day 1 was a fixed point 3D rendering engine with a rotating Utah Teapot, day 2 was a rolling odometer or aviation altitude ticker display and day 3 is a 24-hour analog clock. This last one still needs some work.

The inPulse watch is a great platform to hack on. It has an ARM7, 32 KB of flash and 8 KB of RAM, Bluetooth, a buzzer, an OLED screen and a button. Not much by today’s standards, but plenty to play around with. The programming environment is very much like a microcontroller; no multitasking, no dynamic memory, and very constrained memory/cpu. That is, of course, what makes it so much fun.

My multi-app framework attempts to make it possible to write multiple apps that can share the limited RAM by a technique similar to FORTRAN COMMON blocks. The main app.c file has the mainloop that calls the loop() method of the current app. This main loop also does a static allocation that fills the entire BSS; each app that is linked in rewrites it with its own local state while it is running. When the user holds the button for two seconds, the main app selects the next linked in app and call its init() method to allow it to perform its setup.

Since some of the apps need trig functions and there is no floating point support, I’ve written a fixed-point sin() and cos() function that are within +/- 0.0075 of the real sin function. Close enough for most government work… The function and lookup table consume 157 bytes of flash and no precious RAM. I haven’t benchmarked the performance, although most of the apps already have time-delays to only redraw the screen at 30 fps.

There are still several things that need to be done to make the watch usable as a watch. The most important is power management. Even in “powersave mode”, the battery runs dry in about three hours. Clearly it is not saving much by turning off the display.

The other two major requirements are a local build environment and a more accurate simulator. The cloud-compile environment does make it easy to get up and running, but there are many things that a local build would make easier. For instance, the Bluetooth stack is always linked in even if it is not used, leaving less RAM and flash to the user. Or figuring out why calling snprintf() breaks everything. Hopefully they’ll release the local SDK soon.

Until then, the developers hang out on the inPulse forum and have been super helpful with debugging some of the getting-started difficulties.

What better way to spend a hot, humid Sunday Brooklyn afternoon than checking out Buzz-A-Rama, a 1960′s era slot car parlor in Kensington? Inside this unassuming storefront are 4 or 5 large twisting tracks, where children and adults race cars about 3 inches wide by 6 inches long, much larger than the matchbox-sized slot cars I played with as a kid. Amateurs like us use slow cars rented from Buzz. The pros, however, bring their own custom lightning-fast cars and controllers, and they are quite serious about them.

The car chassis are cut from lightweight aluminum composite using electrical discharge machining. Motivation is provided by high-performance brushless DC motors. Wheels and tires are made of special sticky, heat-resistant rubber, with a set of chemicals and rituals for cleaning and warm-up before a big race.

The lightweight plastic body can be either an aerodynamic wedge shape that directs airflow up, forcing the rear wheels down for better traction, or a more traditional scale model of a production muscle car. Super-cool retro body styles are available as well.

The controllers are also semi-custom built, and are adjustable by the operator to conform to his or her desired level of aggression in acceleration and braking.

You can buy the cars as ready-to-run products, but many racers customize theirs and/or build their own from the ground up, choosing the best components, and tweaking them for the best performance. The cars we saw were mostly made with components from Koford Engineering, and the controllers were from DiFalco Design, although apparently there are other companies serving this market as well. The fastest ultra-light cars we saw cost as much as $500.

Buzz has a good stock of generic aluminum and brass bar stock, motors, electrodes, dremel bits, lubricant, etc., behind the counter, so this could be a handy resource for local hobbyists and hackers building other electro-mechanical gadgets as well.

Buzz-a-rama is only open on weekends, and it is closed for two months in the summer starting tomorrow, but if you get a chance, stop by and check it out. It’s worth the trip:

Buzz-A-Rama
69 Church Avenue
Brooklyn, NY 11218-3791
(718) 853-1800
View in Google Maps

Some more photos are in my Flickr Buzz-A-Rama Set. You can read more about Buzz-A-Rama at nytimes.com and kensingtonbrooklynblog.com

During Hackday I worked on a display for the Stabby ID.

I have six or so HDSP 2111 units lying around. They also come in green and red led models.

Read on for Schematic and Demo Arduino Source

Requirements:

1 HDSP 211x LED Display
1 SN74LS595N Low Current Shift Register
1 Arduino compatible board
1 current reference capacitor ( just for safety )

Schematic:

Source:

Video of our presentation at Hackday:

In the video,

Ben Combee is speaking, Max Henstell is working the stabster’s pneumatics and Mark Tabry is standing by to protect bystanders, and I am off camera to the left looking pretty for the cameras.

Not in the video is Bill Ward, Charles Pax, as well as the original Max.

* Special thanks to my friend Adam from Twilio who provided us with some assistance in the effort.

For the blow by blow of the event check out our time lapse. Trust me it was 24 hours of tedium just as grueling as watching this 2.5 minute clip.

As you can see this was an pretty large effort by NYCR and a hell of a lot more went into this project than is readily apparent. Just getting the equipment there was an event all its own. Max and Charles worked tirelessly to repair Stabby’s pneumatic stabber arm. Max also worked on wiring up the actuators and accompanying arduino code to link up with Ben, Bill, and Marks twilio interface code base. I worked with Mark on a display that showed debug info from the arduinos ( blogarythmic cred ) as well as caller ( aka stabber ) id when stabbing.

We finished up about 5 minutes before time was called… literally. Came down to the wire. Stabby was awarded a runner up award, and supposedly will be on display at Tech Crunch on Wednesday some time during the day.

We had a hell of a lot of fun, and were excited to present a functioning project ( a first for me =P ). Even more exciting was winning a runner up award in a contest that didn’t actually have runner up awards. I guess they were afraid of being stabbed.

We’re time lapsing, and Mr Stabby is here getting his API action on… literally.

Stop by what we are calling battle station resistor in the deep recesses of the hacker caves.

If you have spare sparkfun line relay breakouts… we could use 4 to six if you have some to spare… otherwise we’ll be rube goldeberg a solution.