Main Site Documentation

IO60P16 - Reading pins eats up memory until application crashes


hi everybody,
i have a memory issue when polling pins of an IO60P16 module. my application is very simple. I just need a timer event in which I poll the state of 18 InportPins of an IO60P16 module. when I do Debug.GC(true) i see that the memory consumption of Type 11 (CLASS) and Type 1B (DELEGATE_HEAD) increase with each timer event. I’m using the normal GHI driver for the IO60P16 module. my mainboard is a Spider. any help would be much appreciated.

here’s the code of my timer event:

void timer_Tick(GT.Timer timer)
    for (int i = 0; i < SLOTS; ++i)
          byte current = pins[i].Read()  ? 1 : 0;
           // do something with my data

and here is how i initiate my inputPorts:

pins[0] = new IO60P16.InputPort(io60p16, IO60P16.IOPin.Port1_Pin0, IO60P16.ResistorMode.ResistivePullUp);


Is that complete code for the timer_Tick routine?


no. but i reduced it to this part while debugging with the GC print and still had the issue. so my guess was that it must be up to the read operation.


Can you show the rest of the code?



void timer_Tick(GT.Timer timer)
    for (int i = 0; i < SLOTS; ++i)
          byte current = pins[i].Read()  ? 1 : 0;
          if (current != status[i])
                // toggle LED
                if (current == TRUE)
                    ledPWM4.SetPulse(0 );
                // write to output
                status[i] = current;


serial is the serial interface of a usbserial module. but as i said i commented all this and still had the issue.


Very strange. And if you comment out actual Read call the issue is gone, right?




@ dustin - What is the tick period of your timer?

It might be that you are generating timer events too quickly so they are getting queued up and this queuing is causing the out of memory problem.

This happens when the your timer fires quicker than the code that is in the timer tick handler can actually execute so a new timer event is put into a queue while the previous event handler is completing.

The Read might appear to cause the issue, when what is really happening is it is introducing enough latency into the handler to induce the queuing of events.


@ taylorza - That makes sense especially with Type 1B (DELEGATE_HEAD) increasing.


that’s very likely to be the problem. the tick period is just 1 millisecond. will try it out with longer periods. thanks for pointing this out! will let you know about the result.