MrSolidSnake745 tweeted out this great Final Fantasy VI theme song tribute synthesized using floppy disk drives controlled by a Maple board.

The code used seems to be SammyIAm's Moppy, which runs just fine on Arduinos. There's a whole scene of stepper motor and floppy drive audio projects out there, like that of our friends Open Music Labs (videos, write up), but we think this particular track came out really well!

Bagging up distributor shipments at Industry Lab

After a couple logistical hiccups, we finally shipped out fresh Maple boards to distributors, and a batch of Maple Minis are expected to go out next week. All distributors have been out of stock for many weeks now, and we want to make it clear that the blame lies with us, not our manufacturing and distribution partners. Sorry about that!

You might wonder just where our boards are actually manufactured; I certainly did! During a personal trip to China this past January I was able to visit Shenzhen and Seeedstudio, the company that has handled sourcing, PCB fabrication, assembly, and testing for the Maple product line for the past several years.

It's impressive how much Seeed has grown in the past few years. They have a small army of young engineers and designers prototyping new devices, and multiple lines for prototyping, testing, and assembly. I liked the space they are working in now: an entire floor of a large industrial building. Not very sexy, but solid, well lit, and with plenty of room for projects, heavy equipment, and toys. Compared to the shiny, expensive, and heavily marketed "incubator hubs" and "innovation centers" in Silicon Valley or Cambridge's Kendall Square, I think this type of older building is much more valuable resource for growing companies who need space of their own to grow and experiment.

Bryan and Eric Pan at the Seeed offices; even in January I worked up a sweat walking around the city

Small batch assembly line at the main offices; runs of more than a few hundred units go to a seperate facility nearby

Violet showing me around the stock room; a bank of pogo-pin board testers

Electronics work bench

Testing and Soldering boards

Of course "no trip would be complete" without a visit to the famous electronics markets...

Turns out that the Maple Mini bootloader binary linked to from our bootloader documentation was nonfunctional. It's unclear how that happened, but we've uploaded a fresh bootloader binary which is known to work. Sorry about that!

Cryptic vending-machine-as-library in Shenzhen, CN

We have switched to a new website backend, using Pelican to statically generate HTML files. As noted last week, we don't have a mechanism for direct comments on posts right here any more, so please discuss this post (and future ones) in the forums here! There was not a direct way to keep old comments attached to their pages, but they have been archived and are accessible via a link at the bottom of every blog post.

If you subscribe to our RSS feed, the URL should not have changed, but slight changes in XML syntax may mean you get spammed by a re-listing of all our old posts. Sorry in advance!

I did my best to re-point image references and preserve old post URLs; if anything breaks please drop us a line.

So it would appear that LeafLabs has done a pretty bad job the past few months of keeping everyone in the loop, and for that we definitely apologize. So here’s a status report, and a look at what’s in the pipeline.

First off, we want to say that Maple and Maple Mini will be available for the foreseeable future. There is no intention of discontinuing either product line; we plan to keep making and selling them as long as people are interested in buying. So don’t panic! If you’ve got a Maple-based project (or were planning one), you should be able to get your hands on new boards as you need them.

The bad news is that there are no concrete plans to expand our hobby line at the current time. Unfortunately, at the moment it’s just not financially viable. We hope this will change in the near future! We’ve been exploring some industry partnerships, and there’s also hope that some of the other projects we’ve been working on (outside the hobby-hardware space) will become lucrative enough to fund expansion of Maple and related products. But nothing has solidified yet. We will try to keep you updated as things develop.

Despite this, we do plan on continuing to maintain Maple, that is, fixing bugs, accepting patches, responding to questions, and keeping you all abreast of awesome new Maple-related projects. This hasn’t been going so well recently, and for that we apologize. But we’re going to do better! We’ve got lots of plans for how to do that, not the least of which includes bringing Bryan Newbold (bnewbold from the forums) back on board to help out. So keep your eyes peeled for a blog post with more details in the very near future.

In the meantime, thanks for sticking with us.

Recently, we've been playing around with ways to get libmaple to compile faster. We've been able to get good results (0.1 seconds for a full build); this post summarizes them. Results were obtained with the UNIX toolchain, but it might be interesting to try to port them over to the IDE. All timing results are for building blinky.cpp on today's libmaple master (0cc911c) using a quad-core hyper-threaded CPU (an Intel i7-3770 at 3.4 GHz).

TLDR:

1. Use make's -j flag to parallelize the build
2. Use ccache to save old build files

Building with make -jN allows N separate jobs (e.g. compilations) to proceed at the same time. The "right" value of N depends on the computer you're using to build libmaple; we usually use the common heuristic N = number of cores.

Without -j:

$ time make
[...]
real    0m3.570s
user    0m2.664s
sys 0m0.400s

That's 3.570 seconds of wall clock time. With -j8:

$ time make -j8
[...]
real    0m0.825s
user    0m3.788s
sys 0m0.476s

0.825 seconds, or a little more than a 4x speedup. (make -j4 usually results in ~1 second builds; increasing N beyond 8 seems to have little effect.)

Use ccache to cache old build files: We recommend this in general, but it really shines if you use more than one kind of Maple board (regular Maple, Maple Mini, etc.) or have to make clean a lot for some other reason.

ccache is a compiler cache. It saves the results of old compilations, letting you reuse them even if you've deleted the versions in the libmaple build directory. Since you have to run make clean before rebuilding libmaple when switching boards, having a cache of libmaple's object files for the other board saves time when you switch back.

Results using ccache with an empty cache:

$ time make
[...]
real    0m4.489s
user    0m3.056s
sys 0m0.488s

Running it multiple times, it seems that this number (~4.5 seconds) is typical. Note that that's a little under a second more than building libmaple without ccache. The extra time is presumably spent warming up the cache.

The results when rebuilding libmaple with a warm cache are pretty impressive:

$ make clean; time make
real    0m0.352s
user    0m0.064s
sys 0m0.040s

That's more than a 10x speedup over rebuilding libmaple without ccache.

If you'd like to try this for yourself, you can use the following libmaple patch:

$ diff --git a/support/make/build-rules.mk b/support/make/build-rules.mk
index 3d541ba..1a2abbb 100644
--- a/support/make/build-rules.mk
+++ b/support/make/build-rules.mk
@@ -1,9 +1,9 @@
# Useful tools
-CC       := arm-none-eabi-gcc
-CXX      := arm-none-eabi-g++
+CC       := ccache arm-none-eabi-gcc
+CXX      := ccache arm-none-eabi-g++
LD       := arm-none-eabi-ld -v
AR       := arm-none-eabi-ar
-AS       := arm-none-eabi-gcc
+AS       := ccache arm-none-eabi-gcc
OBJCOPY  := arm-none-eabi-objcopy
DISAS    := arm-none-eabi-objdump
OBJDUMP  := arm-none-eabi-objdump

(Save the patch to a file, then run $ git apply the-file-name from within libmaple).

Parting shot: the combination of the two (make -j8 plus warm cache):

$ make clean; time make -j8
[...]
real    0m0.132s
user    0m0.064s
sys 0m0.020s

About a 27x speedup over  plain make. Which is awesome, but note that it's less than the product of the speedups of using -j8 (4x) and ccache (10x). Presumably the fixed overhead is non-parallelizable, non-cacheable build tasks like the final link.