4 Operating Systems for the Arduino

I was working in the lab, late one night, when my eyes behold an eerie sight... Yes, Halloween is a long time ago, but that stupid song is still stuck in my head. I miss Halloween. I never got to post up pictures of my skeleton running off IXM's. :-)

Anyway, I was browsing the Arduino forums and saw this cool post about DuinOS, a real-time embedded "operating system" for the Arduino.


DuinOS by RobotGroup

It's a simple little realtime OS (RTOS) built by the guys at RobotGroup (hello!), and can be downloaded here. It's meant to have a simple function scheduler, implementing a basic form of multitasking (not quite multithreading, but something like round-robin scheduling I think). That let's someone code multiple functions at a time, that get executed in turn, so that a single Arduino could be executing multiple types of "apps" or "sketches" at the same time.

Well, that's something of a stretch, but it's getting there... we won't get into context switching an RAM page swapping just yet :-)

So then that got me thinking, why not write up the other "OS's" out there for the Arduino platform. So here are the other 3 Arduino operating systems I'm aware of...


Pyxis OS by ArduinoWill

This is a graphical OS built on top of the Arduino and TouchShield platform, and is written by ArduinoWill (aka Thom). Thom is ridiculous, and extremely talented at coding. He has been prototyping some of the craziest stuff I've seen on the MegaPalm kit, DOSonChip, and the TouchShield Slide.

Ok. Here's a video of Pyxis OS in operation, which is quite ridiculous:



ArduinoWill also figured out a crazy hack to implement portrait and landscape mode...



And I'm not even going to mention the Super Mario level port:



Pretty insane... 12 fps. 0x000C. 00000110b frames per second. I'm still trying to figure out how you did this...

ArduinoMacOS by Mark

Mark managed to port a few apps to the Slide, including... um, I don't know... a GPS, Tic Tac Toe, Tetris, a Calculator, Oscilloscope, Breakout, The Matrix Screensaver, and a Canvas Drawing program. And the Control Panel. And Hex editor. And a Graphics Demo. And an analog Pin Visualizer.

And it's all zipped up over at the Open Source App Store here.


I wish I still had screen shots... I've searched my hard drive inside out, but instead, I just have the source code :-( EDIT: I finally found some pictures, and uploaded them above...


TaOS by Ziplock

Here's another lite-weight operating system, this time built by Ziplock. It's a simple embedded GUI that focuses on assigned blocks of code to little squares. In essence, it's the epitome of a miniature, lightweight script execution OS. Applications are like mini-apps.

If every operating system were written with this little overheard, I'd be running Quake on an 8 bit Motorola 6800 written in assembler...

Anyway, I digress, but the code for TaOS is all available over here.

What's The Best Instant Coffee for Hacking?

Chris and I just spent the last couple weeks completely strung out coding and hacking the IDE. There were a number of problems, but they all stemmed from two simple issues that could be summed up in one word: "suck".

1) Apple deciding to modify the binary java application launcher in preparation for 64 bit java compatibility (which broke the Aardvark IDE), and

2) Windows 7 sucking. Billy G. locked down certain folders, changing the way programs have to deal with temp files (which also broke the Aardvark IDE)

Anyway, Chris wrote a blog about how we solved the issues technically speaking. But this is a differenty kind of blog. This is the one that describes how we solved it biochemically speaking. With coffee, of course.

We drank a lot of coffee, especially late at night, and when Starbucks or the local joints are usually way past closed. So I figured it was a great excuse to do some double-blind taste tests of the various instant coffees I could find at the grocery stores around me.

Here are the five types we taste tested, from left to right, Maxwell house, Medaglia D'oro, Starbucks Bold Via, Starbucks Columbian Via, and Mount Hagen. You pretty much have to live in a bubble not to have seen all the advertisements for Starbucks Vias recently, so this was also Chris and my attempt to cut through all the marketing B.S. out there...


Naturally, we took out a piece of paper to document the experiment:


The Via's needed scissors to open, which sucks. Everything else was easy to use, but needed a spoon, which is a more readily available "kitchen" tool as far as I'm concerned. On the other hand, the lab space always has scissors lying around, so I guess it all depends on where you fix your coffee.


