4531 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:02:49 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=1664&page=2#post-10598 Thu, 10 May 2012 18:16:17 +0000 mbolivar 10598@http://forums.leaflabs.com/ <blockquote><p> What's not easy to deal with is that none of the 6 IDEs —Arduino 0023 and 1.0, MPIDE, Energia, Wiring, MapleIDE— share the same norms, although all claim to be Processing- and Wiring-based or derived. </p></blockquote> <p>Yes, the situation is completely out of control. Thank you very much for your efforts to reconcile the various implementations! </p> http://forums.leaflabs.com/topic.php?id=1664#post-10594 Thu, 10 May 2012 15:43:45 +0000 Rei Vilo 10594@http://forums.leaflabs.com/ <p>Thank you for your detailed answers.</p> <blockquote><blockquote>• Are you considering modifying the .build.mcu key —as in maple.build.mcu— in the boards.txt file? </p></blockquote> <p>No; this is a libmaple-only change (and the Make-based libmaple build system doesn't use boards.txt files). Is there some reason to change those? For example, are they annoying you in some way?</p> </blockquote> <p>Not at all. </p> <p>I raised that question only to be ready for the next release, as embedXcode uses the <code>.build.mcu</code> key from <code>boards.txt</code>.</p> <blockquote><blockquote>• Are you considering using __STM32_SERIES_F1__ instead of STM32_SERIES_F1 for better readability?</p></blockquote> <p>No, and I don't think that's more readable. [...]</p></blockquote> <p>The explanation is clear.</p> <p>What's not easy to deal with is that none of the 6 IDEs —Arduino 0023 and 1.0, MPIDE, Energia, Wiring, MapleIDE— share the same norms, although all claim to be Processing- and Wiring-based or derived. </p> <p>So you can imagine the complexity my embedXcode project has to cope with! </p> http://forums.leaflabs.com/topic.php?id=1664#post-10574 Wed, 09 May 2012 08:31:20 +0000 mbolivar 10574@http://forums.leaflabs.com/ <blockquote><p> • Are you considering modifying the .build.mcu key —as in maple.build.mcu— in the boards.txt file?</p> </blockquote> <p>No; this is a libmaple-only change (and the Make-based libmaple build system doesn't use boards.txt files). Is there some reason to change those? For example, are they annoying you in some way?</p> <blockquote><p> • Are you considering using __STM32_SERIES_F1__ instead of STM32_SERIES_F1 for better readability?</p> </blockquote> <p>No, and I don't think that's more readable.</p> <p>Names with underscores before or after (and more so with _double_ underscores before _and_ after!) are often used to indicate that something special is going on. In fact, double-underscore identifiers are technically reserved for use by the compiler (though we do "cheat" and <a href="https://github.com/leaflabs/libmaple/blob/v0.0.12/libmaple/libmaple_types.h#L49">use them sometimes</a>). If the AVR MCU identifiers are provided by avr-gcc, then that's one thing, but the STM32_SERIES_xxx are part of libmaple, and are just normal defines used to avoid magic numbers. </p> http://forums.leaflabs.com/topic.php?id=1664#post-10572 Wed, 09 May 2012 05:58:48 +0000 Rei Vilo 10572@http://forums.leaflabs.com/ <p>Two questions:</p> <p>• Are you considering modifying the <code>.build.mcu</code> key —as in <code>maple.build.mcu</code>— in the <code>boards.txt</code> file?<br /> • Are you considering using <code>__STM32_SERIES_F1__</code> instead of <code>STM32_SERIES_F1</code> for better readability?</p> <p>Thank you! </p> http://forums.leaflabs.com/topic.php?id=1664#post-10549 Tue, 08 May 2012 22:56:01 +0000 mbolivar 10549@http://forums.leaflabs.com/ <p>rei:</p> <p>there are some changes to libmaple/stm32.h in the pipeline which will also make this easier. the development branch is wip-family-support:</p> <p><a href="https://github.com/leaflabs/libmaple/tree/wip-family-support/" rel="nofollow">https://github.com/leaflabs/libmaple/tree/wip-family-support/</a></p> <p>we're updating the &lt;libmaple/stm32.h&gt; include to make it easier to interrogate libmaple about the current build target. new features include:</p> <p>- STM32_MCU_SERIES: series for the current target. values are STM32_SERIES_F1, STM32_SERIES_F2, etc.<br /> - (for STM32F1 targets): STM32_F1_LINE: line for the current target. values are STM32_LINE_PERFORMANCE, STM32_LINE_VALUE, etc.</p> <p>thanks to anton eltchaninov, there's going to be value line support in the mainline libmaple tree! F2/F4 work is also getting closer. check out the code for more details. i've also started to update the documentation for this; for now, you can watch the leaflabs-docs branch libmaple-next for more:</p> <p><a href="https://github.com/leaflabs/leaflabs-docs/tree/libmaple-next" rel="nofollow">https://github.com/leaflabs/leaflabs-docs/tree/libmaple-next</a></p> <p>this work has been a long time coming. it's not ready for prime time yet, but we'll be sure to write a blog post when this branch is merged into master. </p> http://forums.leaflabs.com/topic.php?id=1208#post-10548 Tue, 08 May 2012 22:48:13 +0000 mbolivar 10548@http://forums.leaflabs.com/ <p>rei -- looking forward to less forking and less NIH. </p> http://forums.leaflabs.com/topic.php?id=1664#post-10535 Tue, 08 May 2012 14:07:43 +0000 Rei Vilo 10535@http://forums.leaflabs.com/ <p>Thanks! </p> http://forums.leaflabs.com/topic.php?id=1208#post-10533 Tue, 08 May 2012 08:29:03 +0000 Rei Vilo 10533@http://forums.leaflabs.com/ <p>@tochinet</p> <p>I fully agree with you: the NIH syndrome is devastating.</p> <p>For that reason and because I'm currently using different platforms —Arduino, chipKIT Uno32, ultra-low-power LaunchPad, Wiring and soon Maple—, I'm tired of having one IDE per platform, which only difference is the colour —blue, dark red, light red, orange and green. </p> <p>So I've developed a set of makefiles I could use with any IDE, in my case, Xcode because I own a MacBook. I also tested it on NetBeans.</p> <p>This makefile-based approach is based on the assumption that the claim " Writing a sketch is not programming " is just fairy tale. I'm confident that considering a sketch as plain C++ code could ease development, with no hidden "dirty work" done below.</p> <p>I'm working closely with Hernando Barragán to promote this idea. </p> <p>If you're using a Mac computer or just for fun, pay a visit to <a href="http://embedxcode.weebly.com/" rel="nofollow">http://embedxcode.weebly.com/</a> to learn more.</p> <p>Enjoy! </p> http://forums.leaflabs.com/topic.php?id=1664#post-10531 Tue, 08 May 2012 08:24:42 +0000 crenn 10531@http://forums.leaflabs.com/ <p>*IDE Directory*/hardware/leaflabs/cores/maple/stm32.h</p> <p>MCU_STM32F103RB LeafLabs Maple<br /> MCU_STM32F103ZE LeafLabs Maple Native<br /> MCU_STM32F103CB LeafLabs Maple Mini<br /> MCU_STM32F103RE LeafLabs Maple RET6 edition </p> http://forums.leaflabs.com/topic.php?id=1664#post-10530 Tue, 08 May 2012 08:18:13 +0000 Rei Vilo 10530@http://forums.leaflabs.com/ <p>Hi!</p> <p>Most of the Processing-based IDEs as LeafLabs MapleIDE have a unique identifier for the CPU. </p> <p>Examples:<br /> • Arduino: <code>__AVR_ATmega328P__ __AVR_ATmega2560_</code><br /> • chipKIT MPIDE: <code>__32MX320F128H__ __32MX795F512L__</code><br /> • Wiring: <code>__AVR_ATmega644P__</code><br /> • LaunchPad Energia: <code>__MSP430G2452__ __MSP430G2553__ __MSP430G2231__</code><br /> • MapleIDE: ?</p> <p>What are the identifiers for MapleIDE and where are they defined?</p> <p>This is critical for my embedXcode project, Xcode for embedded computing. Learn more about embedXcode at <a href="http://embedxcode.weebly.com/" rel="nofollow">http://embedxcode.weebly.com/</a> </p> http://forums.leaflabs.com/topic.php?id=1208#post-8218 Thu, 16 Feb 2012 08:57:33 +0000 tochinet 8218@http://forums.leaflabs.com/ <p>For a good reason to migrate to Wiring, look at Arduino : they started from ... Wiring, made minor changes, up to 0022, and then ... broke it into the 1.0. Or look at Pinguino : they reengineered Wiring in Python for some unknown reason, hoping some day to support ARM cortex , AVR and PIC altogether (both 8 and 32 bits), and ... never got there.</p> <p>Maintaining an IDE is work, and it's a shame (IMHO) to have 4 or more parallel versions of nearly the same thing, just because of teh NIH syndrome. Some other people (Jeelabs, chipkit or pjrc's teensy) could understand that and wanted to "stay compatible" with the Arduino IDE. 1.0 was a pain in the *** for them.</p> <p>So I applaud the move of leaflabs to join forces with Wiring team. The more the better. I only wish leaflabs or wiring active people could give more info on what's going on (or why it's stalled), what are the plans, etc. Because I've seen little more than a LOI at this moment.</p> <p>BTW @LarryP, could you tell us where the Wiring IDE documentation is _most_ behind Arduino's or Maple's ? It looks similar to me, except there are less libraries. </p> http://forums.leaflabs.com/topic.php?id=1208#post-7317 Mon, 12 Dec 2011 18:43:09 +0000 poslathian 7317@http://forums.leaflabs.com/ <p>right you are. </p> <p>Also, an eclipse plugin would be nice. I have seen several Maple-eclipse setups that were built by hand using the command line tools environment we provide. It would be great to really polish that up and put it out there. </p> <p>In terms of Wiring, the exact path forward it still being worked out so I cant say too much. The long term vision is to provide a single environment with cross-vendor support and to develop a wirish (digitalWrite, Serial1.print, etc) level (rather than libmaple level) API that is standard across many devices, including crossing the 8/16/32 bit boundaries. This is a difficult undertaking to get right, so its really just getting started. The final perk would be that rather than a bunch of vendors all forking their own IDE, they can all put their efforts towards improving one IDE which will ostensibly mean a lot more polish. For example, the windows installation process on win7 64 -bit could become a double-click sort of endeavor ;)</p> <p>There are not a ton of finalized details for me to make available at this point, but we more than welcome your feedback. </p> <p>There has also been talk of an open shield standard, which I think is really important. Although IMO gadgeteer's peripheral model is so much more useful than the Arduino style shield. I dont know what the shield standard will look like, but it would be so great to be able to design a shield that works on many different vendors boards (and board types) and indicate that fact to all your customers. Not only that, but a standardized Wiring API (The Wiring Framework) would mean that any libraries/drivers written for a shield that adhere to the API would work across a ton of different devices. Its certainly a dream, but I think a really powerful one. </p> http://forums.leaflabs.com/topic.php?id=1208#post-7289 Thu, 08 Dec 2011 22:44:26 +0000 robodude666 7289@http://forums.leaflabs.com/ <p>If you're currently using libmaple, or the MapleIDE, it does not affect you.</p> <p>Wiring 1.0 is a release that attempts to decouple platform-specific support from the language. In reality, for most people all it changes is... the IDE will be orange instead of green. That's about it. Leaflabs is working with Wiring to have libmaple built right in, and it aught to work the same or better than the current MapleIDE (from what I understand).</p> <p>If you're currently using libmaple from the command line, you can continue to do so. </p> http://forums.leaflabs.com/topic.php?id=1208#post-7288 Thu, 08 Dec 2011 22:30:05 +0000 LarryP 7288@http://forums.leaflabs.com/ <p>I read in the leaflab blog that the IDE for programming Maples was heading toward Wiring. On first glance, I don't offhand see much benefit. That may well be due to the IMHO poor Wiring documentation: Many, many fragments, and not an overview or architectural summary anywhere I could find. (IMHO, even by itself, unclear docs tends to indicate a less-than-clean design lurking.)</p> <p>Would somebody wise in the strengths of Wiring (and/or on the leafLabs team) explain why this (forkish) change in direction is a *good* thing, rather than a confusing, compatibility-breaking thing? IMHO, if an alternative to the Arduino GUI is to chosen, I'd much rather see leafLabs moving to a well-supported Eclipse environment. </p> <p>Comments? </p>