http://forums.leaflabs.com/topic.php?id=938 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:00:54 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=938#post-105763 Thu, 23 Jul 2015 17:10:49 +0000 rogerclark 105763@http://forums.leaflabs.com/ <p>It seems unlikely that you need to change the bootloader, as it is unloaded when the sketch runs.</p> <p>As the last posting to this thread was 3 years ago, I'd suggest you post to <a href="http://www.stm32duino.com" rel="nofollow">http://www.stm32duino.com</a> as its more active than this forum, and uses a derivative of libmaple </p> http://forums.leaflabs.com/topic.php?id=938#post-105739 Mon, 25 May 2015 06:08:45 +0000 josemaes 105739@http://forums.leaflabs.com/ <p>Hi mbolivar,</p> <p>do I need to recompile the bootloader to apply the patch? </p> http://forums.leaflabs.com/topic.php?id=938#post-5880 Wed, 03 Aug 2011 23:12:55 +0000 anton 5880@http://forums.leaflabs.com/ <p>Happy to hear. I had the same problem. </p> http://forums.leaflabs.com/topic.php?id=938#post-5878 Wed, 03 Aug 2011 22:13:56 +0000 ridgebackred 5878@http://forums.leaflabs.com/ <p>mbolivar,</p> <p>Yes, that update of exti.c fixed the multiplexed EXTI IRQ issue for me!</p> <p>The pulse duration of all six channels of the RC receiver are now captured correctly using the external interrupt capability of the Maple Mini.</p> <p>Thanks! </p> http://forums.leaflabs.com/topic.php?id=938#post-5876 Wed, 03 Aug 2011 18:04:55 +0000 ridgebackred 5876@http://forums.leaflabs.com/ <p>Thanks mbolivar!</p> <p>The Maple Mini: $34.99</p> <p>Having LeafLabs expertise brought to bear on an issue: Priceless </p> http://forums.leaflabs.com/topic.php?id=938#post-5874 Wed, 03 Aug 2011 16:49:38 +0000 mbolivar 5874@http://forums.leaflabs.com/ <p>OK, I've pushed what should be a fix; see this bugtracker comment for more details:</p> <p><a href="http://code.google.com/p/leaflabs/issues/detail?id=77#c2" rel="nofollow">http://code.google.com/p/leaflabs/issues/detail?id=77#c2</a></p> <p>Let me know if it resolves the issue on your tricopter/quadcopter.</p> <p>The fix went in as part of the following series of commits (now merged into master), which should also bring some other bugfixes and performance improvements to exti.c:</p> <p>c0750411002ce61a0df96aefd385106c2fc2b509 exti.c: Optimize multiplexed IRQ handlers.<br /> 487a60946d89f340982e4435d7ededaea1a09468 exti.c: Cleanups.<br /> aee5bceb0f773826627543199de4332b2e36ba4a exti.c: Remove enable_irq() and maybe_disable_irq().<br /> 5a7ad93ab24cac998cc498aadb7e32cc29b836de exti.c: Clean up some bit-banding usages.<br /> f5935ef4778aa081c7a22e1d3bfd0aadc7a213e2 exti.c: Cleanups.</p> <p>If you notice any other improvements or regressions, we'd love some feedback.</p> <p>Edit: Here's the compare view on those commits:</p> <p><a href="https://github.com/leaflabs/libmaple/compare/dab7dd44...c075041" rel="nofollow">https://github.com/leaflabs/libmaple/compare/dab7dd44...c075041</a> </p> http://forums.leaflabs.com/topic.php?id=938#post-5873 Wed, 03 Aug 2011 16:30:17 +0000 mbolivar 5873@http://forums.leaflabs.com/ <p>I have reproduced the issue. IRQs that are shared between several EXTI lines do appear to get dropped on the floor if a non-multiplexed EXTI IRQ is triggered at the same time.</p> <p>Since I don't have access to your sensors, I've added a new (non-portable and Maple Mini specific, ATM) test of external interrupts which only requires wires:</p> <p><a href="https://github.com/leaflabs/libmaple/blob/master/examples/mini-exti-test.cpp" rel="nofollow">https://github.com/leaflabs/libmaple/blob/master/examples/mini-exti-test.cpp</a></p> <p>See the file header for a way to wire it up.</p> <p>Bugtracker reference, with expected and actual output:</p> <p><a href="http://code.google.com/p/leaflabs/issues/detail?id=77" rel="nofollow">http://code.google.com/p/leaflabs/issues/detail?id=77</a></p> <p>I'll try to sort out what's going on. </p> http://forums.leaflabs.com/topic.php?id=938#post-5861 Tue, 02 Aug 2011 22:07:30 +0000 ridgebackred 5861@http://forums.leaflabs.com/ <p>mbolivar,</p> <p>I have 2 MapleMini's flying in my tricopter and quadcopter since the MapleMini's went on sale. Lots of fun! The MapleMini's are great controllers. I had my doubts about using high clock speed controllers in an environment as electrically noisy as RC models. The MapleMini's are holding up very well in a demanding application.</p> <p>Four RC channels are all that is required for basic flying.<br /> Additional channels are for mode selection and trying out new control schemes in flight.</p> <p>My "real-time" debug method is limited to blinking the led from different parts of the code, and looking at the led output with an o-scope.</p> <p>It seems like a AFIO_EXTI_5 handler and higher is being blocked by something.<br /> I have eliminated the RX signal itself as the cause by switching RX channels 4 and 5 of the receiver to the MapleMini inputs. The 'missed/late interrupt' stays with EXTI 5 (and higher) pin(s).</p> <p>Interrupt capture is rock solid for EXTI 0 through 4.</p> <p>A functional program is at: <a href="http://snipt.net/ridgebackred/mapleminiquad0002apde" rel="nofollow">http://snipt.net/ridgebackred/mapleminiquad0002apde</a></p> <p>A photo about half way down the page of the MapleMini.<br /> <a href="http://aeroquad.com/showthread.php?3614-3D-printed-motor-mounts-for-aluminum-airfoil-arms/page3" rel="nofollow">http://aeroquad.com/showthread.php?3614-3D-printed-motor-mounts-for-aluminum-airfoil-arms/page3</a> </p> http://forums.leaflabs.com/topic.php?id=938#post-5850 Tue, 02 Aug 2011 15:14:38 +0000 mbolivar 5850@http://forums.leaflabs.com/ <p>ridgebackred,</p> <p>can we see your entire program, or get some more details on what you mean by the following:</p> <blockquote><p> Inputs AFIO_EXTI_5 and above all seem to drop to a lower interrupt priority. Interrupt servicing for the multiplexed handlers is not consistent. </p></blockquote> http://forums.leaflabs.com/topic.php?id=938#post-5792 Fri, 29 Jul 2011 12:10:48 +0000 ridgebackred 5792@http://forums.leaflabs.com/ <p>Thanks robodude666,</p> <p>This is the code snip. It's repeated for each handler. Unless the micros() function is taking much longer than I realize, I should be in-n-out of the handlers plenty fast enough not to miss any.</p> <pre><code>void handler_CH1(void) { // Measure RX Pitch duration if(Chan1begin == 0){ // Rising edge interrupt signal Chan1begin = micros(); Chan1prev = RxInPitch; } else{ // Falling edge interrupt signal Chan1end = micros(); RxInPitch = Chan1end - Chan1begin; if((RxInPitch &lt; 1000) || (RxInPitch &gt; 2000)) //Glitch suppression {RxInPitch = Chan1prev; Chan1end = 0;} RxInPitchSmooth =(RxInPitchSmooth + RxInPitch) / 2; Chan1begin = 0; } }</code></pre> http://forums.leaflabs.com/topic.php?id=938#post-5791 Fri, 29 Jul 2011 11:33:45 +0000 robodude666 5791@http://forums.leaflabs.com/ <p>There may be two explanations for this:</p> <p>1) All interrupts are configured for the lowest possible priority. If you adjust the priority of 0 - 4, they <em>will</em> operate at a higher priority level.</p> <p>2) EXTI 0 through 4 have their own irq line. 5-9 and 10-15 respectively share the same IRQ line and interrupt handlers.</p> <p>If an interrupt for 5 through 9 is received, it goes through more code to determine which of the five interrupts could have been triggered. This takes more time and creates a delay.</p> <p>You can view the <a href="https://github.com/leaflabs/libmaple/blob/master/libmaple/exti.c">libmaple/exti.c</a> file yourself to see how the implementation actually works to understand where these delays come from. This implementation is based on STM's design, and not some weird setup LeafLabs decided on.</p> <p>-robodude666 </p> http://forums.leaflabs.com/topic.php?id=938#post-5790 Fri, 29 Jul 2011 11:20:53 +0000 ridgebackred 5790@http://forums.leaflabs.com/ <p>I hesitate to call this a bug, but I am seeing repeatable results when staying in the userspace code area...</p> <p>My setup is a six channel RC receiver with the outputs connected to the MapleMini.</p> <p>All inputs to the MapleMini are used as external interrupts. Care has been taken not to violate the multiplexed interrupt pin assignment rules.</p> <p>AFIO_EXTI_0 through AFIO_EXTI_4 work fine.<br /> Inputs AFIO_EXTI_5 and above all seem to drop to a lower interrupt priority. Interrupt servicing for the multiplexed handlers is not consistent.</p> <p>Ideas? </p>