When I talk to people about the Rascal, they often ask about the differences between a Raspberry Pi and a Rascal.

Summary: if you want the cheapest possible computer, buy a Raspberry Pi. If you want to control some Arduino-style hardware from your web browser and you're a busy person, buy a Rascal.

The Raspberry Pi on the left, the Rascal on the right

The two boards have a lot of similarities, but a few major differences as well. Let's run through the similarities quickly.

Similarities

• Both the Raspberry Pi and the Rascal run Linux.
• Both store their filesystems on SD cards.
• Both use ARM processors.
• Both have an Ethernet port (Raspberry Pi Model B only) and two USB host ports.

Differences

I'll get to the specifics of the differences shortly, but let me explain what drives most of the differences: the two boards are intended for different purposes.

The Raspberry Pi is made by a nonprofit foundation in the United Kingdom for the purpose of teaching kids to program. To quote their website, "We want to see it being used by kids all over the world to learn programming. . . . Our main function is a charitable one – we’re trying to build the cheapest possible computer that provides a certain basic level of functionality . . ." The Raspberry Pi has connections for a monitor and keyboard.

The Rascal came from my work as an embedded systems engineer. I was frustrated that I couldn't buy an embedded Linux board that was preconfigured for controlling Arduino-style hardware from the web. I designed the Rascal so that I could plug Arduino shields directly into it, and I wrote the software using a modern web framework so that I wouldn't have to set that stuff up every time I started a new project. Then I added a code editor and wrote a Python library to make it even easier. The Rascal doesn't use a monitor-- you interact with it through your web browser.

Here's a summary of the differences.

Wait, if the Rascal has a slower processor, why would I pay more for it?

In the end, the decision comes down to the value of your time. Almost anything you could do with a Rascal, you could eventually do with a Raspberry Pi, if you're willing to learn a lot of Linux programming. If you're a Linux-savvy person just playing around with embedded computers, and tweaking the Linux kernel sounds interesting, you can save some money with the Raspberry Pi. If you're new to embedded computers or you just need to get something done quickly, I think the extra cost of the Rascal is worth it.

This post is to preview some of the stuff that I've been working on for the Rascal.

Suppose you want to build a pulse counter so you can tell how fast a motor is spinning. The pulses are coming out of the motor at around 10 kHz, i.e. at 10,000 pulses per second.

The Linux kernel that runs on the Rascal doles processor time out to different programs at 100 Hz, i.e. in 10 millisecond chunks. For example, the Rascal is constantly running a webserver, but also a program that watches for new USB hardware. The Linux kernel schedules those different programs so that they can share time on the same processor. If you were to add code that checked whether a pulse had arrived, it would share time with the rest of the processes running. With this kind of process scheduling running, reading pulses 10 times per second can be done, but reading pulses at 10 kHz is hopeless.

How do we think about this kind of stuff?

In my mind, I divide tasks into four groups:

1. Simple and high latency is OK, like tripping a relay to drop a box over a turtle. Any microprocessor can do this.
2. Complex, but high latency is OK, like image analysis or serving web pages. The Rascal wins at this.
3. Simple, but low latency is required, like counting pulses from a motor. A microcontroller like the Arduino wins at this.
4. Complex, but low latency is required, like using facial recognition to pilot a drone toward a target in a crowd. We can't do this on one processor.

Diagram that shows what kind of device to use for different tasks

In theory, you could change the Rascal's operating system so that the scheduling interval was much smaller, so you could actually check for pulses much faster. The problem with this approach is that every time you stop a process to run your pulse counting program, you burn some time in the switch. Eventually, your system is spending more time switching processes, and your pulse counter starts missing pulses.

Codename Slingshot

A better approach is to use a secondary processor that can handle the low-latency stuff. I've been prototyping this kind of realtime coprocessor as a shield that can plug into the Rascal's headers. For lots of tasks, you could use almost any microprocessor, so long as it doesn't have an operating system. To make things easy, I'm prototyping with an Arduino kit. In the long run, I will probably use a small ARM processor, maybe something like the Cortex M3 used on the Arduino Due. For the meantime, I'm using an Arduino Uno and calling the project codename Slingshot. (Thanks to Dan Beyer for the naming suggestion. He thought a slingshot was the sort of accessory a rascal would keep close at hand.)

In the pulse counter example, the Slingshot counts the pulses very quickly. When the Rascal has a 10 ms slice available, it asks the Slingshot for the count. The Slingshot dumps the answer into its I²C hardware, which talks to the Rascal while the Slingshot keeps counting. In the long run, I would like the Rascal to come with a Slingshot built in, and with a pile of different programs available on the Rascal. If you want a pulse counter, you just select the pulse counter option, and the Rascal drops it onto the coprocessor for you.

