8 replies to this topic

[Crispin]

Folks, Maybe my thinking is all wrong... I was wondering if there is a way to see how busy the CPU is. In the normal world, if you wrote a programme that had While(true){} and waited inside it for an event, you'd be shot (in most cases). Is there a way to work out how busy the CPU is? In my current project I have 3 threads running, each checking different sensors (love threads!! ), each thread has a while loop which never ends but has a sleep(50) at the bottom. Is there a way to see when you are actually always "doing work" instead of your main thread just bouncing round in a loop. Cheers, Crispin

[Chris Walker]

Hi Crispin, There's no "performance monitor" for .NET Micro Framework, at least not today. It would be something cool to recommend to the .NET Micro Framework team for inclusion in a future release. Chris

[MattW]

[snip!]
I was wondering if there is a way to see how busy the CPU is. In the normal world, if you wrote a programme that had While(true){} and waited inside it for an event, you'd be shot (in most cases).
[/snip!]

Good question. You would think a while(true) loop would mean 100% CPU utilitzation and therefore higher power usage. Is that the case?

[Chris Walker]

Good question. You would think a while(true) loop would mean 100% CPU utilitzation and therefore higher power usage. Is that the case?

That is the case. Using event handlers and background threads with Sleep(...) timers is "best practice" for .NET Micro Framework and can save you power in many cases. A while(true) loop without any sleeps in it would be keeping the processor plenty busy (up to 100%).

Chris

[Chris Seto]

I don't know how NETMF handles while loops, but I do know they aren't a good idea. If you have to loop endlessly, you are suppose to use timers. I don't know how smart NETMF is in handling stuff like that, though.

[Chris Walker]

I don't know how NETMF handles while loops, but I do know they aren't a good idea. If you have to loop endlessly, you are suppose to use timers.

I don't know how smart NETMF is in handling stuff like that, though.

It's a pretty cool paradigm shift... In traditional embedded programming, while loops are very common. But with .NET Micro Framework, you get the power of richer features: timers, threads, event handlers, etc.

I'd generally avoid using infinite while loops in .NET MF code. But they're great when you're starting out ("blinky" for example).

Chris

[Crispin]

Thanks folks. While(true) never seems like a good idea, embedded or not. I'm still exploring the micro frame work but seem to recall seeing a timer class. If this is anything like a normal timer then all is well. Bummer about the perf mon though but in reality, it would probably consume a lot of what little you have Still, I'll go have a look on Connect.

[ajcg1973]

I'd generally avoid using infinite while loops in .NET MF code. But they're great when you're starting out ("blinky" for example).

Chris

Chris,

Two questions,

First question, in my embedded experience with Microchip 8bit PIC's and from what I have seen and done, generally you do have infinite loops that keep the processor going in loops (not including interrupts) because the processor is completing a relatively simple task over and over again forever. While I would prefer that the Netduino doesn't do this so certain items can be garbage collected if need be, I'm not sure I can accomplish this without an infinite loop. How do you get around this?

Second question, what is the recommended minimun resolution for an ExtendedTimer in the .net micro framework for the Netduino? I know for most versions of Windows a timer event resolution is only good for about 55ms. Is there a way to reliably calculate the minimum resolution on a Netduino?

Thanks.---AJB

[Chris Walker]

ajcg1973, You can do infinite loops if you'd like...it's fully supported by the .NET Micro Framework. Threads and event handlers can make it much simpler to create sophisticated projects--but whilte(true) loops are great for things like blinking lights or "read and write" type of applications. BTW, Netduino will still garbage collect in your infinite loop. Garbage collection can be triggered by low-memory conditions. You can also write code that doesn't need to be garbage collected if you want to be a little more advanced... As far as ExtendedTimers go, my general assumption is that they're accurate to around a millisecond--but I haven't personally tested that. Perhaps someone here has tested them (and if not you can certainly test it yourself). High resolution timers are available in Windows now and since .NET MF is not based off of a legacy ~18Hz clock I think you'll see better timing here. Chris