Rascal 0.3 in the works

The circuit boards for the next revision of the Rascal arrived from Illinois while I was in New York for the Open Hardware Summit.

The new board has a few changes that I hope will be improvements. On the bottom of the board, the programming connector is replaced with just a set of flat pads. The goal is to allow the boards to be programmed without soldering a connector to the board.

I made an adapter that converts the 20-pin programming connector to a smaller Samtec connector with spring-loaded pins. Instead of straight, stiff pins, the Samtec part (FSI-110-06-L-D-E-AD-TR, if you're interested) has pins that bend into a loop at the end. As you press the connector against the board, the loops flex, making a low-resistance connection between the pin and the pad. In theory, the scrubbing of the pin loop across the pad is supposed to clean oxidation off the contact. I measured the contact resistance at 0.2 ohms.

The connector also has locating pins to insure that the pins are lined up correctly and can be held in place with #2-56 bolts.

One experiment that turned out reasonably well is the logo I added to the board. The Rascal circuit board is a 4-layer board, meaning that the board consists of 4 layers of copper interleaved with 3 layers of fiberglass. As is common with 4 layer boards, the two inner layers are power planes, meaning that they're mostly solid copper sheets connected to +5 V or ground. Because many chips have multiple power and ground connections, this makes routing those connections very easy-- next to each pin that needs a power or ground connection, you just drop a via to the correct power plane, and you're done. Also, the large ground plane act as low-inductance return paths for the currents flowing in traces, thereby minimizing the noise that high-speed signals in one trace induce in nearby traces.

Looking at the last revision of the Rascal, I noticed that the edges of the board were translucent, because the power planes are pulled back from the edge by 1 mm or so. I thought I might be able to use the translucency to make a cool effect. To embed the logo, I made a gap in the outer copper layers and added the text to the internal layers. At first glance, the logo is invisible, but when you hold it up to the light, the fiberglass is translucent, but the copper is not. The logo font is not correct, because the Rascal logo is actually slightly tweaked from a commercial font, but I'll fix that later.

The next Rascal should be ready on Wednesday, October 6, 2010. In addition to the logo and the secret JTAG port, the new rev will also have a serial flash for the bootloader and the Ethernet port correctly terminated, biased, and decoupled. If all goes as planned, it won't spontaneously switch to half-duplex mode any more, and it will be able to boot Linux without any human intervention.

Thoughts on the 2010 Open Hardware Summit

Last Thursday, I went to the Open Hardware Summit in Queens, NY. The Summit had a lot going for it-- people from all of the major open hardware players were there (Arduino, Adafruit, Sparkfun, Bug Labs, and Beagleboard, to name a few), and it took place at the New York Hall of Science, a cool science museum right next to Flushing Meadows with its enormous, awesome Unisphere.

For the past few months, I have been working solo on a device that I intend to be open hardware. In my circumstances as not just a "small business," but the smallest possible business, the crucial question is whether opening my hardware designs to the world will result in someone taking a design and replicating it more cheaply than I can, thereby stealing all my customers. Against that fear, I have the hope that opening my designs will result in people improving them in ways that I can't predict.

This issue came up repeatedly at the summit. Many of the speakers were actually building and selling open hardware. Very few came from VC-funded companies (Bug Labs is the notable exception). Most of them were engineers who had bootstrapped their way from a few small designs they made themselves. They are evidence that my fears are unfounded, particularly in my current state of obscurity.

The explanations varied. Limor Fried of Adafruit said something like, "People say they will copy you, but it's hard to actually do. . . . Being obscure is worse than being ubiquitous." (A video of her talk is now available.)

In a later talk, Chris Anderson, who runs DIY Drones, mentioned the power of the community. They design small, autonomous aircraft and release all the plans on the internet. Their customers buy the electronics from DIY Drones and then tweak them. Anderson isn't worried about closed competitors: "We think the customers will go with the community." He also pointed out that the community of drone zealots was innovating faster than most private companies; even if you were to copy the hardware today, you'd be obsolete in short order.

After one of the panels, I talked to Nathan Seidle of Sparkfun for a few minutes. Sparkfun is the internet version of what Radio Shack was in the 70's, when they sold lots of electronic components. They have over 80 employees and around $10M in annual revenue. I asked Nathan why Sparkfun, if run by an evil version of him, wouldn't just collect open hardware designs and start replicating them. His answer was that breaking the trust of the community like that would devastate his sales.

Later in the day, I talked with Chris Gammell of the Amp Hour for a few minutes. He said that he was worried about what was going to happen when larger distributors enter the open hardware market. This is an interesting point viewed in the light of Nathan Seidle's and Chris Anderson's comments about the trust of the community. When the open hardware community is a small subgroup of a 10-100 thousand people forming a somewhat cohesive culture, losing the support of the community might be catastrophic. But if the electronic hobbyist world grows so that most of Sparkfun's customers don't even know that the hardware they're buying is open, it might be worth it for a giant like Digikey to risk alienating the hardcore open hardware folks. The situation might be like the libertarian anti-Obamacare editorial published by the CEO of Whole Foods in the Wall Street Journal last year-- hardcore liberals started boycotting Whole Foods, but the majority of their customers didn't care, because have you tried their almond cookies?

For me, as a new entrant to the market, I have no worries about a large corporation stealing my ideas-- risking the $100,000 it would take to beat me on volume on the hope that this solitary engineer has come up with a winning product would be colossal folly. I do think that the Rascal will be a great product, but it's definitely not there yet, and it will take a community of users to get it there.

Footnote: mbed.org

One other interesting note-- during lunch, I met Simon Ford and Dan Ros of mbed.org, a small group within ARM that is making development tools for ARM processors. The Mbed is not fully open hardware, though they do distribute schematics of the system. Simon said it was because he wanted to be sure they were built right.

The Mbed is an interesting board. It actually has two microcontrollers on it. The main processor, on top, is an LPC1768 running at 96 MHz. There is a second processor running at 12 MHz on the underside of the board that acts as the programmer for the first processor. You compile your code on their website and then transmit your programs to this supervisory processor via USB. It puts the code on the second processor via JTAG. The advantage of this is that the main processor behaves exactly as it will in a final design. You can design a device using the mbed, and when you're done, you can buy the same LPC1768 processor and replicate what you've got, minus the second processor, which is no longer necessary. It's an elegant architecture.

Alpha prototype out the door

I just sent the first working version of the Rascal to a friend of mine in California who has been helping with Rascal software development and debugging on the side. The hardware, which uses the second PCB revision, is not flawless, but it works well enough to download and boot Linux via TFTP and serve web pages.

It feels good to be shipping something to someone, even if he's not a paying customer.

Rascal 0.2: launching rockets at the sky

The second revision of the Rascal arrived in mid-August. After a little mucking about with a JTAG pod, it can execute code.

A lot of my friends have been asking me whether the Rascal is ready for action now. The hardware is in good shape-- it's not flawless, but it's somewhere above 95% operational. The remaining work is the software, which seems easy, maybe because it's made of electrons. It's not actually easy, so I thought I should explain some of the details.

Making the Rascal load an operating system like Linux or Android is more complicated than you might expect. (The good news is that I've already done the hard part for you; once the code is configured correctly, it boots automatically when the Rascal is turned on.)

When I got the first Rascals back from the assembly house, all of the memory was blank, except for a small chunk of code that the chip manufacturer, Atmel, burns into every chip. I added two other pieces of software, called bootloaders, to help start up an operating system.

Three levels of bootloaders

The first chunk of code, burned into memory by Atmel, is called the ROM Boot Program. It switches the processor from using a low speed oscillator to using a high speed crystal, which drives a frequency-multiplying circuit called a phase-locked loop. This kind of hardware initialization is needed no matter what you're doing with the chip, which is why Atmel includes the code. (Strictly speaking, you can bypass it in some chips, or if you have a certain kind of memory attached to your chip.)

When the ROM Boot Program ends, it starts the next program, which is called AT91Bootstrap. This program, which works with all processors in the AT91 series, configures the processor to talk to all of the peripheral chips on the Rascal PCB. Atmel made the first version of AT91Bootstrap; I edited the source code slightly to fit the wiring of the chips on the Rascal circuit board and recompiled it to make a new program just for the Rascal.

AT91Bootstrap has a few jobs, but most importantly, it configures the memory bus, which allows the use of external RAM and Flash chips. (Rascal 0.1 had a problem with the memory bus, so this was as far as those boards could get.) The last job of AT91Bootstrap is to copy the third bootloader, U-boot, into RAM from Flash.

Booting the Linux kernel

U-boot is somewhere between a bootloader and a minimal operating system. It can load files into memory, tell you the status of different hardware components, and download new code from the internet.

Here's an example of using U-boot to query the Rascal's Ethernet controller.

language-bash U-Boot> mii info PHY 0x00: OUI = 0x0885, Model = 0x11, Rev = 0x02, 10baseT, HDX U-Boot> mii dump 0. (3100) -- PHY control register -- (8000:0000) 0.15 = 0 reset (4000:0000) 0.14 = 0 loopback (2040:2000) 0. 6,13 = b01 speed selection = 100 Mbps (1000:1000) 0.12 = 1 A/N enable (0800:0000) 0.11 = 0 power-down (0400:0000) 0.10 = 0 isolate (0200:0000) 0. 9 = 0 restart A/N (0100:0100) 0. 8 = 1 duplex = full (0080:0000) 0. 7 = 0 collision test enable (003f:0000) 0. 5- 0 = 0 (reserved)

In actual operation, U-boot doesn't do very much other than load Linux from Flash into RAM, and then start executing it. In the long run, we might change the Rascal so that AT91Bootstrap loads and boots Linux directly, but for development, having the flexibility and diagnostic capabilities of U-boot is great.

There are still more layers of user software to build on top of the operating system, but I hope this clears up some of what I've been messing around with the past couple of weeks.