Timer Hardware Interrupts


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.)


Maverick_sky wrote Oct 6, 2013 at 9:54 PM

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


wrote Jun 9, 2014 at 2:56 AM

wedge905 wrote Jun 9, 2014 at 2: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, 2014 at 10: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, 2014 at 12:24 PM

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, 2014 at 6: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.

wrote Oct 28, 2014 at 11:38 PM

Alex111 wrote Jan 17 at 1:26 PM

I also would like to see native interrupts forwarded to NEtMF... Maybe NetMF is too slow for the moment. But I'm still hoping to get AOT or JIT. Microsoft has already such a technology called ".NET Native"..

wedge905 wrote Feb 2 at 8:51 PM

I've got a much better understanding of how netmf works than I did back in June.
Now, what I think is really needed is a Hardware Timer base class or interface. This would provide an abstraction layer that can be tied into when netmf is ported, and a common usage for end users such as us. Just like how other hardware features are implemented like SPI, I2C, etc.
This would be far better than each vendor doing their own implementation. And when I say better, I mean it would be much more consistent and easier for end users such as us. Although admittedly it may limit the full extent of features of each chip from being exposed (But that's par for the course).
I think it would also be much more likely that a vendor would implement this. Since there would be existing hooks they can tie into. As opposed to creating completely from scratch.

A few ideas the hardware timer/counter class should have:
-Should support capture or compare
-Period and CompareBuffer values should be configurable
-Run once or continuous
-Should be able to trigger a managed event handler, based on each available hardware interrupt
-Should have Read() and Write() methods for the counter
-Should have a Reset() method that returns int. It would return the current value and reset the count as a single atomic operation.