http://forums.leaflabs.com/topic.php?id=1912 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:06:08 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=1912&page=2#post-26447 Mon, 03 Jun 2013 22:52:13 +0000 newyorkbrass 26447@http://forums.leaflabs.com/ <p>Is this going to be merged into main line? </p> http://forums.leaflabs.com/topic.php?id=1912&page=2#post-13075 Sun, 02 Sep 2012 00:15:01 +0000 mbolivar 13075@http://forums.leaflabs.com/ <blockquote><p> What about adding an 'adc_irq_cause' function instead of passing the 'irq_flags' in the 'adc_callback_data' struct? This would make it more inline with the DMA IRQ framework.</p> </blockquote> <p>As far as I'm concerned, dma_get_irq_cause() is broken, and there's no good way to fix it. See this thread for why:</p> <p><a href="http://forums.leaflabs.com/topic.php?id=2624" rel="nofollow">http://forums.leaflabs.com/topic.php?id=2624</a></p> <p>Providing all the bits is more confusing at first, but it's the only way to avoid the kind of confusion that hacks like dma_get_irq_cause() will cause when you stress the implementation.</p> <blockquote><p> What is the usage scenario for the 'arg' argument in the 'adc_callback_data' struct?<br /> Most|all other interrupt handlers in libmaple have no attached user data.</p> </blockquote> <p>I think this is a deficiency. We're trying to backwards-compatibly add user data to callbacks in other areas as well; see this pull request for external interrupts for another example and usage scenario:</p> <p><a href="https://github.com/leaflabs/libmaple/pull/53" rel="nofollow">https://github.com/leaflabs/libmaple/pull/53</a> </p> http://forums.leaflabs.com/topic.php?id=1912&page=2#post-13041 Sat, 01 Sep 2012 04:06:52 +0000 ventosus 13041@http://forums.leaflabs.com/ <p>This is awesome!</p> <p>Just one thing I'm curious about, is the 'adc_callback_data' struct needed?</p> <p>What about adding an 'adc_irq_cause' function instead of passing the 'irq_flags' in the 'adc_callback_data' struct? This would make it more inline with the DMA IRQ framework.</p> <p>What is the usage scenario for the 'arg' argument in the 'adc_callback_data' struct?<br /> Most|all other interrupt handlers in libmaple have no attached user data. </p> http://forums.leaflabs.com/topic.php?id=1912#post-13006 Thu, 30 Aug 2012 15:01:20 +0000 mbolivar 13006@http://forums.leaflabs.com/ <p>OK, I've got some patches in a branch on my libmaple tree:</p> <p><a href="https://github.com/mbolivar/libmaple/tree/adc-api-expansion" rel="nofollow">https://github.com/mbolivar/libmaple/tree/adc-api-expansion</a></p> <p>They provide adc_attach_interrupt() and a variety of other convenience functions to make using it easier.</p> <p>Here is an example program which shows how it all fits together:</p> <p><a href="https://github.com/mbolivar/libmaple/blob/adc-api-expansion/examples/adc-low-level-interrupts.cpp" rel="nofollow">https://github.com/mbolivar/libmaple/blob/adc-api-expansion/examples/adc-low-level-interrupts.cpp</a></p> <p>The example shows how to start with a pin number, and end up with an interrupt that calls your handler each time ADC conversion on that pin finishes. You can try it out from libmaple like this (WARNING, this will delete any main.cpp you have):</p> <pre><code>$ git remote add -f mbolivar git://github.com/mbolivar/libmaple.git $ git checkout mbolivar/adc-api-expansion $ rm main.cpp $ ln -s examples/adc-low-level-interrupts.cpp main.cpp $ make clean; make install</code></pre> <p>Any comments about the new API or the example code are very welcome. Here are the most important new functions:</p> <p>- <a href="https://github.com/mbolivar/libmaple/blob/adc-api-expansion/libmaple/adc.c#L145">adc_set_conv_seq()</a><br /> - <a href="https://github.com/mbolivar/libmaple/blob/adc-api-expansion/libmaple/adc.c#L201">adc_attach_interrupt()</a><br /> - <a href="https://github.com/mbolivar/libmaple/blob/adc-api-expansion/libmaple/include/libmaple/adc.h#L354">adc_start_conv()</a><br /> - <a href="https://github.com/mbolivar/libmaple/blob/adc-api-expansion/libmaple/include/libmaple/adc.h#L395">adc_get_data()</a></p> <p>Some important new types, which you use in your interrupt handlers, are:</p> <p>- <a href="https://github.com/mbolivar/libmaple/blob/adc-api-expansion/libmaple/include/libmaple/adc.h#L418">enum adc_interrupt_id</a><br /> - <a href="https://github.com/mbolivar/libmaple/blob/adc-api-expansion/libmaple/include/libmaple/adc.h#L462">struct adc_callback_data</a></p> <p>Barring any feedback which implies changes, I'll polish this up and merge it into master. </p> http://forums.leaflabs.com/topic.php?id=1912#post-12818 Thu, 23 Aug 2012 00:33:14 +0000 mbolivar 12818@http://forums.leaflabs.com/ <p>I've prepared a document explaining how interrupt handling in libmaple works:</p> <p><a href="https://github.com/leaflabs/libmaple/blob/master/notes/interrupts.txt" rel="nofollow">https://github.com/leaflabs/libmaple/blob/master/notes/interrupts.txt</a></p> <p>It's mostly useful as a developers' doc, but it attempts to archive a lot of the information discussed in this thread.</p> <p>As it definitely meets the "generally useful" criterion, I'll try to get around to adding <code>adc_attach_interrupt()</code> (and something like a non-blocking <code>adc_start_conversion(adc_dev* dev, int channel)</code> to make it more useful) this week.</p> <p>As you can see from the document, doing QA on foo_attach_interrupt() routines can be nontrivial given the variety of STM32s libmaple supports, so hopefully you'll forgive us for not having done it sooner. We don't mean to be an unfriendly "zomg RTFS N00b!"-style forum, and I do try to help, but we've got limited resources to devote to Maple, so these things can take a little while sometimes. </p> http://forums.leaflabs.com/topic.php?id=1912#post-12696 Sun, 19 Aug 2012 09:53:45 +0000 ventosus 12696@http://forums.leaflabs.com/ <p>@davies46, that's because the IDE uses Wiring which is a subset of C++ iirc, and therefore does not support all valid C++ syntax. When using the code from within the unix toolchain, both syntax are valid and give the same object code.</p> <p>Is your code shareable? It'd be nice to have a look at it... </p> http://forums.leaflabs.com/topic.php?id=1912#post-12463 Thu, 16 Aug 2012 02:55:32 +0000 davies46 12463@http://forums.leaflabs.com/ <p>FWIW, building under the Maple IDE v0.0.12 I got my adc interrupt called when I changed the syntax slightly to:<br /> <pre><code>extern &quot;C&quot; { void __irq_adc(void) { conversionInterrupts++; ADC2-&gt;regs-&gt;SR = 0; } }</code></pre> <p>since<br /> <code>extern &quot;C&quot; void __irq_adc(void) {/* Your ADC handler goes here */}</code><br /> doesn't compile on that setup. </p> http://forums.leaflabs.com/topic.php?id=1912#post-12145 Wed, 01 Aug 2012 11:02:20 +0000 ventosus 12145@http://forums.leaflabs.com/ <p>thanks, but I've got the ADC DMA interrupt up and running in DUAL ADC SCAN mode, but I'd like to use an ADC interrupt, too, besides the DMA interrupt.</p> <p>consider the following setup:</p> <p>144 sensors -&gt; 9x 16:1 channel multiplexer -&gt; maple mini</p> <p>So far I use a timer and in its interrupt I switch the mux channel and start a new ADC conversion burst. DMA is setup once at startup in circular mode and fires its interrupt after all 160 conversions (1 ADC channel is converted twice because dual adc mode requires an even number of channels).</p> <p>This works fine for running things at fixed rates, but I'd like be able to run this as fast as possible. Simply replacing the timer interrupt with the ADC interrupt would just be the simplest change and I could even switch easily between the two modes (fixed-rate vs. as-fast-as-you-can).</p> <p>Alternatively I'll try this now:</p> <p>Set up DMA in non-circular mode and let it fire after each ADC burst (10 conversions), switch the muxes and start the next conversion. And then reset the DMA destination address after all the 160 conversions. For this I won't need an ADC interrupt. </p> http://forums.leaflabs.com/topic.php?id=1912#post-12135 Tue, 31 Jul 2012 16:44:13 +0000 mbolivar 12135@http://forums.leaflabs.com/ <p>I don't, but I think I have some old code somewhere of ADC firing DMA interrupts. If you can afford the latency hit, maybe it's still useful to you? I can try to dig it up if so. </p> http://forums.leaflabs.com/topic.php?id=1912#post-12091 Sat, 28 Jul 2012 11:04:09 +0000 ventosus 12091@http://forums.leaflabs.com/ <p>Has anybody some working code with an ADC interrupt that could be shared? </p> http://forums.leaflabs.com/topic.php?id=1912#post-11340 Thu, 21 Jun 2012 15:36:46 +0000 ventosus 11340@http://forums.leaflabs.com/ <p>Thanks for the detailed explanation, this was exactly what I was looking for. Sadly my handler is linked in correctly, so the problem sits somewhere else :-( </p> http://forums.leaflabs.com/topic.php?id=1912#post-11339 Thu, 21 Jun 2012 12:51:08 +0000 mbolivar 11339@http://forums.leaflabs.com/ <blockquote><p> Is there a way to check in the produced binary, whether my function was linked in correctly and will be called instead of the __default_handler?</p> </blockquote> <p>(I assume you're not using a JTAG or SWD debugger)</p> <p>One way is to check the vector table in the disassembly file (in build/&lt;your_board&gt;.disas using libmaple from Git). In libmaple, the vector table symbol is <code>__stm32_vector_table</code>; it should be the first symbol in the text section (and hence will be at the top of the file). Look up the ADC handler address in the vector table, and make sure it's the address of <code>__irq_adc</code> (which you can also look up in the disassembly).</p> <p>Here's a worked example.</p> <p>This is the vector table from a disassembled program with __irq_adc() defined:</p> <pre><code>08000000 &lt;__stm32_vector_table&gt;: 8000000: 00 50 00 20 1d 23 00 08 71 08 00 08 75 08 00 08 .P. .#..q...u... 8000010: 79 08 00 08 7d 08 00 08 81 08 00 08 d7 1a 00 08 y...}........... 8000020: d7 1a 00 08 d7 1a 00 08 d7 1a 00 08 d7 1a 00 08 ................ 8000030: d7 1a 00 08 d7 1a 00 08 d7 1a 00 08 09 04 00 08 ................ 8000040: d7 1a 00 08 d7 1a 00 08 d7 1a 00 08 d7 1a 00 08 ................ 8000050: d7 1a 00 08 d7 1a 00 08 8d 01 00 08 ad 01 00 08 ................ 8000060: cd 01 00 08 ed 01 00 08 0d 02 00 08 59 1d 00 08 ............Y... 8000070: 79 1d 00 08 99 1d 00 08 b9 1d 00 08 d9 1d 00 08 y............... 8000080: f9 1d 00 08 19 1e 00 08 1d 01 00 08 d7 1a 00 08 ................ 8000090: 29 0a 00 08 d7 1a 00 08 d7 1a 00 08 2d 02 00 08 )...........-... 80000a0: c5 1f 00 08 f1 1f 00 08 1d 20 00 08 59 20 00 08 ......... ..Y .. 80000b0: b5 20 00 08 31 21 00 08 ad 21 00 08 cd 1e 00 08 . ..1!...!...... 80000c0: e5 1e 00 08 d9 1e 00 08 f1 1e 00 08 d7 1a 00 08 ................ 80000d0: d7 1a 00 08 e1 22 00 08 f5 22 00 08 09 23 00 08 .....&quot;...&quot;...#.. 80000e0: 65 02 00 08 d7 1a 00 08 d7 1a 00 08 e...........</code></pre> <p>This contains:</p> <p>1. The initial stack pointer,<br /> 2. The addresses of the interrupt handlers, in the order specified by Table 63 in RM0008. (Starting with the reset vector, then NMI, etc.)</p> <p>Each entry is 4 bytes long. The byte-order is little-endian. The first entry in the above example (the initial stack pointer value) is thus 0x20005000, and the reset vector is at address 0x0800231d. Note that the last bit in the reset vector address is set. This is the "thumb bit"; it's an ARM feature meaning that the address to be branched to contains thumb-2 (mixed 16- and 32-bit) instructions instead of 32-bit only (this is fine since instructions want 2 or 4 byte alignment). The actual address of the reset vector is thus 0x0800231c.</p> <p>__irq_adc() is at offset 0x88 from the start of __stm32_vector_table, so in this example, the corresponding value is 0x0800011d. Masking out the thumb bit, the ADC handler address is 0x0800011c. And sure enough, when I search the disassembly file for "__irq_adc", this turns up:</p> <pre><code>0800011c &lt;__irq_adc&gt;: 800011c: 4770 bx lr</code></pre> <p>(My handler is a trivial one that returns immediately, so it just contains a standard "return to caller" <code>bx lr</code> instruction). </p> http://forums.leaflabs.com/topic.php?id=1912#post-11338 Thu, 21 Jun 2012 09:28:11 +0000 ventosus 11338@http://forums.leaflabs.com/ <p>I have the feeling that my custom __irq_adc function does not properly replace the weak definition and then libmaple calls the __default_handler which is an infinite loop as I've read in the documentation somewhere.</p> <p>Is there a way to check in the produced binary, whether my function was linked in correctly and will be called instead of the __default_handler? </p> http://forums.leaflabs.com/topic.php?id=1912#post-11300 Sun, 17 Jun 2012 04:11:53 +0000 ventosus 11300@http://forums.leaflabs.com/ <p>Here my non-working code</p> <p><a href="http://pastebin.com/vCzwm2F6" rel="nofollow">http://pastebin.com/vCzwm2F6</a> </p> http://forums.leaflabs.com/topic.php?id=1912#post-11297 Sat, 16 Jun 2012 12:56:43 +0000 ventosus 11297@http://forums.leaflabs.com/ <p>correction: the maple_mini hangs only when actually starting a conversion when both the NVIC_ADC_1_2 and the ADC_CR1_EOCIE are set, no matter whether a custom __irq_adc function was defined or not... </p>