We’ve been bursting forth with code and hardware as the weather improves but have neglected to share them with you despite many emails and conversations; thanks for all your interest!
On the top of our stack is the next batch of Maple boards, rev3. We’ve got a small production batch back for testing and will have boards for sale as soon as the full run comes back from assembly. We’re toiling away on stable versions of our bootloader, low level library, and arduino-based IDE to be released at the same time as these boards go on sale; you can track our development on github and we look forward to your comments and critique as once the dust settles. We’ve also got a shiny new website and fancy documentation in the pipeline.
We spent a whole day this past week testing the Maple rev3. The biggest fixed issue is noise, both crosstalk between headers and digital noise from the USB bus. The USB noise is still detectable, while the crosstalk has virtually disappeared on most pins. We’re collecting hard numbers on our actual ADC (analog voltage measurement) precision and accuracy; in theory we could get 12-bit resolution over the 0-3.3v range but most development boards have trouble meeting the full potential of their parts. We’ll report back once we’re more confident of our test setup and peripheral configuration, but it looks pretty reasonable.
As part of the testing process I wrote up an interactive testing program which acts as a console over one of the USART serial ports and has commands to read in GPIO status, spit out servo-compatible PWM sweeps, dump data over the USB connection, etc. We’re thinking of including this as the default program on the rev3 Maples, what do you think? Should we make the interface over USB instead of USART? You can look at what we have now here. In the future we’re excited to see if we can port more complete environments like eLua or python-on-a-chip.
Breadboarding PWM audio with the Maple
One use for high resolution ADC sampling is real time audio work! With the right low pass filter (which can be just a couple resistors and capacitors) the high speed PWM ports on the Maple can pump out reasonable audio-frequency waveforms. Okie has been working on a basic audio shield with nice active filters and other goodies.
Of course a dedicated DAC could give much higher audio fidelity, and many microcontrollers can implement basic audio synthesis. We’re experimenting with some more computationally intensive frequency domain effects and are planning on building a more fancy professional grade audio shield for the Maple Native… the delux version of the Maple with a larger header configuration and more features, which we’re now prototyping. Jess has been using an open source tool (Kicad) to do the design and layout for the Maple Native and she’ll be posting about that experience soon.
There’s more going on; check out our flicker stream for more photos of testing, a MIDI/IR theramin, wifi routers, and a ghost from our past soon to be reincarnated.
on April 27, 2010 at 1:09 am
· Permalink
AWESOME!, I cant wait till the next run is out!, i been waiting for the Maple native but i think i wont be able to hold it that long before i just buy one.
keep up the great work!, and please keep us informed about the developments =)
on April 28, 2010 at 2:17 pm
· Permalink
Thanks! Feel free to give us a poke if you get too impatient; we haven’t been on IRC as much but we definitely reply to email!
on April 27, 2010 at 2:39 am
· Permalink
Cool, I hope to see eLua running on it.
But eLua need 256KByte Flash Maybe you need to upgrade your chip to STM32F103Z series.
I like the libmaple . It is clean and beautiful.
on April 28, 2010 at 2:16 pm
· Permalink
Thanks! We’ll try to live up to such flattery.
Yes, eLua might have to wait for the Native, but hopefully we can get python or something similar on the regular Maple.
Related question: we’re debating RAM options for the Maple Native (whose uC has an FSMC bus). How much ram is useful given that more increases the price? IIRC there are options from 1mb up through 16mb in the package we’ve laid out. Should we always place a 2 or 4mb chip and get the price down through economies of scale? Or offer a whole range of RAM sizes at different costs (including nothing populated on the board which would let you upgrade later; it’s a big SMD part but definitely doable with a good iron and steady hand).
on April 28, 2010 at 4:35 pm
· Permalink
Since we’re tech customers I definitely think you should offer something like 3 levels of ram; basic 2 or 4mb version(depends on the cost factor, think entry level for the native), 8mb advanced version, and the 16mb monster version.
I think more than that will complicate stock/assembly/tracking/logistics way too much.
on April 28, 2010 at 12:15 pm
· Permalink
USB or serial doesn’t really matter to me. There are a plethora of ways to adapt between TTL rs232 and USB, so I wouldn’t worry about it.
The one area you really want to focus on though is wireless. Blutooth or Xbee or any other way you solve it, people will want the ability to both interact with Maple over wireless and if you can also give the ability to program Maple over a wireless protocol, all the better. I’m partial to SparkFun’s BlueSmirf Gold, but that’s just me.
on April 28, 2010 at 2:11 pm
· Permalink
Well it isn’t actually TTL rs232, it’s at 3.3v, but most FTDI-style devices work fine. We’ll probably add USB functionality eventually just so we don’t have to fight over our precious FT232RL breakouts in the office…
Yes wireless would be great! I haven’t played with a Fio or Bluetooth Arduino yet but i’d love to. We don’t currently have plans for integrating wireless right on the board but most existing arduino shields should work.
I’ve got my eye out for wireless SDIO cards (like eye-fi but hopefully for bluetooth and 802.15.4 too) we could use with the Maple Native to get cheap wireless functionality. We haven’t decided whether or not to include an SD card slot on the Native; maybe we’ll just route the pads onto the bottom of the board and let users add the slot if they don’t mind a bump on the bottom?
I’m personally disappointed with the whole ZigBee licensing situation and want to get hacking on some alternative 802.15.4 protocols, especially 6LoPan. I was poking around to see how feasible a full software implementation would be using Oak and it definitely wouldn’t be trivial but perhaps we can find a more simple radio protocol (HAM packet radio? I don’t think any of us are licensed) to start hacking with first.
on April 28, 2010 at 4:42 pm
· Permalink
I’d say SD card Slots is always a big plus, if you cant get it on the top, put it on bottom and include some shot standoffs.
on May 3, 2010 at 10:18 am
· Permalink
I think hardware USB as at least a virtual com port eliminates the extera chip problem and Teensy++ even encorperated it almost seemlessly into the arduino IDE.
So with a much simpler chip hardware USB com port was implemented.
You show you work with sound etc. Well more bandwith could be good with that.
Aparently with radio their has been a radio programed arduino that is buyable not the expensive bluetooth one.
on May 3, 2010 at 10:21 am
· Permalink
The USB example trial on git.hub looks interesting does the USB time out?
So that is what you guys like for a software version control system?
Joomla has a subversion option and sets up quite a nice content management system.