You can have a task that reads the ADC and then on a trigger raise an event to managed code.
Reading adc is rather easy but you need to read the processor datasheet.
@ Gus: thanks, this task won’t interrupt with regular .NETMF execution? (other then steeling some of the processor cycles of course), the task i want to do is time critical and i can’t seems to achieve it in .NETMF mode
Reading adc will only take few microseconds.
I think the audio recording RLP sample would be a great point to start for that, even if you don’t need such a high sampling rate.,
@ Reinhard - thanks i already familiar with that example, will look into it better if you say so 
@ Gus - i know reading a single sample takes a few microseconds but the task is continuous meaning it will work all the time to detect a ADC condition (impact of some sort) and then raise an event in the .NETMF application, i can achieve that right?
thanks again for the fast replies
This is what a RLP task is for.
You do not simply wait in a loop, but you set a new RLP task in a specific time.
After that time your RLP routine is called again. In the meantime Managed code is executed.
This is exactly how the audio recording sample is working in the end.
All you need additionally is raising an event from RLP to Managed code when your ADC value meets the condition.
But that’s simple.
from your reply implies that the task has “dead” times where it is idle, i need to be able to detect an impact that is 30msec at length (roughly) so i figured that task behaves as a “thread” in the regular MS environment which means it should run the whole time (beside context switching…) is that the case with RLP Task?
No not really. The RLP Task is more like a timer (I guess it just sets a timer interrupt).
In each “timer” event you set the time when the next event should happen.
How exact do you need the start/end/length of the event?
You could setup the RLP task to fire every 1 or 2 msec.
The shorter you make that time, the higher is the sample rate. But it will also drain more CPU time from the managed code.
What does the analog event look like?
It might be possible to “map” it to a digital input by some resistors, …
If you use an interrupt capable GPIO, you could setup an RLP interrupt on both edges, and by this react to it without wasting any CPU time.
I mistakenly said ADC while i should have said ACCELEROMETER, i want to be able to detect a certain impact that is detectable with a simple thread on the accelerometer, but if i do that on .NETMF then my cycle is too slow so i wanted to go to RLP
from your explanation Task is not a thread since it is not continuous but sound more like “alertable” process that wake every certain timeframe, is that the case?
What accelerometer do you use?
The often have an internal comparator, which can set and clear an interrupt line (digital output).
The threshold can usually be paramerized.
If you connect this digital output to an interrupt capable GPIO, you can react to it.