The picture below shows the first attempt at the Slingshot. It's just an Arduino with some parts missing, but I think the functionality will be great.

The Slingshot running off the Rascal's power supply, connected to the Rascal via I²C

I've left out the original headers and the power circuitry from the Arduino kit. For the power connections and I²C, I soldered pins in the open holes. These pins allow the Arduino to draw power from the Rascal's power supply and talk to the Rascal using I²C.

Anyway, this marks the beginning of the Slingshot. I think the Rascal/Slingshot combination will be powerful when the Slingshot is done.

Other folks doing this kind of thing

I would remiss if I didn't mention that lots of other people have done this sort of thing before. In the open source hardware world, there's the Wyolum Alamode board, which is an Arduino that plugs into the Raspberry Pi and can talk over the serial port. One of the guys behind the Alamode, Kevin Osborn, works out of our local hackerspace here in Somerville, so I've talked this stuff over with him a few times.

One of the early Rascal customers was the Massachusetts General Hospital Learning Lab. The Learning Lab has been developing an attendance tracking system using 125 kHz RFID cards. In their current system, each card reader talks to an Arduino microcontroller using the Wiegand protocol; the Arduino talks to a PC over a USB cable; and the PC talks over the local network a database server to determine whether a card is valid or not.

The folks at the Learning Lab wanted to replace the PC and the Arduino with a Rascal, so I offered to help them interface their Wiegand card reader with the Rascal. For testing purposes, I got a cheap Wiegand protocol card reader off of Ebay. A little googling revealed that a gentleman by the name of Mark Jason Anderson had already written a Linux driver for Wiegand card readers. He used some CPU-specific kernel functions in his code, but luckily he was using the same Atmel AT91SAM9G20 processor that I use for the Rascal. I forked his wiegand-linux repository to my own on Github and modified the code slightly to use pins that the Rascal breaks out to its Arduino headers. I was able to build the kernel driver with the same cross-compiler I use for the Rascal kernel. The details of setting up the ARM cross-compiler are covered in the Rascal build guide.

There was one other challenge-- the card reader idles at 5 V, but the Rascal expects 3.3 V on its inputs. To scale the voltage down, I used a circuit not unlike the 2x voltage divider on the Sparkfun level shifter. The picture below shows the circuit. I used 4.64k and 9.09k resistors to scale the voltage down. In theory, this would reduce a 5 V signal to 3.31 V; I measured it at 3.29 V, so it was pretty close. I suspect that a 5k and 10k resistor would work fine, but I found the other values in my bins first.

Circuit used to scale Wiegand card reader's 5 V down to 3.3 V for the Rascal inputs

The earlier kernel driver build provided me with a driver binary called wiegand-linux.ko. I copied that to the Rascal. For testing, I was able to insert it into the running kernel like this:

insmod wiegand-linux

After this, the following shows up in dmesg:

wiegand intialising
wiegand ready

To make the kernel load on boot, the binary should be moved into /lib/modules/2.6.36+/ and the full filename, wiegand-gpio.ko, added to /etc/modules.

When a card is held next to the card reader, it beeps, the diamond flashes green, and we see new text in dmesg.

1 0 0 1 0 0 0 0 0 1 1 1 1 1 1 1 0 1 0 0 1 0 0 0 0 0 wiegand read complete
new read available: 32:65168

The new card data is also available from /sys/kernel/wiegand/read.

In the long run, I'd like the RFID reader to display some confirmation that it's working properly on a display, so I hooked up a 4D Systems LCD that I had from a different project. Here's the whole assemblage.

RFID reader and LCD plugged into the Rascal

The last step is to pull data from /sys/kernel/wiegand/read and display it on an LCD. (Of course, the Rascal should also do something useful like unlock a door or log the card number to a database, but this is just a demo.) I wrote a short RFID monitoring Python script that does this on the Rascal. It would be nice to use the Rascal's Python server, uWSGI, to watch for new cards and trigger the Python so a second script wouldn't be needed, but that would mean writing a libudev plugin for uWSGI. I might do that eventually, but for now, this works fine. If you take a close look at the LCD in the picture above, you can see data from the few test RFID cards that I have.

Onwards!

One of the Rascal accessories I've been working on for scientists is what I call the Precision Voltage Shield. It's a circuitboard that plugs into the Rascal or an Arduino that allows you to measure 8 voltages very precisely. Yesterday, I got the precision voltage shield working as an 8-channel digital multimeter with an Arduino. I wanted to record some of the details of how I got working for posterity.

