That is a memory issue, which makes me think that your event handler is way to complicated. You should do the bare minimum in the event handler and not create any new variables, etc.
You could also look at using input capture or doing this in RLP to see if either offers a better solution.
Interrputs are queued in memory and then dispatched to your code. If interrupts occur faster than you can process them you will run out of memory.
When I did my testing I was able to handle in the 1200-1700 interrupts per second rate with no processing in the interrupt handler. I don’t remember the exact maximum rate.
You are handling interrupts on both edges, so at 600hz you are getting 1200 interrupts a second. Do you really need to handle both edges? Handling one edge will double you input range.
If you want higher rates, then you should look at RLP.
it only this thre line + interrupt :
static void port_OnInterrupt(uint port, uint state, DateTime time)
{
if (state == 0)
{
// Falling edge - end of pulse
I have another device that I have to use the same time.(all this working fine - I 'm not add the RPM yest)
GPS 20 Hz com4
Accelerometer MMA7455L I2C
temperature max6675 -SPI
Xbee - com2
I’ll let you know when find out what is Max Interrupt frequency for Panda II
I can only read under 300 Hz , if more just few second work and out of memory
whats wrong, Mike said that should work 1200 Hz
This is the code ,
using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using GHIElectronics.NETMF.FEZ;
namespace FEZ_Panda_II_Application1
{
public class Program
{
static InterruptPort port;
static long tiks = 0;
static long v = 0;
static long pulseWidth;
public static void Main()
{
port = new InterruptPort((Cpu.Pin)FEZ_Pin.Interrupt.Di0, false, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeHigh);
port.OnInterrupt += port_OnInterrupt;
while (true)
{
}
}
static void port_OnInterrupt(uint port, uint state, DateTime time)
{
pulseWidth = time.Ticks - tiks;
v = pulseWidth;
tiks =time.Ticks ;
}
}
}
The above code is a big part of yoor problem, your burning all of your processor’s time running in a tight loop that does nothing… You should use a thrread.sleep(timeout.infinate) there instead.
In cases like this, it may be a good idea to draft a plan. I.e.:
Do you need to sample continuously, or can you sample every few milliseconds?
How often do you plan to act on the information and how long does it take to do such processing?
With some careful management of timings you should be able to pull it off.
Also keep in mind that the .NET MF uses cooperative multitasking, that is, it will move from one thread to the next every 20ms or sooner depending on whether the current task yields its time slice once it is done. Thus the suggestion to put the [italic]while[/italic] statement to sleep it if is doing nothing, otherwise it will spin uselessly for 20ms. Invoking [italic]sleep[/italic] tells the CLR to pass the plate to the next thread. Your interruptions will run in a “separate thread” and are subject to scheduling.
Do you need to sample continuously, or can you sample every few milliseconds?
Very interesting, how I can sample continuously ? I don’t have a tape .:). 100 ms will be fine
I got the point with while - sleep, so I can do in separate thread.
I will have the following Thread
GPS update rate 50 ms (working fine I do not lost data)