http://forums.leaflabs.com/topic.php?id=1045 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:20:08 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=1045&page=2#post-6690 Fri, 30 Sep 2011 04:05:25 +0000 mbolivar 6690@http://forums.leaflabs.com/ <p>There's nothing that easy yet for adding to the Boards menu, but it's a good idea, and shouldn't be too hard to implement. We've got some reasonably big news upcoming on the IDE front, so I won't commit to implementing that quite yet, but a mechanism like that for adding new boards easily is definitely a nice feature that we should add. </p> http://forums.leaflabs.com/topic.php?id=1045&page=2#post-6680 Thu, 29 Sep 2011 17:33:50 +0000 gbulmer 6680@http://forums.leaflabs.com/ <p>I would like the ability to define new boards easily.<br /> I'd be happy with<br /> <code>#include &quot;custom_board.h&quot;</code><br /> while developing prototypes.<br /> Is their an easy way to add to a 'Boards' menu?<br /> I am thinking of something as trivial as name value pairs.<br /> something like: board-name to be displayed in the menu, and custom-header-filename to be #included in source,<br /> e.g. "Orone" ",,/Orone/orone.h" </p> http://forums.leaflabs.com/topic.php?id=1045&page=2#post-6671 Thu, 29 Sep 2011 13:05:38 +0000 mbolivar 6671@http://forums.leaflabs.com/ <p>coming up with a good naming scheme now does seem like a good idea.</p> <p>something like manufacturer_boardname[_version] seems like a reasonable starting point. i'm not sure about the the user being part of the name. e.g. torfbolt is the maintainer of the new olimex board support (which just merged), so "torfbolt" (or "David Kiliani") should go into a MAINTAINERS file or something, rather than the name of the board, so that there's a handoff procedure if he ever decides to stop working on it.</p> <p>as for version, i'd rather make that optional. i'm leery of too many versions of a board getting in and cluttering everything up. for instance, we don't keep the board files for our prototypes in libmaple.</p> <p>in a related matter, there should be a way to provide support for a board just by defining the right functions and data structures, in the same way you get newlib syscall support just by defining the right <a href="https://github.com/leaflabs/libmaple/blob/master/libmaple/syscalls.c">stubs</a>. my idea for doing this is here:</p> <p><a href="https://github.com/leaflabs/libmaple/blob/1873871aeaacad66d9c8b06211c7b32aaea5c829/wirish/boards.h#L141" rel="nofollow">https://github.com/leaflabs/libmaple/blob/1873871aeaacad66d9c8b06211c7b32aaea5c829/wirish/boards.h#L141</a></p> <p>we could just remove the warning altogether, and replace it with a <code>#include &quot;custom_board.h&quot;</code> or something (or just remove it altogether and let people make a custom header that does the right thing before including wirish.h). this would let people manage their own boards without modifying the libmaple source code, which is nice during development and allows people to distribute support for a board as just a pair of board files (assuming libmaple already supports the MCU).</p> <p>thoughts? </p> http://forums.leaflabs.com/topic.php?id=1045&page=2#post-6624 Mon, 26 Sep 2011 18:56:08 +0000 corguy 6624@http://forums.leaflabs.com/ <p>Do you have a naming scheme or standard for naming "foreign"(non-maple) boards. I used maple_ as a prefix to my board name and in hind sight I thought that might not be good. It's not a big deal now but it might be when you have tens or hundreds of foreign boards and keeping track of them could become a problem. That is assuming you want all of them in the main code base.</p> <p>What about something like (company or user or lastname) + MCU + version. So CORGUY_VET6_V000 would be mine. The Olimex (if it has not been merged in) could become OLIMEX-TORFBOLT_RBT6_V000. The ST discovery could be ST-ANTON_F100RB_V000. Seems like now would be a good time to give all that some thought. </p> <p>I'm not going to issue a pull request until things are running well on the VET6 anyway. </p> http://forums.leaflabs.com/topic.php?id=1045&page=2#post-6615 Mon, 26 Sep 2011 08:35:05 +0000 mbolivar 6615@http://forums.leaflabs.com/ <p>Chances are good. Just send us a pull request on GitHub. Please read the docs on contributing to libmaple first:</p> <p><a href="http://leaflabs.com/docs/libmaple/contributing.html" rel="nofollow">http://leaflabs.com/docs/libmaple/contributing.html</a></p> <p>Reading that will help save us both some time, since e.g. we only accept signed-off pull requests when they touch libmaple or wirish.</p> <p>You can use git rebase -i to reword existing commit messages; <code>git help rebase</code> for more info. </p> http://forums.leaflabs.com/topic.php?id=1045&page=2#post-6602 Sun, 25 Sep 2011 20:29:46 +0000 corguy 6602@http://forums.leaflabs.com/ <p>I may hold off on doing the bootloader mods then, I won't need the bootloader for several weeks anyway while I get the first board running. </p> <p>What are the chances of getting the VET6 mods merged into the main code or am I "forked" forever? </p> http://forums.leaflabs.com/topic.php?id=1045&page=2#post-6570 Sat, 24 Sep 2011 18:34:02 +0000 mbolivar 6570@http://forums.leaflabs.com/ <p>Glad to hear that everything went well.</p> <p>By the way, the USB code is about to change pretty drastically. Today while you were adding VET6, I was rebasing a bunch of USB changes I've been making to the top of the tree. These will get merged in as soon as I've tested them out on OS X and Windows:</p> <p><a href="https://github.com/mbolivar/libmaple/tree/usb-touchups2" rel="nofollow">https://github.com/mbolivar/libmaple/tree/usb-touchups2</a></p> <p>The new version isn't perfect, but notably, the CDC ACM API got ripped out into its own file, so if you want to e.g. use the USB peripheral for HID, you can add that in without stepping all over our stuff. The new stuff mostly follows the current libmaple styles and conventions, so it should be more readable than the old stuff as well.</p> <p>Edit: In particular, this commit will affect you:</p> <p><a href="https://github.com/mbolivar/libmaple/commit/970d11c9e2c6664701230c60ea3e9e09407abd86" rel="nofollow">https://github.com/mbolivar/libmaple/commit/970d11c9e2c6664701230c60ea3e9e09407abd86</a> </p> http://forums.leaflabs.com/topic.php?id=1045&page=2#post-6568 Sat, 24 Sep 2011 17:53:52 +0000 corguy 6568@http://forums.leaflabs.com/ <p>Sure thing, glad to do what I can.</p> <p>I used your instructions and made all the modifications to libmaple today to support<br /> the VET6 MCU and my board. I did not find anything of note that you did not cover. It<br /> would have helped me to sit down first and list all my pins and what they are used<br /> for, there was a lot of going back and forth and the whole process took longer than<br /> it should have. But in the end I was able to compile libmaple for my VET6 board... now if I just had some hardware to run it on.</p> <p>I'll probably take a look at the USB code next week at the office were I have multiple monitors to work with. Thanks again for your help, saved me a ton of time! </p> http://forums.leaflabs.com/topic.php?id=1045&page=2#post-6552 Sat, 24 Sep 2011 14:03:05 +0000 mbolivar 6552@http://forums.leaflabs.com/ <p>That would be awesome! Thanks for the offer to help!</p> <p>I agree that libmaple's scheme should work fine here as well. The only "gotcha" I can think of is that the same libmaple style of different linker scripts for the medium- and high-density chips also needs to get ported over. </p> http://forums.leaflabs.com/topic.php?id=1045&page=2#post-6550 Fri, 23 Sep 2011 19:59:45 +0000 corguy 6550@http://forums.leaflabs.com/ <p>Thanks for the tip, using the mini cut the diffs in half. </p> <p>If you would like some help I'd be willing to take a shot at taking a<br /> unified approach to adding support for the VET6. I've looked at the diffs<br /> and I think I could do it as easy as hacking in support for the VET6. Using the same type of scheme as libmaple BOARD_maple_native, BOARD_maple_mini, etc seems to be workable. Let me know your thoughts as I have spent a sum of about 20 minutes looking at the code. </p> http://forums.leaflabs.com/topic.php?id=1045&page=2#post-6544 Fri, 23 Sep 2011 16:51:55 +0000 mbolivar 6544@http://forums.leaflabs.com/ <p>Just FYI, the master branch is pretty old, so as I'm sure you've discovered, the diff between that and native-boot has a fair amount of extraneous crap that won't be relevant for getting the VE patch done.</p> <p>I recommended diffing from mini-boot because it's the cleanest diff which still gives you the information you should need -- over time, as the branches have evolved, we've gotten progressively more general, so the changes between bootloaders has decreased between each new board's release.</p> <p>I really am sorry that this is the state of affairs. All of these branches really need to be replaced with a single one where the appropriate header gets included for the board you're compiling for, just like libmaple. It just hasn't gotten done mostly out of inertia and lack of developer time.</p> <p>In any case, please do keep us posted as you go. </p> http://forums.leaflabs.com/topic.php?id=1045#post-6539 Fri, 23 Sep 2011 16:08:13 +0000 corguy 6539@http://forums.leaflabs.com/ <p>Right, I was trying to follow your directions to start with just the maple-native code but that's where I did not get how git works to pull a branch. I see now, thanks for the help. </p> <p>For future reference for git newbies like me:</p> <p>git clone <a href="https://github.com/leaflabs/maple-bootloader.git" rel="nofollow">https://github.com/leaflabs/maple-bootloader.git</a> (grab master)<br /> git branch -a (lists all the branches)<br /> git checkout native-boot (get the branch)<br /> git branch (now lists both master and native-boot locally)<br /> git diff master native-boot &gt; /tmp/diffs.txt (gives me all the diffs in a file)<br /> gitk --all &amp; (starts gitk GUI to browse the files) </p> http://forums.leaflabs.com/topic.php?id=1045#post-6538 Fri, 23 Sep 2011 15:41:11 +0000 mbolivar 6538@http://forums.leaflabs.com/ <blockquote><p> I took a look at maple-bootloader and it appears that all the board changes are branches rather than forks. It's not clear to me how to pull one specific branch like maple-native. Do you get all branches when you clone maple-bootloader? </p></blockquote> <p>yup; as i mentioned previously:</p> <blockquote><p> - DO NOT use the bootloader master branch as a starting point. (as of today) it's maple-only. the bootloaders for the other boards are in the the other branches (we know; sorry). the native-boot branch is the one used for maple native; i'd recommend starting there. </p></blockquote> <p>just <code>$ git checkout native-boot</code> for the maple native branch.</p> <p>to see the diff between mini and native (which may be helpful for picking out what you might need to change), do <code>$ git diff origin/mini-boot..native-boot</code>. </p> http://forums.leaflabs.com/topic.php?id=1045#post-6536 Fri, 23 Sep 2011 15:14:05 +0000 corguy 6536@http://forums.leaflabs.com/ <p>I took a look at maple-bootloader and it appears that all the board changes are branches rather than forks. It's not clear to me how to pull one specific branch like maple-native. Do you get all branches when you clone maple-bootloader? </p> http://forums.leaflabs.com/topic.php?id=1045#post-6533 Fri, 23 Sep 2011 13:32:56 +0000 corguy 6533@http://forums.leaflabs.com/ <p>I sent the gerber's off for the first pass prototype VET6 board today. I'll update as I see progress in getting libmaple running on it. And I'm sure I'll be back with questions. </p>