Here's what the precision voltage shield looks like plugged into a Rascal. What a handsome devil!

An overview of how the AD7607 A/D converter works

The core of the precision voltage shield is the Analog Devices AD7607 analog-to-digital converter. This chip measures 8 channels with 14 bits of resolution. There are also 16-bit and 18-bit versions, but they cost a little more. I'll probably offer variants of the shield that use those chips if people are interested.

The AD7607 has some awesome features that make it better than a classic A/D converter like the ADC0805. The first is the input filtering it includes. When you sample a voltage repeatedly over time, you run into the problem of aliasing, where high-frequency noise exceeds twice your sampling frequency, which makes it appear like low-frequency noise. Once you've sampled it, you can't tell whether it was high-frequency noise aliased down, or real low-frequency noise, so no digital filter can help you.

The fix for aliasing is an analog filter on each input. Older A/D chips didn't have this because we didn't know how to make capacitors inside chips cheaply. Analog Devices has apparently figured this out; their datasheet claims that each channel has an analog second-order Butterworth filter that attenuates noise over 15 kHz or so. (The 3 dB point changes slightly depending on the input range selected.)

The second cool feature is adjustable oversampling. In its default configuration, when you ask the precision voltage shield for a reading, it samples 64 times and gives you back the average reading. If you want, you can cut the traces under the OS0, OS1, and OS2 jumpers to configure the sampling rate to be higher, but there's no sense in doing that unless you can actually store data at significantly higher data rates than 1 kHz. (See the notes about speed further down for some more thoughts on this.)

The third excellent feature is the adjustable input range. With a jumper on the shield, you can choose whether the input range is +/-5 V or +/-10 V. This means that you can handle large voltages while still being able to read smaller voltages accurately if you need to.

How measurements actually work

To make the shield take a measurement, you pulse pin 5, which is labeled "CONV." The shield will answer by raising its "BUSY" line for around 300 microseconds. After this, the Rascal or Arduino can read the data out using the SPI protocol on "MISO" (pin 12). The oscilloscope screenshot below shows two full cycles of voltages being read. The gap between conversions (around 1 millisecond) is the time it takes for the Arduino to send the raw data to my laptop over USB at 115200 bps. With this gap, the system cycles at 735 Hz. The precision voltage shield Arduino code that I wrote for testing is up on Github. (You are welcome to use it however you like, but I would appreciate a link back to rascalmicro.com.)

• BLUE: start conversion pulse
• PURPLE: busy during conversion
• YELLOW: digital data coming out via SPI

The precision voltage shield talking to an Arduino, captured on my trusty oscilloscope.

The AD7607 data format

The AD7607 spews out eight 14-bit measurements sequentially, each ranging from -8192 to 8192 to represent either -5 to 5 V or -10 to +10 V, depending on how the range jumper on the shield is set. The readings are encoded as the two's-complement of the count.

Sampling speed

By default, the precision voltage shield oversamples by 64x and averages the values. As mentioned earlier, you can speed this up if you want, but you need a way to store the data.

The Arduino Uno I was using to talk to the shield has 32 kB of flash memory. If the Arduino pulls 8 readings at around 1 kHz and stores each reading in 2 bytes, that's 16,000 bytes per second, which means that the Arduino is full in 2 seconds. Some scientists do experiments that last less than two seconds, but many (most?) last much longer, which means we need a way to get data out of the Arduino.

I tried two different methods of sending the data: raw and formatting the 14-bit fields into ASCII characters separated by commas. The formatting makes the sampling around 3 times slower (200 Hz or so, rather than 735 Hz), but the limiting factor there was the Arduino's serial transmission rate. By default, the Arduino's serial library can only transmit at 115200 bps. From what I've read on the Arduino forums, an adjustment to the UART divider can get you up to 1 Mbps serial transmission, which should take the raw data transmission time from 1 ms to around 100 us. Adjusting oversampling to just 4x should get the conversion time down to 20 us, which means you're getting averaged samples every 200 us or so, which is equivalent to 5 kHz. To go faster than that, you could reduce oversampling further, speed up SPI (risking data corruption), and switch to a parallel data transmission scheme to get data out of the Arduino faster. In the right circumstances, the AD7607 can sample at 200 ksps, but actually achieving that would take some work.

The other obvious possibility is using something more powerful than the Arduino, like the Rascal. The Rascal's processor is 25 times faster than the Arduino Uno's, and it has an SD card for storage, so the delay incurred by sending the data out the serial port is avoided. When data does need to be transmitted, it has a 100 Mbps Ethernet port.