Here's a close-up of the different looks of the instant coffee. Mount Hagen sort of looked like bacon bits, and perhaps as a result, looked the most appetizing. Medaglia was sandier, while the others were more like little piles of dirt.


Here's the full get-up. I followed the recipe marked on the label in every case, down to the amount of grinds, and water.


Here's me pouring out the microwaved water into one of the cups:


And this is what all the glasses look like when they're filled:


And after I stirred each glass:

One thing to note is that the Mount Hagen is the only one with foamy bubbles at the top. This is weird. It would have been fine if I'd put milk in there, and stirred it up. But I didn't. It just somehow likes to keep its foam. For some reason, this foam stayed there the whole time. Not good, not bad, just different.

To clear our pallates in between sampling, we used Diet Coke. Why? Because it's another liquid that commonly makes it's way around the lab, and is often the chaser Chris and I use when drinking coffee. There's something satisfying about drinking a hot cup of coffee, then a cold glass of diet coke, then another hot cup of coffee, then about cold glass of diet coke.

Hi, my name is Matt, and I have a caffeine problem.


While we drank, we kept notes on the first imrepssions, tools needed, time to prep, amount of water needed, smell test, taste test, and even what each type tasted like after waiting a while. The rationale went like this: a lot of times, I make a couple cups of coffee at a time, pour them out, and bring them from the kitchen into the lab. Inevitably, one of the glasses gets cold. Drinking cold coffee is a fact of life in a lab :)

Finally, we ranked each of the 5 in terms of total experience, and provided summary notes.


I even typed it up:


The bottom line

If you can get over the weird foaminess, the Mount Hagen is the best tasting coffee, hands down. The Italian Roast Bold Via is the next best taste, but you have to drink it all quickly, because it starts to taste a little stale after sitting around. The Columbian Via holds its flavor better, but that's because that flavor is bland. Maxwell House has a chemical, synthetic taste in my opinion, kind of like that smell you get when you drive on I-95 through New Jersey, and you drive past that big chemical refinery and the air smells like pancakes which is normally good but you start holding your breath because you know it's not really pancakes, it's actually acetyln glycol esther mercury fumes. Medaglia D'oro was 3 European ounces of just plain horrible - they had me at the smell - which is tart and sour and nasty and frankly has no business belonging in any cup I'm drinking.

So in conclusion:

1. Best - Mount Hagen if you can live with the weird foam
2. Runner up - Italian Roast Via
3. So so - Columbian Via
4. Eh - Maxwell House
5. Get out - Medaglia D'oro

Aardvark 0.8.36 Released

This is the next installment of the Aardvark 0.8.x series. Notable new features include:

• New Library menu that's board friendly
• New Library reference docs
• Larger reference panel
• The library example list auto repopulates when the board changes.
• Added JeeNodes library (Ports, RF12)
• Arduino Duemillanove upload bug fixed, thanks Fred!
• Misc startup fixes
  

Download @ Illuminatolabs

I've added a Library Menu that dynamically changes with each different board. Here, we see the standard libraries for the Arduino family of boards:



I've also included new reference docs for the Libraries, which load up a library is pulled into the sketch. Below, we see a quick reference for the AFSoftSerial library:



Tip: A quick way to show the reference panel is to click Help->Reference.

Thanks for all the code contributions that made this all come together.

New Haven Maker Meetup, Christmas Edition

I’ve been getting a lot of emails about the next New Haven Maker Meetup, so it must be about that time again.

The Eli Whitney will be hosting the second Maker Meetup in the first week of December, so Christmas themes are welcome, though Thanksgiving projects are certainly interesting too. Actually, I wouldn’t mind seeing some neat Halloween costumes or setups either, but that’s just me. 

What: New Haven Maker Meetup, Christmas Edition
When: Tuesday, December 1, 7:30 pm - 9:30 pm

Where:
Eli Whitney Museum (directions)
915 Whitney Avenue
Hamden, CT 06517
(203) 777-1833

How Much: Free
RSVP (preferred): kl@eliwhitney.org

Here’s a couple projects Mike, Chris and Matt did for the holidays last year that might make another appearance:

The 8-bit embedded TurkeyShield

This year, maybe a 32-bit embedded turkey with the IXM?

Mike’s Christmas Tree Upgrade

And it’s always fun to make lights blink in cool new ways :-)

