anyone made a shield template for these?
i'm getting started on one, but wouldn't mind being stopped by someone with it already complete ;)
if not, i'll post what i come up with.
anyone made a shield template for these?
i'm getting started on one, but wouldn't mind being stopped by someone with it already complete ;)
if not, i'll post what i come up with.
well, i guess i should have looked in the folder named "mapleshieldtemplate" before i posted..
is there a reason why the reset button and diode are included here?
and it looks like this might not support the rev5's with the new pin spacing?
Well the reset and power plug are higher than the headers.
You could use kicad. I made a r3 shield for a prototipe I am working on and made a maple like board in kicad. the maple like board is dr-brog-arm.zip
and the shield for maple r3 is shield.zip
https://sites.google.com/site/openloopproject/
ok, so, the specifics of rev 5's breadboard 100mil compliance aren't really well documented.
a change log might be nice.
for interested parties:
the 2x9 header that was on previous revs is now a 2x8 header. pins 21 and 22 are broken out into a 2x1 jumper-ish header labeled RTC, which is about 200 mils to the left of where it would have been otherwise (where it would have overlapped a drill).
i'm unclear about whether or not it makes sense to include the two disjointed pins in a shield.. it's probably circumstantial, but could make certain shields incompatible with other shields when stacking more than one.
i'm also confused as to why the header is labeled RTC, when the datasheet indicates those pins are used for SPI or ADC (or TIM3 for 22)..
any thoughts?
(and yes, the power plug is higher than the headers, which is frustrating, but can be worked around.. there's no change in the board outline for the shield, which indicates spacers should be used if there is a clearance issue. the reset button isn't higher than the headers, so i'm not really sure what you mean there...)
(p.p.s - st just revamped their website and now visiting it is like trudging through a swamp. hope you downloaded those datasheets earlier! ;)
at the risk of talking to myself, looking at these eagle files a bit more prompts another couple of questions about board layout choice...
arduino shield compatibility is certainly a stated goal of the maple board, which is understandable. what i don't get is why you guys chose to make the board shorter than the arduino. cause now, when used with a typical arduino shield, you'll get some serious overhang, which could make fitting a project into an enclosure troublesome. the smaller layout, while nice for compactness, also translates to less usable space in maple shields, since extending in the direction of the plugs causes overhang, and extending in any other direction puts the connectors right in the middle of the layout (which may or may not be a problem depending on the design)
similarly, why is the lipo connector facing the same direction as the usb? if you have a project with a rechargeable battery, and you want to put it in an enclosure, the usb should face out, but the battery should be housed in the casing, no?
hopefully these are constructive questions?
I think that the Maple layout was only really designed for minimal compatibility. The Maple Native would be the more "real" version of the Maple, but for the transition period, the Maple's Arduino-esque layout is helpful. I'm not sure how the overhang causes problems with fitting in an enclosure, unless you mean one designed for the Maple with its smaller size. Either way, the idea about the LiPo going inward is good. Or at least moving it further inboard.
just to be clear: native completely breaks arduino compatibility. the 'arduino-compatible' constraint made it difficult to fully take advantage of the capabilities of the stm32 line, so we're not trying on native, in order to make it a better overall platform. arduino shields won't fit on the native.
native will be _software_ compatible with maple and mini, however (modulo a few differences related to which pin can do what).
hmm. Interesting suggestions.
first off, yea those template docs need to update, thanks for pointing it out.
The other suggestions are good food for though. Made me think "hmm, ill open up a wiki page"....ugh, but no wiki. Setting one up. I think well throw it on googlecode (/p/leaflabs)
we dont host our code there anymore, but we do host the bugtracker, and potentially now the wiki
the problem that the overhang causes isn't fitting the sandwich in an enclosure, but accessing the usb and dc jack once it's enclosed. using an ethernet shield, for example, your ethernet port would be flush with the enclosure, but the usb and dc jacks are now recessed. have fun with firmware updates. fail.
i also disagree with the notion of "minimal compatibility" from a hardware perspective. either the shields physically fit, and the pins can perform the appropriate push/pull/ain actions, or they don't. particularly in this case, where it takes an engineering compromise to be compatible (the compromise here being the arduino's aggravating, unique header spacing that renders it incompatible with breadboards and generic proto boards).
i do think that the overhang issue will discourage folks from using some arduino shields, and that the smaller board size is less friendly to a maple-specific protoshield, but i'd be happy to be proved wrong on both of these.
and yes, it's good to be clear. i wasn't under the impression that the native would be compatible with arduino shields. i am glad you guys are throwing the HD chip on it though.. i had a bit of buyer's remorse today when comparing the datasheets of the MD and HD chips.. no dac, no sdio, no i2s... no fun! that's my fail for the day..
fail early, fail often, fail cheaply =)
(then win big)
soundcyst: the word from okie on your constructive questions: "they're all good points"
rough files:
schematic - http://db.tt/qFiBjC5
board - http://db.tt/cvOMq0c
note that the breakouts aren't on a .1" grid, as they're designed for jumper wires rather than breadboarding.. if you're making a proper shield, you probably won't want the breakout pads anyways (just use doublestack headers)
Ok, I get what you mean now. The USB and DC being recessed would create a problem for enclosures that have them flush. I didn't think of that because I am making a custom shield and a custom enclosure, so the problem never occurred to me (and I don't need the USB to be flush). Now that I understand you, I think these could be some good ideas for future Maple revisions.
Anyway, I think we all agree that the Maple Native isn't intended to be Arduino-compatible for hardware.
You must log in to post.