Next up: the precision voltage shield with a Rascal . . .

There's a Rascal customer (let's call him "Justin") in Arlington, MA, USA, who has been building his young daughter a dollhouse over the last year or so. At some point, Justin decided that he would like to add lights to the dollhouse and control them from his iPad. The Rascal is the perfect tool for the job. He was able to wire the Rascal to a series of MinM smart LEDs and control them immediately with the BlinkM demo on the Rascal. Dealing with wiring the dollhouse with copper tape under the wallpaper has proved challenging, but in any case, it got me thinking about dollhouses.

What are dollhouses for?

People build and play with dollhouses for different reasons. For some, designing and building the dollhouse is the fun part. Some kids don't care about building at all; they just use them as the setting for tea parties or other kinds of imaginative play. "Dollhouses are for burning," says my friend Dan Beyer.

When I was a kid, I had an electric train set. I spent a lot of time flipping through Model Railroader magazine and wishing I had the resources, patience, and skills to build miniature railroad trestles. But most of the time I spent with the train set was actually spent telling stories. I would set up little scenes, usually involving a train, some small men, a helicopter, and a Batmobile (mostly hostage scenarios). Then, I would tell myself a story about how someone had been kidnapped in a helicopter, and now Batman was going to apprehend the villains. The stories never got very far, in part because the helipad wasn't accessible from the roads in the trainset, and the ground clearance on the Batmobile of the 70's didn't allow for offroading. But also, I didn't care about the outcome of the stories; I cared about setting up an exciting scene from them. This is the idea behind the storyhouse: it's a dollhouse with a Rascal embedded in it that kids and parents can use to tell stories.

The storyhouse

With a storyhouse, you sit in a dark room with your kid and tell stories together. On the first level, the iPad lets you control the lights in the house. If you want to get more advanced, you can write stories in the Rascal editor and save them on the Rascal. Like a pop-up book that has a different moving feature on each page, each page of your story can have a different button or knob that controls something in the storyhouse. I'm not sure of the details of how it will work, but the idea is that the storyhouse is a miniature stage for a play that you are directing with your kid.

The dark room gives you a mood of intimacy, where the rest of the world fades away. I spent a few summers as a camp counselor, and I can attest first hand that that if you gather a bunch of kids in a circle and put a candle in the middle, they suddenly drop the fronts they wear all day. Two kids who were telling each other to shut up, no you shut up, all day start listening to each other and talking thoughtfully. I'm hoping that the storyhouse will have the same effect.

The first prototype

The pictures below show the first version of the storyhouse, which is really more of a proof of concept than an actual prototype. Inspired by Justin's dollhouse, I quickly assembled it in the Artisan's Asylum woodshop to see if the idea was worth pursuing. The next prototype will probably have 3 floors, more windows, and more lights, but this was enough to get started. It turns out that the lighting isn't really much fun unless the room is dark. Also, the storyhouse needs internal walls so that the lights have something to bounce off.

Front view of the sketchiest storyhouse prototype

Back view of the storyhouse prototype

What kind of imagining do you want?

To my mind, the kind of unconstrained, imaginative storytelling that works with a storyhouse is totally different than what happens when you play with modern, hyper-realistic toys. Consider the modern "digital dollhouse", a virtual dollhouse app for smartphones that appeared on the New York Times list of "apps to keep children happy". When you look at a virtual dollhouse, you see cartoon illustrations of families going about their business in their homes. You can imagine the characters' personalities and behavior, but the visual elements of the interaction are predetermined by whoever drew the cartoons. You can change the characters' clothes, but all the choices are conventional, like a T-shirt or dress. You can't choose, for example, to dress a character in a sea of bees, a hurricane, or electricity.

If your goal for imaginative play is to keep children happy, or at least shut them up while you drive somewhere, like the New York Times suggests, maybe this kind of imagination-inside-a-prison scenario is what you're after, but it's not what the storyhouse is for. The point of the storyhouse is to be a stage for stories, something that helps get your imagination going. Once it's going, you can take the story wherever you want.

Plans for the future

I'm thinking about how I could bring the first group of storyhouses into existence. There's a Cambridge custom woodworker in the same makerspace as Rascal headquarters who is interested in making some storyhouse prototypes that we would jointly sell as kits. We may have a demo working for the Cambridge Science Festival on April 20, 2013, or on display during the public Battlebots Challenge at Artisan's Asylum on April 21, 2013. If you're interested, drop me an email at brandon at rascalmicro dot com