Give me a shout if you’d like me to send a reminder email, or if there’s a project Mike and I should bring to this meetup – jhuynh at gmail. Hope to see you there!

Updates to the Antipasto Arduino IDE: Frickin's, Fixes, and Features

Matt mentioned a few of the issues with Apple and Java, so I thought it might be helpful to add a little technical detail on what's happening and why. The fixes are all part of the latest Antipasto Arduino IDE I uploaded last night, which can be downloaded here.

And given the situation, I chose to express myself through a series of F-words: Frickin's, Fixes, and Features.

Frickin's 1: Apple Breaks Java

Here's the bad news from Apple that was posted to a mailing list regarding Jan's broken Java app:

On Jun 16, 2009, at 7:23 AM, Jan Andersson wrote:

After the latest upgrade starting several of my Java-based applications fails
(when I have changed the plist to say 1.6+). This includes IntelliJ, Install4J
and DbVisualizer.

This is part of a change to the double-clickable app launching policy (which we explained in detail in the developer preview release notes). To enabled the Finder's "Run in 32-bit mode" checkbox for Java apps, and to make the transition to 64-bit by default easier, we've modified the JavaApplicationLauncher.framework to only launch application's in the architectures they have present in their JavaApplicationStub.

The thinking is that if you haven't rebundled, you likely haven't ever considered that you'd be run in 64-bit mode (and when users have dragged Java SE 6 to the top of their Java Preferences, they found that some of their applications stopped working). By preventing apps from being launched in 64-bit if they haven't rebundled, we can maintain the widest compatibility, with a minor impact on developers (and actually let them have a say in what their version and architecture requirements are).

Hope this explains what you are seeing,
Mike Swingler
Java Runtime Engineer
Apple Inc.

Apple Translation:
We don't care if we break all the Java applications out there...that's your problem, not ours.

So in response to this, Matt and I (and a few others - thanks esp. to Nick!) worked really hard to re-bundle the Arduino IDE as a 64-bit bit native. You're probably asking, why not just check the box in the Get Info window to run in 32-bit mode? Well, that was my first thought too, but the check box mysteriously disappeared, so that wasn't an option any more. Dang.

In any case, that means we needed to ensure everything is 64-bit compatible, including all the contributed libraries the IDE heavily depends on. Especially the infamous librxtxSerial library that provides serial connectivity to the boards. So when everything came together, I recompiled everything for 64-bit.

Fixes: Now the Arduino IDE runs on Mac OS X with Java 1.6+, as a 64-bit native application.


Frickin's 2: Apple PackageMaker Relocation Bugs

Aside from the Java issue, have you ever installed an application on your system and the .app file mysteriously disappears? If you have, like me, you've probably been the victim of a bug with Apple's PackageMaker utility that comes standard in OS X.

As it turns out, when building an installer package inside of a relative directory, like the Arduino IDE needs to, PackageMaker thinks I'm trying to relocate the installed Application on the target computer to a random directory. Installation result due to this bug: A full Arduino IDE installation with a missing Arduino.app file. Not a pleasant surprise.

The fix is more of a hack, and it's to scan for and manually strip out any XML in the packager maker build files that point to obscure package relocation settings.

Fixes: Now the Arduino IDE should always have an Arduino.app file in the Applications/Arduino directory.


Features: TouchShield Core Consolidation

A positive outcome of the getting back into IDE development was updates to the TouchShield core. The biggest thing is that the Stealth and Slide libraries have now been consolidated into a single core. This allows for easier code maintenance and allows for contributed libraries to run on both boards. As it turns out, this is the only thing I can indirectly thank Apple for breaking Java for.

Features: Reference Panel Added

I like to be able to browse reference docs, even when I don't have an internet connection. To see it, click Help Menu->Reference.

Features: Libraries and Reference Docs are now Core-Specific

Thanks to Andrew for suggesting this one. He was creating graphics libraries for Slide, which don't run on the Arduino. With this update, core-specific libraries like those can be dropped into to the following directory: hardware/cores/*/src/components/library

