Another simple OutputCompare sample

This is a simple example of OutputCompare.

I wrote it to learn about the OC so it might help others, or it might not. :slight_smile:

What surprised me was that the OutputCompare kept on running when the program was paused… :slight_smile:

All it does is “breathe” the onboard led on a Panda/Domino. What is nice is that it is “fire and forget”…


using System;
using Microsoft.SPOT;
using System.Threading;
using Microsoft.SPOT.Hardware;
using GHIElectronics.NETMF.FEZ;
using GHIElectronics.NETMF.Hardware;

namespace USBizi_Application1
{
    public class Program
    {
        public static void Main()
        {
            OutputCompare oc = new OutputCompare((Cpu.Pin)FEZ_Pin.Digital.LED, false, 360);
            uint[] Buffer = new uint[360];//Create a buffer for 180 on times and 180 off times
            for (int i = 0; i < 360; i=i+2) //Fill the buffer with the on times from the SIN function.
            {
                int SinValue=(Microsoft.SPOT.Math.Sin(i)+1000)*10;//Value will vary between 0 and 20000

                Buffer[i] = (uint)(SinValue);//On time
                Buffer[i + 1] = 20000 - Buffer[i]; //Off time is the remaining time, of 20000us, after On time.
            }
            oc.Set(false,Buffer,0,Buffer.Length,true);//Start the Output Compare, repeating.
            //while (true) ;
            Thread.Sleep(Timeout.Infinite) ;// Sleep CPU
        }
    }
}

You are welcome :wink: We have some super nerds working at GHI making this happen lol

This should go on fezzer.com :wink:

especially since you end the program with a while (true) which is really bad on the .Net interpreter

I didn’t see that while loop…yes that is VERY bad!

Why is that bad other than he is stuck in a tight loop. Something else going on that we should know about?

-Eric

it’s stuck in a tight loop but running the CPU at full speed. thread.sleep(timeout.infinite) is much better since it’ll let the CPU idle.

It’s not “bad” for anything, but as was mentioned the CPU will be at 100% usage. More power = more heat.

There’s not really a reason for doing it versus Thread.Sleep(), but unless you have other threads or stuff like the OutputCompare it’s not going to matter much :slight_smile:

It is bad because at 100% load you may have little problems connecting VS to the device as the device is too busy to respond to VS.

Does that mean that .netmf does use a low power mode for idle?

I must admit that the while(true) is from my embedded habits, as a last ditch attempt to prevent the CPU from going into an unknown state.

I’ll change the code to use sleep… :slight_smile:

Yes absolutely :slight_smile: