Log in

View Full Version : how do you...


AlphaOmega870
22-01-2004, 17:28
create a counter for the autonomous code? :confused:

Kevin Casper
22-01-2004, 17:35
create a counter for the autonomous code? :confused:

What type of counter do you want? Time based? Cycle based? Event Based? Code for a counter?

If it is time based then one of the loops of the program happens every 26ms(I think). Just count the program loops and you have time.

AlphaOmega870
22-01-2004, 18:13
What type of counter do you want? Time based? Cycle based? Event Based? Code for a counter?

If it is time based then one of the loops of the program happens every 26ms(I think). Just count the program loops and you have time.
we want something like last years auton counter.

Bharat Nain
22-01-2004, 19:40
How would you create a Time Based counter?

Mercutio
22-01-2004, 20:20
How would you create a Time Based counter?
Read http://www.innovationfirst.com/FIRSTRobotics/pdfs/Timers_White_Paper_2004-Jan-14.pdf. It'll tell you everything you need to know. Make sure you know the basics of interrupts too.

~Aaron

Rickertsen2
22-01-2004, 22:18
If it is time based then one of the loops of the program happens every 26ms(I think). Just count the program loops and you have time.

Don't Do this!! It was the only option last year, but we have much better options this year. Create a timer interrupt that triggers every X seconds(see above whitepaper link), that inctements a variable. Jut read this variable an you have a timer. If you need orther help, just let the peeps here and we can help.

Bharat Nain
23-01-2004, 15:31
From where do you get all these help files and manuals?

Astronouth7303
24-01-2004, 19:55
IFI, mostly.

echos
25-01-2004, 05:43
here is some rather straight forward code, simular to previous years stuff.


unsigned int counter;

if(autonmous_code)
{
if(counter <= 20)
{
pwm01 = pwm02 = 255;
}

else if(counter >= 21 && counter <= 100 && counter != 99)
{
pwm01 = 255;
pwm02 = (pwm01 -= 254);
}
else
{
die(void);
}

counter++;
}

Obi
25-01-2004, 08:41
here is some rather straight forward code, simular to previous years stuff.


unsigned int counter;

if(autonmous_code)
{
if(counter <= 20)
{
pwm01 = pwm02 = 255;
}

else if(counter >= 21 && counter <= 100 && counter != 99)
{
pwm01 = 255;
pwm02 = (pwm01 -= 254);
}
else
{
die(void);
}

counter++;
}


Our program (Team #870) looks like that, except that we have counter = 40 x the MS (26.2, but we use 25). We then output that to the IFI loader screen, and we get a nice display, every second, declaring the amount of seconds, whether in Auton mode or Practice.

FotoPlasma
25-01-2004, 08:57
Just like James said earlier in this thread, I highly recommend using something a little more advanced than just incrementing a counter variable every code cycle. The PIC18F8520 comes with 5 seperate timers (the first of which is used by IFI, so we have access to 4). They're pretty well documented in the datasheet (http://www.microchip.com/download/lit/pline/picmicro/families/18fxx20/39609a.pdf) for the microcontroller (sections 11 through 15). Three 8bit timers, and one 16bit timer. With all of the capabilities of the processor, itself, I would be very disappointed to see any team counting cycles as a timing system. I'm already forcing my programming mentees to learn about timers, interrupts, and other such features of these nice little machines.

Obi
25-01-2004, 09:30
I don't exactly see the advantage of using interrupts over counting cycles. Care to elaborate?

Rorschach
26-01-2004, 20:38
here is some rather straight forward code, simular to previous years stuff.


unsigned int counter;

if(autonmous_code)
{
if(counter <= 20)
{
pwm01 = pwm02 = 255;
}

else if(counter >= 21 && counter <= 100 && counter != 99)
{
pwm01 = 255;
pwm02 = (pwm01 -= 254);
}
else
{
die(void);
}

counter++;
}


I know this may sound rudimentary, but where is <i>die(void)</i>, is that the function that the routine is within?

Mark McLeod
27-01-2004, 09:21
I don't exactly see the advantage of using interrupts over counting cycles. Care to elaborate?


Program cycles will vary as you add and remove code.
The cycles are also variable in general because of other events like interrupts that may be going on asynchronously. So one loop might take 50 clock ticks while the next takes 150 ticks. Over time you can accumulate large variations.

The clock approach always puts you within a few clock ticks of where you expect to be, and errors don't accumulate over time.