Each core also has its own reference html docs. These show up in the right-hand reference panel (see above). The reference html docs for each core exist in the following directory: hardware/cores/*/reference

Features: Compile and Upload is Now Non-blocking

Greg asked about making edits to my sketches while uploading or compiling, so now the IDE allows that to happen.

This is just a start, and hopefully it tackles a few of the issues that I've been getting emails about. I've put the IDE up here. Feel free to give it a spin and let me know if there's anything else I should take care of, or if you've got a chunk of code to include as well.

A very bad week for Open Source Hardware

This has been a very bad week for Open Source Hardware. First Sparkfun gets served up by Sun for sounding like SPARC processors. Guess what? No one in the WORLD would ever have made that connection. NO ONE except a set of trigger-happy lawyers whose sole goal is to increase the percentage of GDP in the US dedicated to legal transaction costs. Then, the Creative Commons tells GOSH to buzz off because they don’t want to help make an Open Source Hardware-specific license, instead they basically said, “hey guys, go learn about patents.” And now, Apple’s 64 bit update java dev team conveniently decided it was time to refactor the library base for 64 bit, leaving anyone who had coded an app for 32 bit hanging in the dark.

Basically, Apple just announced to any Open Source 32 bit coder like me and Chris: “Get lost!”

I have just spent 35 hours that I will never get back. Chris and I have been killing ourselves trying to understand what Apple has done to their installation of Java, and why it suddenly broke Antipasto Arduino IDE.

Apple is migrating to 64 bit hardware, and they don’t want to look back. I guess I don’t blame them. Apparently, that means anyone with a 32 bit application out there that relies on hardware API service calls, you’re left hanging. I guess Apple learned from their transition from 68k to PowerPC that backwards compatibility really doesn’t mean anything, because community developer’s time is free and cheap and no one cares about the community. I’m one of those community developers, and apparently Apple doesn’t care about my time… they’re ok to just say, “whatever, your fault, just recode your entire application for 64 bit Java if you want anyone to care.”

I guess it’s easier to tell the community “go build an app for that and get out of my face.”

Well, to whomever is responsible for making this decision, I HATE YOU.

Here’s what happened so far:

-Apple decides at some point that 64 bit java support is all they need

-Apple released version 1.6.0_15 of Java, switching everything around for 64 bit, rather than 32 bits http://news.techworld.com/security/3201055/apple-patches-critical-java-bugs/

-Antipasto Arduino IDE’s use serial libraries and serial drivers to control the FTDI comm. link, which is more stable in 32 bit land

-Apple doesn’t care, so they rearranged the lib tree structure and object files, and decided they’d let us developers figure it out for ourselves. A couple other people have noticed http://lists.apple.com/archives/java-dev/2009/Aug/msg00115.html

http://www.chemaxon.com/forum/ftopic5319.html

http://forums.java.net/jive/thread.jspa?messageID=366935

http://forums.sun.com/thread.jspa?threadID=5405279

-On October 21^st, http://twitter.com/LiquidWare madaerodog was the first to notice it was broken, and twittered all about it

-Chris and I started reverse engineering the problem once we figured out what java version he and I were running and why it worked on one and not the other

-Chris and I (and Nick) just pulled a 35 hour coding and debugging marathon trying to recompile all of the serial dependencies for the 64 bit java 1.6.0_15

Hey Apple! Next time you decide to refactor your platform-specific installation of Java in an effort to not support backwards compatibility, here’s a tip:

Don’t.

This is not going to be an overnight fix… but Chris posted up the most recent update to the Antipasto Arduino IDE. If you want to help, and you have a Mac, maybe you can try this version out, and let me know if it works - inthebitz at gmail…

What would Richard Stallman do?

It’s been a while since I talked about open source theory, but it comes up now and again because it’s pretty much a part of everything I’ve been working on lately. There’s been the open source Illuminato X Machina project (schematics, gerbers and software here), the Open Source Hardware Bank (and the Open Source Hardware that was produced as a result). But before I wax philosophic (perhaps something for later this week), I decided to try applying open source to a current problem.

Folks have been picking up the Portable Megapalm for one reason or another, where a touchscreen and buttonpad come in handy. But John and Glenn made an excellent point – why not have some handheld/mobile computing type software running on it? Maybe even some form of Linux? In any case, this could really go one step closer towards a truly customizable, open source, handheld/mobile computing device.

Then Matt and I looked at each other and asked “WWRSD?”, or “What would Richard Stallman do?” The phrase works just as well with Linus Torvalds, or your favorite open source hero :-)

Well, the conventional, closed-source solution would be to spend $1000’s (if not more) paying for full-time coders to develop proprietary software for such a project.

The open source solution would be to turn it around to a community of talented coders, passionate about driving their own projects and bringing open source devices one notch up versus closed source alternatives.

Nevertheless, Richard Stallman might mention something about the open source battle cry “free as in speech, not as in beer”. The classical gratis vs. libre distinction suggests that everyone is free to modify, reuse and contribute – but this does not necessarily equate to zero-cost. In the case of software with little marginal cost, however, open source has tended to mean both gratis and libre.

Despite the fact that many coders on open source project spend time on a project out of personal interest in a cause, it doesn’t mean that they couldn’t use some extra pocket cash.

It’s not the first time that someone is offering a little bit of money to help light the spark for an open source software project, though. My beloved New York City just launched an initiative called NYC BigApps, seeking software developers to create the best applications to analyze NYC’s open data sets and help improve the system, offering a $20K prize and a dinner with the Mayor.

Github launched something similar to improve its functionality. They offered up a nice ~$70 bottle of liquor in a friendly competition to solve a problem and get some new ideas and recommendations.

So I talked to Stephen, a staunch supporter of OS, and asked him what he thought of the situation. He said that he’d even redirect his I-bills towards getting some functional software written on the Slide and Portable Megapalm, on the condition that it was written collaboratively, and in an open source fashion.

Here’s what he was thinking in terms of stuff for the Portable Megapalm, all of which is open to thoughts and comments:

$1000 in funds towards folks who could develop a PDF reader
$500 in funds towards those who can get a quick JPG viewer up
$500 in funds towards functionality, features, or projects that the community votes on and is interested in seeing

Of course, it’s open source and collaborative, and shouldn’t be a hardcore competition! Hence I say “funds”, as it will be distributed across the top 5 or so contributors to each project.

What do you think? If you’re interested, or have an idea on how it could be better structured, feel free to send me a note or comment: jhuynh at gmail

On Friday, I’ll wrap up a few of the feedback that I get and kick it off next week. Looking forward to it!

New Haven Maker Meetup Recap

Thanks to the makers and hackers that came out to the Eli Whitney Museum last week for the inaugural New Haven Maker Meetup. There turned out to be quite a variety of projects and discussion, which is always a great source of inspiration.

Growing up in New York (and not CT), I didn’t have a chance to experience the Eli Whitney Museum as a child, so I was in for a real treat. The museum serves as a workshop for all sorts of hands-on projects, in addition to having a lot of neat historic relics. All-in-all, a great place to spend some time.

Museum Director Bill Brown kicked off the evening with a brief history the museum and the art of “making” as it existed in a different age. While the materials, medium and projects may be different, the ingenuity, curiosity, and pure interest in tinkering is timeless.

Bill ended his talk by making a favorite project of his own, on the spot: the rubber band powered car, and setting it off to the races! A shaky, full motion shot, was only fitting :-)

Here’s what they usually look like fully finished and decorated:
We had a few neat demonstrations from Alex, Mike, and Rob. Alex brought in and talked about his crackerbox amp, which he built from parts that he salvaged from an old TV!

Mike talked a little about his experience tinkering and building the boards over in the Liquidware shop, and Rob (below) gave a demo of the Drawdio project (as well as a box full of other projects!).


Then we all split up into a mingling/project show-and-tell session, which is part of what makes meetups so much fun, and is usually where I get a lot of ideas for new stuff to work on.

And I just thought this one was really cool to see live - the RC Carduino that Raj set up on his own server:

All good, fun stuff, and a great excuse to hang out with other makers! If you’re in the area and want to be a part of the next one (tentatively for November 11), let me know and I’ll be sure to send you a reminder when it gets closer – jhuynh at gmail

Computational Structures

I just got my letter confirming my invitation to the LACSS Conference at Los Alamos National Labs!


Their hypercube logo reminded me of my Illuminato X Machina representation of what could be considered for a 4-way mesh topology.

The physical connection in my cube is made by bending a few intercellular matrix headers at right angles.



I'm testing Matt's gradient stealer sketch, which is running on each Illuminato X Machina cell, looking speedups due to the cube architecture.

In this 3D mesh configuration, the network architecture allows more nodes to communicate simultaneously, and with shorter hops back to the source, which was my PC.

Up next: Performance speedups by using Oracle bits, and exhibiting quantum acceleration of non-quantum computing, by jumping the mesh.

Digital Venus Flytrap on my TouchShield Slide

When I was at the Maker Faire in Providence, Justin remembered that Matt had a Venus flytrap with him that he was going to do some sort of project with. Way back at the end of May, at the Maker Faire in San Mateo, Matt had picked up a Venus flytrap on the way to the airport. It's the little plastic canister right next to his laptop bag.

Here it was on their Maker Faire table getting some air time.

The whole reason was so Matt could snap a bunch of hi-speed images of the flytrap in action. But somehow in the hustle and bustle of the Faire, that never happened. I'm not sure what ever happened to that Venus flytrap, but I thought it might be a fun little app, so I put one together.

The artificial, hack way, I did this (since that's really the only way I do anything :-) was to search Youtube and take some screenshots. I searched for "Venus flytrap closing" and just looked for a video that seemed right.

For screenshots, I like to use zscreen, which is free and open source, and I had to crop some of them using GIMP, but it was pretty simple. I took only 4 shots, and these are by no means the hi-speed shots that Matt was going to take. But I'd just sample more if I wanted the transition to look a little smoother.

I saved these shots as bitmaps, which I then uploaded to the EEPROM on my TouchShield Slide:

When I touch the Slide, the flytrap closes...

Short and sweet, and the project finally comes full circle four months later. I uploaded the code over on the App Store here, in gadget format for the Antipasto IDE.

Here's a video of me (safely) poking my Slide Flytrap with my "stylus"...as a disclaimer, I wouldn't recommend poking a real one!

The Illuminato X Machina on Linux: Up & Running

Last Saturday Chris and I got the Illuminato X Machina IDE (pre-build binaries here, source code here) working on Gentoo Linux. Most users can just install the IDE and start hacking, but if you don't see a device in the IDE menu and your terminal board is powered up, here are some detailed instructions for setting up Linux properly.

Kernel Modules & Devices

The IXM Red Terminal Programmer is a usb-serial device. On my 2.6.28 kernel, the programmer will show up at /dev/ttyUSB0 (or 1, 2, etc.). This device is provided by the usbserial driver in the kernel. You can check for the module easily:

$ sudo modprobe -l|grep -i usb\/serial
/lib/modules/2.6.28-tuxonice-r10/kernel/drivers/usb/serial/usbserial.ko
/lib/modules/2.6.28-tuxonice-r10/kernel/drivers/usb/serial/ftdi_sio.ko
$

Your distro may have the module built into the kernel instead (that's why you should just try the IDE first). If you need to build the module, you can configure your kernel as follows:

• Check off: Device Drivers > USB Support
• As module: Device Drivers > USB Support > USB Serial Converter support
• Check off: Device Drivers > USB Support > USB Serial Converter support > USB Generic Serial Driver
• As module: Device Drivers > USB Support > USB Serial Converter support > USB FTDI Single Port Serial Driver

After building the module, simply sudo modprobe ftdi_sio. You can check to see if the module is loaded with sudo lsmod. Modern Linux distros use udev, which means the device node should be created when you plug a terminal board in. If not you can look at the kernel documentation for usbserial for more information about device nodes.

That's it!

Embedded Systems Confrence Boston

This year I was lucky enough to sneak out to the Embedded Systems Conference at the Hynes Convention Center in Boston!

This was my first time going to a big event like this with so many embedded systems engineers.

After I got my badge, I saw a great presentation by Robert Brunner from Ammunition to start out my day!

Then I headed to the Exhibit Hall where lots people were showing off their stuff.After that I learned a little about Windows Embedded... they seem to be focusing a lot on a distributed cloud architecture.

I finally got a chance to talk to real NXP team members (from my experience, they are imposable to reach via phone unless you are buying infinity processors). The NXP team knew their products, and were very helpful... they even gave me a free development stick!After that, I headed back to the Exhibit Hall to finish what i started.
I grabbed a quick lunch and went to hang out with the guys from Texas Instruments, and they put on a fascinating demo of their Beagle Board, and how they hacked Ant and Make files to get a Linux kernel running on the board.
The day ended for me with a discussion on power optimization for embedded system operating systems...

Can't wait till ESC Boston 2010!