3
Vote

Timer Hardware Interrupts

description

I hit a stone wall when evaluating .NETMF on a STM32F4xx when, to my total surprise, it became clear that you could not configure the device hardware timers and related interrupt service routine using .NETMF.

The hardware vendor selling the module is blaming .NETMF.

I found this a bit hard to believe, but.. well maybe. Their tinyclr, or .netmf, one of the two, is absolutely constructing ISRs for everything from SPI and UART, to cameras and Ethernet. Why not the 17 built in interrupt timers that the ST datasheet is boasting?

I'm not versed on Arduino, but in a single Bing search I found a "how to configure hardware timers instructional video". So its not impossible for a C# based OS layer to do this.

If I can't use the most basic chip features, then I really cant use .NETMF? Is that true? What's the story?

Thanks. (and I'm not angry.. I'm just hoping that SOL is not the answer, because I love using VS for embedded, and would hate to dump it over something trivial like this.)

comments

Maverick_sky wrote Oct 6, 2013 at 8:54 PM

Hello everybody,
I'm also surprised that is impossible to use built in timers/counters. Is somebody know why?

Mike.

wedge905 wrote Jun 9 at 1:59 AM

This is a very standard and basic microcontroller feature. It really does need to be included in the framework

JanKucera wrote Jun 9 at 9:34 AM

First, the vendor is absolutely free to update the part of MF they are blaming if they feel the feature is that important. Other vendors were enabling features not supported by MF since beginning of the platform.

However, given the non-realtime nature of MF, there is no guarantee about the delay between the hardware interrupt timer fires and your code being executed. What would be the desired scenario under these conditions?

cw wrote Jun 9 at 11:24 AM

Another thing to consider is the execution time of interpreted managed code - for "fast" hardware timers/counters there is simply not enough time for any reasonable processing to be done in managed code. The existing ISR mechanism uses asynchronous handlers (events), "slow" managed handler for a "fast" hardware/time counter will work only until the interrupt queue fills up.

As Jan mentioned above, it depends on what exactly you want to achieve (?)

In certain scenarios, like PWM/frequency measurements, pulse counting etc. it is much easier to implement native driver and provide managed wrapper for configuration and results, for other things the built-it timer mechanism can be used, perhaps with changed system clock speed...

wedge905 wrote Jun 9 at 5:54 PM

I can't speak for others, but in my case I don't need realtime functionality. As long as the delays are not too huge, and no pulses get missed, that's good enough for me.
I'll admit I'm new to all this, so I'm sure there's better ways to achieve this that I'm not aware of. I currently have a counter implemented in software, that uses a gpio interrupt that simply increments a value. But I'm worried about how much cpu time that will consume as the frequency rises. I assumed a hardware counter would accomplish the same thing significantly more efficiently, and would support much greater frequencies.
Currently, I estimate the peak frequency I need to be able to count is between 800 - 1000 Hz. For context, my application is measuring distance travelled and calculating the current, average and max speed of a moving vehicle. It will actually be doing more than that, but that is the core functionality.