Igor Kondrasovas

Hi Chris,

 

Can you give us a little update about what are the news regarding Power Management on Netduino Plus 2? There is an interesting topic here on this post, but I would like to know if there is something else missing that is exclusive to ND+2

 

Thank you,

 

Igor.

Hi Igor,

Good thinking.

The interrupts should be queued (and NETMF will actually drop some if you get too many, to prevent overflows).

But yes, if you get too many queued up...you could eventually run out of memory. This is more of an issue on Netduino Plus 1 than Netduino Plus 2, but it's true for any devboard.

Chris

P.S. Are you getting any glitching (extra state switching) on your input? Or is it an accurate pulse?

Hum...so there is no "nesting" on the interrupt handlers. In fact they are queued an stays on the queue until the previous interrupt handler if finished, right? Like a FIFO behavior.

Pulses seems to be accurate. With a 2KHz input pulse (generated by a PWM on another Netduino) I got stable readings. Should it make difference if I set InterruptPort to use pullup?

Thanks,

Igor.

With the word 'failed' it makes the message seem like something is messed up.

Thanks for the quick reply Chris.

Hello Chris,

Sorry for bringing back this thread, but I am also experiencing something similar when making some fast input readings using interrupts.

My scenario is similar to this thread: http://forums.netdui...goodbye-net-mf/

After upgrading to firmware 4.2 I started to get these "Failed allocation for X blocks". To verify if my app was still running I put some LED blinking, but it seems the app is crashing.

I would like to confirm if my thinking is correct:

As my test app does not allocate much objects but it does use interrupts, I suspect the memory is missing due to the "nested interrupts". In other words, during the interrupt handling my application receives a new interrupt request that is also handled before the first interrupt is completely treated. So after some time there will be no RAM enough for saving such a huge stack, correct?

I tried to change the InterruptMode to InterruptLevelHigh instead and the error messages were gone. This way I would "avoid" having nested interrupts as I reactivate it only at the end of the handler. Obviously I will loose input pulses this way...

Igor.

All I did was to reinfoce duty cycle after setting a new frequency. Then I could get reading around 3.5KHz! After that my Netduino Classic stucked. I will upgrade it to .NET 4.2 and run the tests again as soon as I can, than I let you know the results.

Thank you,

Igor.

Well, I did the tests running Firmware 4.2 and I got similar results as reported in this thread: http://forums.netdui...goodbye-net-mf/

Now I will make some readings about what this erros message is and why it is hapenning. Either way, I think I will have to use an external componet for encoder reading.

Igor.

Hello, Today I tried the same scenario using an Arduino to receive the pulses (acting like the component that will count pulses). As soon I started the tests I realized I got the same strange behavior when the frequency was around 30Hz. So, I was pretty sure I was doing something silly in my pulse generator code. As I don't have an oscilloscope in hands here, I doubted if the PWM class was keeping the duty cycle to 50% (as declared on the PWM construtor) after I set a new frequency. And I realized it was not! so the problem was when I increased frequency, I was also indirectly increasing the relative dutycycle (since the duration was fixed) until we got a fixed true logic level on the PWM output. That was the reson I could not read after 32 Hz (2x16Hz). All I did was to reinfoce duty cycle after setting a new frequency. Then I could get reading around 3.5KHz! After that my Netduino Classic stucked. I will upgrade it to .NET 4.2 and run the tests again as soon as I can, than I let you know the results. Thank you, Igor.