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.
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.
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.
on February 16, 2010 at 4:17 pm
· Permalink
when will the maple native come alive?
on March 30, 2010 at 10:38 pm
· Permalink
when it’s ready!
maple-native shields/extensions will be compatible with oak so we need to be very careful about our headers and pin out selection. we’re doing layout now, it will be at least a month or two before the first batch of natives are available.
on February 18, 2010 at 10:34 am
· Permalink
I know on my google project that uses a lot of references and regulators The data sheets for them mention a low ESR caps on inputs and outputs and trim aireas that can use a capacitor or low esr cap.
If you go to 4 layor boards or larger boards please go truly open source use kicad I use it it works great for my open source project eagle has limitations & is not open source like kicad.
Also kicads scripting options for all of its files lead to some interesting posibillities.
on February 23, 2010 at 12:16 am
· Permalink
were trialling kikcad now! In fact, the maple native layout is being done in kicad
on February 23, 2010 at 8:21 am
· Permalink
Great Kicad is what I use free route I like for simple boards & it makes it truly open source. I know it is different from eagle but EMSL and other tutorials for it are great. The mailing list is very VERY smart.
Here is a link to my kicad stuff…
http://sites.google.com/site/openloopproject/
I am looking forward to the release does this output the true usb high speed virtual com port from the arm hardware? I want to shovel lots of data from my ads1278.
I have not found a way to do it yet easly. The teensy sorta works but it may get bogged down trying to pull in all the samples & output them the usb.
on February 23, 2010 at 12:37 pm
· Permalink
The high speed virtual serial port or virtual com port option linking the print commands arduino code to the usb and linux would be great do they work???
on March 30, 2010 at 10:42 pm
· Permalink
It can and has worked on each platform; right now we’re playing with the bootloader and serial drivers trying to come up with the most reliable configuration across the major versions of Linux, OSX, and (*sigh*) Windows.
on March 20, 2010 at 5:42 pm
· Permalink
This project sure looks very good! Good to see some folks with a bit more electronic engineering experience to build such boards
I’m more of the software. Although i must say that a basic Arduino can do a lot more than most ppl. think/experience… mainly due to bad coding styles :-/
What i wonder though, is `Maple 2′/ `Maple Native’ going to have headers for the extra outputs too? The proto board doesn’t show them yet. (pin 21-39).
Will the libraries/toolkit be available as a gcc target? or only as an IDE? I’d rather prefer the 1st !
Keep up the good work!
on March 30, 2010 at 10:55 pm
· Permalink
Hi Reinoud!
The AVR Arduinos certainly do have a lot of power that can be tickled out with careful coding! Perhaps some of that power will be released in the uno punto zero release with some macros or fiddling about with the hardware libraries; we imagine that our libraries will be somewhat unoptimized as well, at least initially. A lot of what we’re trying to offer with the Maple is access to advanced functionality (multimedia, communications, data processing) and multi-tasking without spending hours twiddling and debugging C and Assembly.
The next batch of Maples will have headers on pins 21-39 and also a table silkscreened on the bottom showing the functionality of each pin. Maple Native is going to have… a lot… of headers… something like 112. That’s a lot of kicad routing!
The libmaple library is released/developed separately from the IDE; the workflow we use for development is to edit a main.cpp file that looks a lot like an arduino sketch and compile/flash that using command line tools, then use gdb over a jtag interface to do debugging. It’s “pretty simple” once you get your development set up, but that’s always more of a headache than you expect it to be, which is the whole point of the IDE. You can take a peak at libmaple on our github page; we’ve been meaning to write up a blog post about it: http://github.com/leaflabs/libmaple
Thanks for posting!
on April 23, 2010 at 11:25 pm
· Permalink
“Medium worst case scenario would probably be sometime around March 31.”
sorry guys… but it’s painful and frustrating to see such a cool and promising project kill itself.
you should definitely try to be more communicative and transparent with us
sincerely your eager customers and maple fans.
on April 27, 2010 at 12:24 am
· Permalink
We posted a new blog entry today with an update; do you have an specific questions?
We are sorry to have slipped on casual deadlines but many of us have separate full time jobs or are full time students which makes logistics and forward planning difficult. The academic summer should free up a lot more hours in a week but we’re doing our best to push out releases and new hardware before then.
on May 19, 2010 at 11:19 am
· Permalink
This project sure looks very good! Good to see some folks with a bit more electronic engineering experience to build such boards
I’m more of the software. Although i must say that a basic Arduino can do a lot more than most ppl. think/experience… mainly due to bad coding styles :-/
What i wonder though, is `Maple 2′/ `Maple Native’ going to have headers for the extra outputs too? The proto board doesn’t show them yet. (pin 21-39).
Will the libraries/toolkit be available as a gcc target? or only as an IDE? I’d rather prefer the 1st !
Keep up the good work!
on May 19, 2010 at 12:02 pm
· Permalink
Hi Bruce!
The crummy image we put up of the native shows a whole lot of pins going on: http://www.leaflabs.com/wp-content/uploads/2010/02/maple_native_proto.png
If I recall there’s something like 64 header pins plus the 48pin FSMC headers which could be used as GPIO if you don’t want RAM… there aren’t that many actual pins run out because some are ground/power, but there are definitely a whole bunch!
Our base library (libmaple) is the foundation for the IDE and can also be used with gcc and other GNU tools… i’ll finish that HOWTO soon but in the meanwhile you can see the README on the github page (http://github.com/leaflabs/libmaple). We’re going to support libmaple on the maple native and any other stm32 boards we make (mini?); it should actually be pretty easy to port to other stm cortex-m3 projects as well.