http://forums.leaflabs.com/topic.php?id=207 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:06:49 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=207&page=5#post-12294 Fri, 10 Aug 2012 20:04:23 +0000 feurig 12294@http://forums.leaflabs.com/ <p>Thanks I guess I misread the above. </p> http://forums.leaflabs.com/topic.php?id=207&page=5#post-12288 Fri, 10 Aug 2012 16:13:37 +0000 mbolivar 12288@http://forums.leaflabs.com/ <p>feurig:</p> <blockquote><p> How permanent is this change and when will we see it rolled into the new codebase?<br /> Am currently delivering 20 units and am thinking to myself that requiring perpetual bootloader mode is going to make field upgrades between the versions just this side of difficult.</p> </blockquote> <p>Not sure I understand the question. Why will you need perpetual bootloader mode? The patches just implement the new "open at 1200 baud, close" reset signal. Even with these patches, SerialUSB still accepts the old DTR + "1EAF" reset signal, so if you didn't need perpetual bootloader before, you shouldn't need it now, and if you do, that's a bug. </p> http://forums.leaflabs.com/topic.php?id=207&page=5#post-12261 Thu, 09 Aug 2012 14:36:28 +0000 feurig 12261@http://forums.leaflabs.com/ <p>This post is about changing the mechanism that the current libmaple uses to enter the bootloader. The change IMHO is significant. </p> http://forums.leaflabs.com/topic.php?id=207&page=5#post-12252 Thu, 09 Aug 2012 05:18:16 +0000 x893 12252@http://forums.leaflabs.com/ <p>:) easy way add CDC to bootloader but it increase code. Not need for me but this very easy to add CDC support. </p> http://forums.leaflabs.com/topic.php?id=207&page=5#post-12241 Wed, 08 Aug 2012 16:48:07 +0000 feurig 12241@http://forums.leaflabs.com/ <p>I need usb on mine, it is how we get the data off of the datalogger. </p> http://forums.leaflabs.com/topic.php?id=207&page=5#post-12240 Wed, 08 Aug 2012 15:23:32 +0000 x893 12240@http://forums.leaflabs.com/ <p>I make a simplest bootloader 2K site via serial port and compatible with avrdude (STK500 protocol). So i can add any feature as i need (no need USB for my devices). </p> http://forums.leaflabs.com/topic.php?id=207&page=5#post-12238 Wed, 08 Aug 2012 11:53:24 +0000 feurig 12238@http://forums.leaflabs.com/ <p>How permanent is this change and when will we see it rolled into the new codebase?<br /> Am currently delivering 20 units and am thinking to myself that requiring perpetual bootloader mode is going to make field upgrades between the versions just this side of difficult. I will have to do some testing. </p> http://forums.leaflabs.com/topic.php?id=207&page=4#post-12199 Sun, 05 Aug 2012 14:32:46 +0000 mbolivar 12199@http://forums.leaflabs.com/ <p>Thanks for the report. I was worried we'd get bad behavior like this. This unfortunately works fine for me on Maple Mini using 64-bit Ubuntu 12.04 and a 64-bit Fedora 17 virtual machine.</p> <p>I'll try to get an Arch VM up and running to see if I can reproduce. </p> http://forums.leaflabs.com/topic.php?id=207&page=4#post-12195 Sun, 05 Aug 2012 05:37:46 +0000 ventosus 12195@http://forums.leaflabs.com/ <p>I've tested this on a maple mini rev3 on 64bit ArchLinux.</p> <p>The method seems to work, but not with the python script (no matter if run with python2 or python3).</p> <p>The new reset.py script runs without errors, but the maple mini board is not reset.</p> <p>The old reset script/scheme still works as expected, though.</p> <p>What works for me is connecting to the maple mini with screen with a baud rate of 1200 and then disconnecting.</p> <p>&gt; screen /dev/ttyACM0 1200<br /> &gt;&gt; C-a C-k</p> <p>Then the maple mini does reset. </p> http://forums.leaflabs.com/topic.php?id=207&page=4#post-12183 Sat, 04 Aug 2012 02:09:05 +0000 mbolivar 12183@http://forums.leaflabs.com/ <p>Update: preliminary implementation:</p> <p><a href="https://github.com/mbolivar/libmaple/commit/df546c1ab0d8d35e7054be3c67ee8973a70b2ce7/" rel="nofollow">https://github.com/mbolivar/libmaple/commit/df546c1ab0d8d35e7054be3c67ee8973a70b2ce7/</a></p> <p>The current strategy is to accept both reset signals (DTR + "1EAF" and closing the connection when baud=1200). We can rip out the old sequence once the new one is widely installed.</p> <p><strong>Please test this out</strong>! It's in the new-reset-signal branch of <a href="https://github.com/mbolivar/libmaple">my libmaple tree</a>. HOWTO test(from within libmaple):</p> <pre><code>$ git remote add -f mbolivar git://github.com/mbolivar/libmaple.git $ git checkout -b new-reset-signal mbolivar/new-reset-signal $ make clean $ cp examples/blinky.cpp main.cpp $ make clean $ make</code></pre> <p>Now play away! <strong>IMPORTANT: the first time you upload using this new code, your board must be in perpetual bootloader mode</strong>. This is because reset.py in this tree no longer sends the old reset signal, so you'll need to "bootstrap" the install process by doing one upload to get the new reset firmware installed before it starts working.</p> <p>Independent confirmation that this works on various machines would be really nice.</p> <p><strong>Update</strong>: Seems to work pretty reliably (one failure out of 15ish attempts) on OS X 10.6. </p> http://forums.leaflabs.com/topic.php?id=207&page=4#post-12133 Tue, 31 Jul 2012 16:13:42 +0000 mbolivar 12133@http://forums.leaflabs.com/ <blockquote><p> As long as you plan to continue libmaple support for the low end processors</p> </blockquote> <p>Yes, definitely. libmaple support for F1s isn't going anywhere, and in fact should continue to improve.</p> <blockquote><p> The joy of this method would be that it would cross usb classes. I have not tested this on lion but you can talk past the drivers directly to the device up through snow-leopard.</p> </blockquote> <p>Yeah, but it also requires custom USB driver work, which ... yuck. I guess libusb might help on Windows, but it's just not something we can afford to support. </p> http://forums.leaflabs.com/topic.php?id=207&page=4#post-12094 Sat, 28 Jul 2012 13:45:15 +0000 feurig 12094@http://forums.leaflabs.com/ <p>Aslo. I am not sure how you would be hurt by implementing a vendor specific control request in addition to whatever you decide to do here. </p> <p>The joy of this method would be that it would cross usb classes. I have not tested this on lion but you can talk past the drivers directly to the device up through snow-leopard. (sorry about my osx centered viewpoint) This still would require that your device enumerates (though the same code could be used to reset a cdc device or a hid device or ...) </p> <p>I wouldn't solve problems like the double reset issue being experienced elsewhere in the forum. </p> http://forums.leaflabs.com/topic.php?id=207&page=4#post-12080 Fri, 27 Jul 2012 21:24:39 +0000 feurig 12080@http://forums.leaflabs.com/ <p>Mboliver My larger concern about the f4 is the cost/accessibility. The $5 verses the $15 arm. Also my issue with the DUE. What you are working out sounds cool! As long as you plan to continue libmaple support for the low end processors then my complaint is kind of mute. </p> http://forums.leaflabs.com/topic.php?id=207&page=4#post-12069 Fri, 27 Jul 2012 16:23:18 +0000 mbolivar 12069@http://forums.leaflabs.com/ <blockquote><p> Is the assumption that the comms processor and the host-reset-handshake will work perfectly always? Will the comms processor NOT have a "the user wants to upload and maybe something isn't work perfectly" button?</p> </blockquote> <p>If not always, then often enough that the simple expedient of power cycling should solve any remaining problems. Hopefully, that's not too brazen.</p> <p>Point taken, though. The current design has a "comm reset" that we were going to take out, but some perpetual bootloader style thing is a reasonable idea.</p> <blockquote><p> Is this board intended to permanently have the comms processor attached, or is it like a few of the ST and NXPresso boards where the JTAG part can be removed, and the board be embedded in a project?</p> </blockquote> <p>It's permanently attached. The layout is pretty tight, though, and we don't think the size will disappoint. </p> http://forums.leaflabs.com/topic.php?id=207&page=4#post-12068 Fri, 27 Jul 2012 16:16:38 +0000 mbolivar 12068@http://forums.leaflabs.com/ <blockquote><p> The key question is, will those lines appear on header pins, or pads that I can get at?</p> </blockquote> <p>That's not part of the current plan, which is only to have them accessible via software on the F4. This allows for "manual" access by having that software additionally listen to another pin which has already been broken out.</p> <blockquote><p> But, is this comment saying you are not going to make the signals available to the comms processor to upgrade?</p> </blockquote> <p>No. The idea came to us too late in the design to implement. That sort of thing will have to wait for Maple 3 ;).</p> <blockquote><p> That "Black Magic Probe" looks like an excellent piece of work.</p> </blockquote> <p>It is. I've been using them for months, and they work flawlessly. The new editions use the 10-pin JTAG connector, so they'll be perfect for Maple 2. I've corresponded with the developer some as well; he's smart and very responsive. </p>