Anyone actually using hardware timers?

[Spencer E.]

I was just reading the white paper from IFI for the timers (I'm using one for the movement of my arm, I had no other choice) and I was wondering if anyone had any feedback on how well the actual RC timers work or if anyone has tried them. This is the first time I've ever used hardware level timers and I'm hoping the example given in IFI's paper will be a good enough supplement for the function I need it for.

EDIT: By the way, I'm willing to offer the timer code for all 5 timers once I get my robot code up and running.

[lukevanoort]

We have the wallclock code to operate Timer 1 from here running on our robot. I won't really say use, because it was going to be used to send the robot into different states (End of autonomous, not enough time left to score, so on) during autonomous, but that code was removed due to difficulties with the feedback system. It'll probably end up being used in autonomous at Palmetto for, at the very least, deploying the robot into scoring mode during autonomous. (Ideally, depending on how busy the practice field is, we'd like to get some scoring going with dead reckoning, but that is far less likely)

[Spencer E.]

Our team was originally going to use gear tooth sensors to get feedback from the arm during autonomous but it kind of fell through due to time constraints and I'm now working on code that will move the arm based on the amount of time passed since the function first began.

[Jake M]

If you just to designate the arm to move to certain positions at a certain time, just in autonomous mode, you don't need to use the timer. In 2005, we had a 3 point autonomous by just doing something like this....

Autonomous_Mode(void)
 {
  static int timer = 0;

  if(timer == 20)
    move arm up;
  else if(timer == 40)
    move forward;
  else if(timer == 60)
    drop arm;

  ++ timer;
 }

Surprisingly, we didn't even overflow once within the 15 second autonomous. Those may not have been the exact values we used, but they pretty low. I think the first two were under 100.

[Spencer E.]

I think a timer would be nice to use for my needs since it is exact to the second so I know how long I will need to move the arm rather than relying on the processors looping to change the arm position. I have looked into doing it the processor looping way but I feel safer using interrupt timers, it seems more exact to me .

[Qbranch]

well... lets see... using ccp's on TMR3:
1. Period Clock for 'overclocked' PWM's (update @100Hz as opposed to IFI's
38Hz update.... a 263% improvement )
2. %duty cycle up time (@16bits as opposed to IFI's 8) for left motors
(resolution increases x256 )
3. " " for right motors

TMR1:
1. In combination with INT2 on PORTB, timing pulses coming back from
ultrasonic transceiver to get distance in great 16bit accuracy (+/-0.05")

CCP's with programmable hardware triggers on compare matches... with the prescalar I'm using for the pwm timebase, getting accuracy of 0.0000002sec on pulse timing. Embedded peripherals make me happy!

For those of you who follow RALFF, I just finished v2 for 1024's 2007 robot. Have to say it was quite a bit more complicated than last years with the SDAR and all....

-q

[Spencer E.]

Wow! Even I didn't understand that haha I think I was being agreed with. Seems like 1024's robot is going to have one complicated code this year

[Qbranch]

Well Spencer if you want to know about any of it just give me a yell. Or, better yet if you are going to Buckeye or the Championship come over to 1024, ask for Q and I'll help you out in person.

Once you learn the hardware... you'll love the hardware... you can do so much cool stuff! It takes the mystique away from things like PWM too, lets you see how downright simple it is.... not to mention gives you the capability of updating PID's at 100Hz as opposed to 38Hz.... and don't forget the extra resolution!

Anyhow.... if you all have any questions about onboard peripherals (i.e. CCP's, Timers, ADCs, UARTS, etc), or anything of the kind, give me a yell, always glad to help.

one last thing... if anybody is having the encoder blues of too fast of an interrupt rate or not enough resolution, try out the analog encoders by US digital.... they are awesome... about 1008 counts of resolution and you don't need to sample them very fast at all... only about 4 times per revolution, unless you figure out a better driver that needs less... for us, to get resolution of about 0.1" the encoder only needs to be sampled at 90Hz and goes up to about 80~90Hz.... which paired perfectly with the PID and PWM update rate of my CCP based high frequency PWM driver.

*whew* ok well i need to get some sleep, sure there'll be plenty of coding to do come tomorrow morning. good luck to everybody else who at boilermaker this weekend!

-q

[Spencer E.]

Thanks Qbranch! If I ever need any interrupt help, I'll gladly ask . I was reading through IFI's white paper on timer interrupts and they have two methods: polled and interrupt driven. They say that either way is the same result but if it is suppose to cause an intterrupt at 25ms, and the fast loop is 26.2ms would it not cause some bias? I think the interrupt route would be more exact. Is there any difference?

[Qbranch]

Don't be fooled... there is a HUGE difference!

Picture this... the IFI main program loop polls for a bit saying that a new packet of data has been passed to the user processor from the master. Then, the IFI code calls Process_Data_From_Master_uP(). The whole time you are in this routine, you wont be polling for your flag... so that can mean up to many milliseconds of delay! Definitely not acceptible error for running a PID, calclating RPM, timing pulses, etc.

The interrupts will always be more (key word: more) exact than polling. While it does take a few microseconds to get into the interrupt, this is surely better than a few MILLIseconds. Of course there's a way around even the delay of interrupts... but we'll save CCP's for some time when I can talk with pad and pen and not have to type it all out.

Do you know how to use interrupts? Its kind of fun... but then again I think a lot of things are fun others dont . Kidding aside, if you need some tips/tricks/hints/explanations i'll give em.

Sometime i'm going to write a whitepaper on all the internal peripherals inside the processor... should be helpful. Just have to sit down and do it... ugh.

-q

[Spencer E.]

All I need the timer for is moving the arm, like I've said before, but I would like it to be exact so I guess I'll work with the interrupt then, thanks for the clarification. I'm not exactly an expert when it comes to writing interrupt code but I can do the bare minimum needed. I've learned from Kevin Watson's interrupt codes how they should be handled and everything. IFI mentions in their white paper that what I should do is get out of the interrupt as fast as possible and just set a variable inside the interrupt and handle it later. I find this kind of weird so what I'm planning on doing is instead of doing it their way, just incrementing the variable I have for keeping the seconds timed and incrementing it inside the interrupt. I don't see a problem with it, is there anything I should know about this?

EDIT: When I mention incrementing the seconds in the interrupt, I mean after the initial 25ms and 100ms interrupts

[ericand]

Since the interrupt handler blocks other interrupts, you want to do as little as possible in inerrupt context. Once you have incremented your timer count, the rest of the calculation should be "interruptable", so it should be done in the main code in the "fast loop" section (i.e. outside the 26ms data transfer to master processor section).

Theory aside, you probably won't notice any problem with doing what you propose. As described, you are doing a fairly quick operation, and you don't have many other interrupt sources that you could be holding off.

We have used the timers (based on the white paper) and find it very usefull to have a high (milisecond) resolution clock for various purposes. For example, if you have a routine to move an arm to a position, it could check the time when it starts and abort if it takes too long to get to position. Alternately, you can use the time to schedule activities on ticks other than the 26ms heartbeat provide by the getdata/putdata requirement.

[Qbranch]

A good tip... make interrupt code as efficient as possible... but often times you can't set a flag and handle it later, since this would be the same as just polling for the interrupt flag in the first place.

If you need to do something longer-time in the routine, but avoid this like the plague if you can, I just suggest that you use a digital I/O pin as a flag pin for how long your interrupt is running, and just time the pulse on your oscilloscope.

Another suggestion, just not a pin (ex rc_dig_out18 = !rc_dig_out18; ) in the Process_Data_From_Local_IO() routine, and wherever you don't see the constant frequency of the main processor loop you know the processor is busy, a good way to guage your % loading on your processor.

-q

[Spencer E.]

Thanks for all the help everyone! I've created the timer, wrote my autonomous code and I should be up and running fully in Waterloo . It'll require a bit a tweaking, but I'm up for the challenge .

[bear24rw]

Team 11 uses a timer to count 14.5 seconds, we drop our keeper last half second of autonomous mode.. it worked great for us and we never had any problems with it