LeafLabs Garden » Topic: Maple frequency measurement

LeafLabs Garden » Topic: Maple frequency measurement http://forums.leaflabs.com/topic.php?id=1038 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:17:24 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php 9xer on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038&page=2#post-10676 Tue, 15 May 2012 18:10:26 +0000 9xer 10676@http://forums.leaflabs.com/ Links for 32bit resolution. Application Note: <a href="http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00165509.pdf" rel="nofollow">http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00165509.pdf</a> Example code: <a href="http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/an2592.zip" rel="nofollow">http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/an2592.zip</a> 9xer on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038&page=2#post-10671 Tue, 15 May 2012 15:42:37 +0000 9xer 10671@http://forums.leaflabs.com/ First thank you to chris.troutner for uploading his code, it has saved me a good deal of time getting started with my first Maple project. WRT to this code <a href="http://pastebin.com/53rmN4rF" rel="nofollow">http://pastebin.com/53rmN4rF</a> I can give a little back by telling you why you are having the overflow problem. It's because you set value=0; only inside the input capture ISR. If you have no input pulse to capture, and therefore an overflow, the input capture ISR will never trigger and therefore you never set value=0. Move the overflow_flag check to the serial output loop. Also when capturing input durations you should never stop or reset the counter (pretty sure the STM32 is no exception). Leave it alone, just let it run. Currently the input capture ISR zeros the counter. This means your counter reset is offset from the actual transition event by the interrupt latency, and the code inside the ISR. At 100Hz this makes little to no difference on this 72Mhz CPU, but as speeds increase it will become more apparent. The best thing to do is something like this inside your ISR: current = TIMER4_BASE->CCR1; //read the captured value value = current - previous; previous = current; Make sure current and previous are unsigned 16 bit datatypes and everything will take care of itself. Only problem with this approach is you can't use timer overflow events in quite the same way to spot an overflow. And finally you can chain or cascade timers together to give you 32-bit input capture resolution see AN2592 (CD00165509.pdf). Another thought to save this complexity is to use the prescaler like an autoranger, take a quick measurement at an arbitrary prescaler, then adjust the prescaler to better suit the frequency. I dare say you could confuse it with a fast enough moving frequency, but with a thought. gbulmer on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-7402 Mon, 19 Dec 2011 14:45:31 +0000 gbulmer 7402@http://forums.leaflabs.com/ chris.troutner - you might move forward faster by trying to get the pieces working in the easiest configuration first. Specifically using two timers, and then trying to merge both functions onto one timer. Then you could have two easier problems to solve, and when everything works, a working reference case to compare to when you try the merge of timer functionality. Think of it like a program optimisation problem, and take Michael Jacksons advice: "The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet." (<a href="http://en.wikipedia.org/wiki/Program_optimization#Quotes" rel="nofollow">http://en.wikipedia.org/wiki/Program_optimization#Quotes</a>) Having said that, my reading of RM0008 (<a href="http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf" rel="nofollow">http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf</a>) e.g "15.3.2 Counter modes" is "In upcounting mode, the counter counts from 0 to the auto-reload value (content of the TIMx_ARR register), then restarts from 0 and generates a counter overflow event." So there is no need for an extra channel, there is an event generated when the timer counter reaches the value in the reload register. Set the reload value to 65535 (or less if you need it), and the overflow event will signal that there was no input. chris.troutner on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-7401 Mon, 19 Dec 2011 14:20:25 +0000 chris.troutner 7401@http://forums.leaflabs.com/ Good points! And thank you for reviewing my code! I only reset the time value on an input capture. If the input is never captured, the timer should over-flow, which is when I want to generate the overflow/compare interrupt. You may be right that the code is messing up the overflow/compare since I configure it before the capture configuration. This was intentional, and I was wondering the same thing. That bit bang code is from airthimble's code. I didn't want to mess it up, so I didn't change it. I think I just need to go through each bit in the reference manual and figure out if it's messing up my overflow/compare. I was hoping someone might be able to see the problem. Oh well. Otherwise, I think you're right that I'll just have to use another timer. I was hoping to use the same timer, and in theory it should work. Hmm... Cheers! Chris Troutner <a href="http://thesolarpowerexpert.com">thesolarpowerexpert.com</a> poslathian on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-7376 Fri, 16 Dec 2011 17:53:47 +0000 poslathian 7376@http://forums.leaflabs.com/ I know you want to run the input capture and output compare on the same timer, but I wonder if that isnt the issue. I am savvy enough with the timers to say one way or the other or if you need to be clever to do it. I noticed in your code that you reset the timer value on the input capture, perhaps you are never overflowing? I also noticed that you configured the input capture after the output compare via bit-banding. Make sure you arnt smashing the output compare configuration accidentally when writing to the timer registers to setup input compare. Since you are bit-banding you probably dont need to do read-modify writes, but its possible you got one of the vals wrong. Dweller on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-7364 Fri, 16 Dec 2011 15:42:08 +0000 Dweller 7364@http://forums.leaflabs.com/ I did some timer capture stuff over in the thread at <a href="http://forums.leaflabs.com/topic.php?id=1170" rel="nofollow">http://forums.leaflabs.com/topic.php?id=1170</a> where I had DMA moving the data across to an array, where I could process it outside of an interrupt handler.. chris.troutner on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-7351 Wed, 14 Dec 2011 15:21:43 +0000 chris.troutner 7351@http://forums.leaflabs.com/ Hey all, I was able to mash the code in this thread together to get my own frequency measurement going on my Maple (Rev 5). Here is a pastebin of the code for those who would like to use it: <a href="http://pastebin.com/53rmN4rF" rel="nofollow">http://pastebin.com/53rmN4rF</a> Just use a wire to short pins 5 and 7 together. Pin 7 generates the square wave, pin 5 measures it. ----- I need a little help refining this example. The code uses Timer4, channel 1 in Capture mode to measure the time between pulses. However, if I'd like the variable 'value' to get set to zero if Timer4 overflows without measuring a pulse. Without this feature, the old value continues getting displayed when you disconnect the wire because the capture interrupt never fires. I (tried to) set up Timer4, channel 2 in Compare mode with the compare value set to the overflow value. The intention is that I want a second interrupt to fire when Timer4 overflows which sets the variable 'overflow_flag'. I'd really appreciated it if people could review my code and let me know why I can't get the overflow interrupt to fire. In particular, check out this section in setup_timer() where I set up the overflow channel and interrupt: //New code to set overflow timer timer4.setMode(2, TIMER_OUTPUT_COMPARE); //Set this channel to compare timer4.setCompare(2, 65534); //Set the compare for the channel to the overflow vale timer4.attachInterrupt(2, handle_overflow); //Assign the interrupt handler Thanks! Chris Troutner <a href="http://thesolarpowerexpert.com">thesolarpowerexpert.com</a> airthimble on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-6722 Sat, 01 Oct 2011 14:39:05 +0000 airthimble 6722@http://forums.leaflabs.com/ mbolivar, thanks for the quick reply! I should have enough stuff to keep me busy for awhile now :D mbolivar on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-6721 Sat, 01 Oct 2011 13:09:08 +0000 mbolivar 6721@http://forums.leaflabs.com/ <blockquote> On another note does anyone know if libmaple supports using I2C with DMA? </blockquote> I see no reason why dma.h won't support I2C with DMA. The relevant channels are DMA1 channels 6 and 7. See this thread for a nice discussion on using I2C with SPI, including example code: <a href="http://forums.leaflabs.com/topic.php?id=1075" rel="nofollow">http://forums.leaflabs.com/topic.php?id=1075</a> <blockquote> I also have a question with interrupts, how are interrupts "attached"? Does it use one of the External Interrupts? </blockquote> Sometimes, but not always. The enum <code>nvic_irq_num</code> in nvic.h gives all of the possible interrupt vectors on the MCU: <a href="http://leaflabs.com/docs/libmaple/api/nvic.html#project0nvic_8h_1a89e3d57340a69fbdef83f12661543d83" rel="nofollow">http://leaflabs.com/docs/libmaple/api/nvic.html#project0nvic_8h_1a89e3d57340a69fbdef83f12661543d83</a> Some of these have to do with external interrupts; these begin with NVIC_EXTI (so <code>NVIC_EXTI0</code>, <code>NVIC_EXTI_15_10</code>). Interrupt "attaching" is jargon derived from the Wiring project. If you want to attach to a timer interrupt, use <a href="http://leaflabs.com/docs/libmaple/api/timer.html#project0timer_8c_1a022e444b1be2b3a47f598d16b0386f95">timer_attach_interrupt()</a> (or the more restrictive but more user-friendly <a href="http://leaflabs.com/docs/lang/api/hardwaretimer.html#project0class_hardware_timer_1ae1965408f7b2ed72eaf37f35590a1e36">HardwareTimer::attachInterrupt()</a>). To attach to an external interrupt (EXTI), just use <a href="http://leaflabs.com/docs/lang/api/attachinterrupt.html">attachInterrupt()</a>. <code>--------------------------------------------------</code> I've been meaning to write more about this for the documentation, so here's a sketch of how this all works (note: this omits certain details, but hopefully gets the important points across). Definitely optional reading, but you may find it interesting. On the Cortex M3, there's a table of pointers to the functions you want to use as interrupt handlers. This is called the vector table; its address in memory is the value of the register SCB_VTOR (accessible in libmaple as <code>SCB_BASE->VTOR</code>). When an interrupt occurs, the MCU looks up the corresponding handler function from the vector table. It then proceeds to save the current context by stacking registers and doing some other stuff, then jumps to the handler. When the interrupt is done, this context saving gets undone and you go back to user code. (The truth is a little bit more complicated because interrupts can nest, but that's the basic idea). Part of what the libmaple startup sequence does is set up the vector table so that the addresses of our handler functions (whose names all begin with "__irq"; see libmaple's support/ld/names.inc for a list of all the names) get stored in the appropriate places in the vector table. When you call one of the various <code>attachInterrupt()</code> or <code>foo_attach_interrupt()</code> functions, it doesn't replace the vector table entry. Instead, what happens is that a pointer to your function is stored in a secondary table of functions (this secondary table being part of libmaple), and when the interrupt occurs, the corresponding <code></code>__irq_foo()<code></code> calls your function after looking it up in libmaple's table. An example of such a secondary table is the array <code>exti_channels</code> in exti.c, libmaple v0.0.12: <a href="https://github.com/leaflabs/libmaple/blob/v0.0.12/libmaple/exti.c#L49" rel="nofollow">https://github.com/leaflabs/libmaple/blob/v0.0.12/libmaple/exti.c#L49</a> The <code>handler</code> fields in the elements of <code>exti_channels</code> are what hold the functions you pass to <code>attachInterrupt()</code>. To see this in action, you can connect the dots between the source code for <a href="https://github.com/leaflabs/libmaple/blob/v0.0.12/libmaple/exti.c#L142">__irq_exti0()</a> and <a href="https://github.com/leaflabs/libmaple/blob/v0.0.12/wirish/ext_interrupts.cpp#L47">attachInterrupt()</a>. This may seem complicated, and it does add some overhead, but the result is more user friendly. For instance, a lot of interrupts get multiplexed into a single interrupt vector. E.g., there's a single <code>__irq_tim1_cc()</code> that has to handle all 4 channel capture/compare interrupts for timer 1. <code>timer_attach_interrupt()</code> hides this complexity from you, so that you can pretend like there's a single interrupt for each of those channels. Further, serving an interrupt is usually more complicated than just providing a function that serves your application's purpose when the interrupt occurs. Often, there are peripheral registers which you have to massage each time the interrupt happens in order to keep things working. External interrupt handlers need to clear pending masks in EXTI_PR. DMA interrupt handlers need to clear DMA_ISR bits. Timer interrupts need to clear TIMx_SR bits, etc. etc. In each case, the libmaple <code>__irq_foo()</code> function handles this for you behind the scenes. We think this increase in usability is worth the performance penalty. You may disagree. If so, you can use <a href="http://leaflabs.com/docs/libmaple/api/nvic.html#project0nvic_8c_1ab78786ff3387dfaf3d9aeb017a111197">nvic_set_vector_table()</a> to set up your own vector table. If you do, you're on your own ;). HTH! edits: examples, clarifications airthimble on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-6720 Sat, 01 Oct 2011 11:30:14 +0000 airthimble 6720@http://forums.leaflabs.com/ Here is the solution I came up with last night, it has a function to set things up and then the interrupt routine. I am not sure what all is implemented in libmaple, I noticed that there were some "TODO" in the comments of timer.h so I set some registers myself and used a few timer convenience functions, the comments should explain what is going on: <pre><code>void testSetup() { pinMode(5, INPUT_PULLDOWN); TIMER4_BASE->CCMR1 = 0x00F1; //channel 1 configure as input, IC1 mapped on TI1 TIMER4_BASE->CCMR2 = 0x0000; //channels 3&4 disabled TIMER4_BASE->CCER = 0x0001; //configure channel 1 as an input TIMER4_BASE->SMCR = 0x0000; //all slave modes disabled, CC transitions on clock TIMER4_BASE->CR1 = 0x0001; //enable the counter TIMER4_BASE->CR2 = 0x0000; //connect TIM4_CH1 pin to TI1 input TIMER4_BASE->PSC = 0x00FF; //set a random large prescalar just for testing timer_attach_interrupt(TIMER4, TIMER_CC1_INTERRUPT, __measurePulse_irq); timer_resume(TIMER4); } void __measurePulse_irq() { //get the bit to see if this is an up or down pulse polarity = TIMER4_BASE->CCER & 0x0002; if(polarity == 0) //this is a rising edge capture { timer_set_count(TIMER4, 0x000); //zero the counter temp = TIMER4_BASE->CCR1; //clear the interrupt by reading CCR1 value TIMER4_BASE->CCER |= 0x0002; //change polarity to capture falling edge } else //this is a falling edge capture { value = TIMER4_BASE->CCR1; //read the captured value TIMER4_BASE->CCER &= ~0x0002; //change polarity to capture rising edge timer_set_count(TIMER4, 0x0000); //zero the counter } }</code></pre> To test this code I created this test loop in main, then wired pin7 to pin5: <pre><code>int main() { pinMode(7, OUTPUT); newTest(); while(1) { delay(500); SerialUSB.println(value); count++; digitalWrite(7, HIGH); delay(count); digitalWrite(7, LOW); } }</code></pre> Hopefully someone may find this code useful, I will post a second version when I get it cleaned up and adjusted later today. On another note does anyone know if libmaple supports using I2C with DMA? I also have a question with interrupts, how are interrupts "attached"? Does it use one of the External Interrupts? I noticed there seems to be interrupt vectors defined in nvic.c/h, timer.c/h and exti.c/h, I would like to take advantage of some of these. Would someone be willing to type up a quick explanation of what I need to do to use some of these? gbulmer on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-6714 Fri, 30 Sep 2011 20:42:51 +0000 gbulmer 6714@http://forums.leaflabs.com/ Okay, 5us to 20ms is a dynamic range of 4,000, and the timer is only 16 bits, so only about 4000/65,536= 1/16th, or 4 bits precision If that is enough precision it should be straightforward If it isn't, it is possible to 'chain' timers to construct a 32bit count, in which case, you might get to 72MHz clock frequency, or about 1/280th, better than 1% :-) I've done this on Arduino and the fundamental mechanism looks the same, though the registers are different. you could work up to this in a few steps: 1. Poll the pin with digitalRead() and use micros() to measure time 2. set a timer to the right frequency (about 4MHz, a "prescaler" of 8) to get to the right count frequency (for a 16 bit count), use that count as the time base, and read it at edges. See <a href="http://leaflabs.com/docs/libmaple/api/timer.html#count-and-prescaler" rel="nofollow">http://leaflabs.com/docs/libmaple/api/timer.html#count-and-prescaler</a> 3. reset the counter to zero when you poll the start edgeand read the count when you see the finish edge 4. poll the pin directly & read the timer - use the pin map to convert from the pin number to the actual 16-bit port and pin within port, read the input data register (RM0008 section 9.2.3 "Port input data register (GPIOx_IDR) (x=A..G)") to poll the pin e.g. <code>while (GPIOB_IDR&(BIT(6))) {} // wait for port B pin 6 to clear</code> This is only more precise in that there is a smaller window for an interrupt to hit (as digitalRead should be deterministic) 5. Set the timer to capture signal change itself see <a href="http://leaflabs.com/docs/libmaple/api/timer.html#capture-compare" rel="nofollow">http://leaflabs.com/docs/libmaple/api/timer.html#capture-compare</a> initially poll the timer to see if it has 'captured' i,e, timed a change 6. Get the captured count it with interrupts!-) HTH airthimble on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-6713 Fri, 30 Sep 2011 17:11:16 +0000 airthimble 6713@http://forums.leaflabs.com/ I wasn't able to find anything besides this post on the forum regarding input capture. I was planning on doing an input capture to measure a digital signal of 5us to 20ms in length. If have time to get it working this weekend I will post my code. gbulmer on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-6388 Sun, 18 Sep 2011 19:20:11 +0000 gbulmer 6388@http://forums.leaflabs.com/ house91320 - most of the timers have 'input capture' pins. The timer can be configured to count, then when an input capture pin is triggered by a signal edge, the timer count is copied into a 'capture register', and an interrupt triggered. The interrupt service routine can pick up the value stored in the capture register, and that is a measure of duration. The resolution of a single timer is 16 bits, which is far from the range needed for 100Hz to 8MHz. If you can have several attempts at the same signal, you could try to adjust the frequency the timer counts (the prescaler) so that it can be captured in 16 bits. That might not be an option. It is possible to 'chain' timers together, if you want to think of one timer's counter reaching the maximum value, and the 'carry' from that timerdriving a second timer counter, effectively giving you a 32-bit counter. The timer can only count at the 72MHz clock frequency, and the sampling of the input signal will effectively be rounded to the nearest clock edge. So an 8MHz signal is only going to register as, roughly a count of 12 (depending on exactly when the edge happens), with an error of almost 10%. If the signal is fast, but repetitive, the signal from the input capture trigger can be divided, say by 16, so the counter value captured in the time for 16 cycles of the input signal, averaging the duration, and hence giving a bit more resolution (though the same absolute error). Have a look at the RM0008 manual, for example section 15.3.5 "Input capture mode" and see if it makes sense. Some of the existing library can be used to set the timer up for counting, but I think you will have to get down to the hardware level, to set up some of the modes, and to get at the capture register. I haven't written code to do this, but it looks quite doable. (full disclosure: I am not a member of LeafLabs staff) house91320 on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-6376 Sat, 17 Sep 2011 00:24:42 +0000 house91320 6376@http://forums.leaflabs.com/ Any code ideas? house91320 on "Maple frequency measurement" http://forums.leaflabs.com/topic.php?id=1038#post-6365 Thu, 15 Sep 2011 21:29:52 +0000 house91320 6365@http://forums.leaflabs.com/ Its digital at 100hz to 8mhz, ideally it would be as accurate as possible.