the state of the maple tree
Hi everyone! As you can probably tell from Okie’s awesome picture in the post below, we got back the prototypes for Maple Rev2 about a week ago. You may recall that the revisions were to fix two issues. The first is that the I/O has been relabeled in a format we think makes more sense for use with the STM32 – the pins are no longer divided into analog and digital banks, although we’ve made sure the pins in those locations have those capabilities to maintain Arduino compatibility. Maple pins are now numbered from 0 to 43 have have labels on each pin indicating its capabilities (don’t worry, the library will still support the numbering scheme from Rev1) like PWM, AIN for analog input, TX1, RX1 for Serial1 port (there are 3 total), and the pins in all the SPI and I2C buses.
The second issue to fix in this revision was slightly more serious. We had encountered a pretty significant voltage swing on VCC – a sawtooth that was up to 1.5 V peak-to-peak, with no code running on the chip, depending on the power source used. The digital I/O worked fine even with the variation, but we shipped the Rev1 boards with a 10 uF through-hole bypass cap that was intended to knock out the swing for those of you working on analog projects. Rev2 incorporated an extra 10 uF bypass into the design.
We got the boards back and the extra bypass seemed to do a pretty impressive job of knocking out the swing, dropping it down to baseline max 70 mV versus the aforementioned 1.5 V.* Still, it’s just not quite as good as we would like. We’re still seeing spikes on VCC of up to 300 mV when pulling on some of the peripherals (especially USB). And the twelve-bit ADCs, which we’ve all been really excited about using, are losing up to six bits of resolution with some combinations of peripherals turned on. (If you’re interested in seeing the results of all the tests we did, check them out here: [link to separate page with test results])
This isn’t totally unexpected — several of the other STM32 dev boards we tested are similarly noisy. Even so, we’re really just not satisfied with these results, and after a lot of experimenting and deliberation, we realized we really just couldn’t get the clean signals with a two layer board. Because of this, we’ve decided to switch to a four layer board. The next revision of Maple will have dedicated ground and power planes, which should (we hope!) solve all of our noise problems.
Of course (bet you saw this coming, didn’t you?), what this means for you is that the next revision of Maples will be shipping out about one to two weeks later than we hoped for. This means, ultra best case scenario, the new Maples will be shipping around March 10, and ultra worst case scenario, around December 2040, considering what good luck we had with production last time. Okay, just kidding – medium worst case scenario would probably be sometime around March 31.
Okie has been working tirelessly on the new four layer design, and it is nearly finished, so we should have prototypes back within a week. Once those are back and tested, we will be sending them to production, and at that time (probably around February 23) we will once again be taking pre-orders!
We’ve been getting a lot of really wonderful feedback on the Rev1 boards, and a lot of interest in Rev2. For those of you who have been waiting for a Rev2, we really are truly sorry for the added delay and inconvenience. We just hope you guys are willing to stick with us a little longer, and that you understand our desire to avoid sending out a product that’s not 100% as sweet as it could be. Thanks for being so awesome, everyone.
TL;DR: Maple is switching to a four layer board to solve some lingering noise issues, and so will be one or two weeks behind schedule – we’re really sorry for the delay!
*OK, that isn’t 100% true. I mean, it is, but that’s not what happened right away. Here’s the entire sordid story for the interested, edited out above for clarity’s sake: we got the boards back and were STILL seeing, baseline with no code on the board, a sawtooth of about 300 mV, despite the bypass.
We were like WTF? So we did a ridiculous amount of tests, and at some point we dumped ANOTHER bypass on the header (a la our impromptu fix for Rev1), and it was fixed. Again we were like WTF? So after lots of digging we eventually realized that the voltage regulator we’re using expected a bypass with a certain equivalent series resistance. The bypass we’d added to the design was ceramic – very little ESR. The one we’d been putting in the header was aluminum electrolytic – plenty of ESR. OH. So we replaced the ceramic one with an electrolytic one and voila, the results detailed above.
We share this story with you just in case you ever come across a similar problem and are like WTF?, you might learn from our travails.
A good story to come… Great things have been brewing. Show us what you’ve been cooking!
Maple on Mac OS X!
With revision 115, the maple IDE works on OS X 10.5, provided you use an external power source (due to the dfu problems mentioned above. To build it, make sure you have developer tools installed. There is an external dependency on two GNU libraries, gmp and mpfr. These can be obtained through macports.
First, go to http://www.macports.org/ and follow the installation instructions. Then open a terminal and type
sudo port install mpfr
This should install libgmp and libmpfr. Next, check out the code repository at http://code.google.com/p/leaflabs
open up a terminal, change to the directory
leaflabs/trunk/maple/build/macosx
and then run appbuild.sh
this will create the application for you and place it into the work directory ready for use.
To flash code, first set the board to maple, and make sure your maple is powered externally or via battery. The first time you try to flash, things will hang up at “Claiming USB DFU Interface…”. When this happens, unplug the usb cable and plug it back in. When you next click upload, everything should work. Ive got mine sitting here blinking right now.
Additionally, the serial monitor works under mac. It should set itself up automatically, but if not, once your code is running go to the tools->serial port menu and select something like “/dev/tty.usbmodem411″.
Hope this works for you all. A pre-built app should be available on the website shortly.
Unfortunately, it seems that there are problems getting libmpfr to play nicely with Snow Leopard (OS X 10.6). We’re currently looking into this, and will let you know when we have a fix.
Blinky!!
Happy Holidays Everyone!
We have gotten reports that Maple’s are being delivered and several users have
successfully gotten Blinky style programs running from the IDE. This is great
news! Here is a short update.
We are currently working on a getting started guide, detailing how to
build/install the IDE and use it to program Maple. This being the Holiday
weekend, the timing could have been better, but we hope to have this tutorial
up late Tuesday evening. After a bit of turbulence with a broken repository, we
have migrated the latest changes to the library into the IDE and it builds
successfully on linux and windows. Unfortunately, there remains an issue on mac
OSX involving dfu-util, the program used to load new firmware onto the STM32.
Support for using Serial.print() to write to the UART ports is complete, however
this function does not mirror the data to the USB port (which acts as a virtual
serial port on the host machine). This functionality exists, but hasn’t been
integrated into the library yet.
We are working to integrate the various dependencies of the IDE into simple
installers on windows and linux, hopefully this will be completed in the next
few days. For now, however, the IDE can be built manually from the repository
at leaflabs.googlecode.com, following the standard instructions on arduino.cc
(for building the IDE). In addition, the IDE depends on dfu-util, which can be
obtained through most package repositories for linux or from openmoko.org.
Thank you for your patience and support, we hope you enjoy getting started with
your new Maple. Please do check on the website later this week for further
updates about installers and the getting started guide. We look forward to your feedback!
Maples Shipped!
Hey all–
Maples are in the mail; hopefully they will arrive this weekend for you residents of America out there, and some time next week for the international folks. Our software will be up within the next few days, just in time to get started hacking on your boards.
Our very own Jewish Santa, shipping Maples to all the good boys and girls.
So thanks for bearing with us, and Merry Christmas, Happy Hanukkah, Killer Kwanzaa, and A yuley Yule to all of you.
The First Two
We’ll hopefully be shipping the pre-orders the end of next week.
Maple before assembly
Here’s a picture of some Maple boards a couple days ago before assembly. Oh my gosh I’m so excited too!
Evidence that at least one component has been placed on one board:
FINALLY some assembly!
In the middle of October we shipped the Maple components off to Gold Pheonix for assembly. It was an exciting day and we could hardly wait the two weeks to see the finished product. As we tracked our package across the world our excitement turned to panic. The components spent a few stagnant days in customs – I naively called this “customs glitch.” Days turned to weeks, our 15 day turnaround went from a plan to a fantasy to an impossibility. However, I am pleased to copy below the update i posted on the home page:
After a VERY long stint in customs, Gold Pheonix has FINALLY received the components for assembly [sometime between friday afternoon and monday morning]. We expect a one week turn around on this. We had originally allocated 15 days lead time for manufacturing our first run of 100 Maples – due to bureaucratic overhead and some naivete on our part, 15 days proved to be a massive underestimate. However, were are pleased to learn that the first run of Maple’s are currently under the pick and place being assembled!. We offer our sincerest apologies for the delay. To those who have contacted us directly about this issue, thanks for your understanding and support!
In: Uncategorized · Tagged with: maple
Yeah, Yeah, its coming…
Silly customs glitched our release timing going on 9 days now! ugh! We’ve been using the extra days to polish up the arduino-port. The principle hiccups have been portability on mac/linux/windows. We usually play in linux, so thats the trivial build. However, Maple depends on dfu-util (from openMoko) and arm-eabi-gcc (codesourcery) and getting these to play nice on the other platforms has been headache. Fear not, all will be righted in the coming days. Were sorry for the delay, the second we’ve got a base application for you to play with were going to open it up to the open source community to hack on. For now, its just a smash-up of arduino and our stm32 build environment, but we hope that together we can make it oh so much more!
Obligatory Screenshot:
What’s the deal with pre-ordering?
Some of you may have noticed that there has been a store page flickering on and off on our blog. Yes, it’s pre-order season.
We had a few kinks left with paypal, but they should be straightened and now you can pre-order your very own Maple! But why, you may ask?
Well, most relevant to you, we are only getting 100 boards on this first run. If you really want a Maple you might want to pre-order. You’ll get the board at the same time and not risk them selling out. Also, we are really interested in gauging the interest in this first round of Maple, and we figured the number of pre-orders and how fast the boards sell would be a decent proxy. This kind of info will be a factor in deciding how many to run for the next run of Maple and Maple Native.
Also, if you’ve tried to pre-order a board and paypal told you it was sold out…. paypal lied. Now that things are worked out, you should be able to pre-order a board here.
PS. For waiting so nicely, here’s a pretty picture of the old prototype:
(The release version differs in that power selection is made using a jumper, between standard barrel jack / USB power / LiPo batter, there is a larger external header to connect to all the external I/O pins not used by the Arduino pin-compatible layout and minor changes have been made to the silkscreen and layout.)
okie edit:
Here’s a picture of the third (we care a lot about getting it right) prototype for Maple. It has no soldermask or silkscreen because these barebones PCBs are cheap and Advanced Circuits ships them the next day. The layout on this one is a lot better than the one in the picture above. The traces have more direct routes, the microcontroller is closer to the pins in the Analog section so that those trace lengths are minimized, and those traces are also farther apart to minimize crosstalk. The LiPo/Li-Ion battery charger on the board seems to work well. I’ve been repeatedly charging and discharging a LiPo battery. It charges it from nearly completely dead in about 20 minutes. A red LED means that a battery is connected and is charging, which you can do by USB power, a wall adapter, or another DC power source greater than 5V. When the battery is charged, a green LED comes on. The charging component is pretty smart in measuring the battery and determining when and how to charge it. It’s probably used in cell phones, media players, etc.
The components on the boards that are going out for preorders are machine placed. The pads are gold plated. The soldermask is deep red like the leaves of a maple tree in the late fall. There aren’t a lot of things much better than working with beautiful hardware on a crispy cool fall night.
Here’s a screen capture of it:
This also has alternate header pads that are in standard 0.1″ spacing with the other headers for those who also like perf board.