Interupts/sec

[cprogrammer]

I am looking at putting encoders on the robot next year. The main question I am wondering is what is the maximum interrupts per sec the encoder.c can handel.

[Tom Bottiglieri]

It's all relative to what you are doing. Encoder.c isnt actually doing much work except for initializing the interrupt to detect on a rising edge and holding the interrupt handler. It really all depends on what else you are doing in the code. If you are running default code, you will be able to service more interrupts without over budgeting your time period to report back to the master processor. Likewise, if your code is fairly complex your ability to service a ton of interrupts will be brought down. We ran into this problem last year with encoder interrupts, serial interrupts, and a full field navigation system running on the RC at all times. We ended up putting a switch on the robot to turn serial on and off because our robot would reset about 5 times per match.

I guess think of it as a pizza. Half of the pizza's toppings can be interrupts, half can be regular routines. You don't have to eat the whole pizza (processing time), but you certainly can't eat more than you have been given.

[Kevin Sevcik]

Also remember that the tighter your interrupt handler and other code is, the more interrupts you'll be able to handle. If you're only using Encoder 1 and 2, you can excise all the code for Encoders 3-6 and save yourself 5 branches and a bit of extra code in the interrupt handler. Ditto the serial ports. Basically, dump anything in your code that's not serving any purpose.

[Matt Krass]

Originally Posted by Kevin Sevcik

Also remember that the tighter your interrupt handler and other code is, the more interrupts you'll be able to handle. If you're only using Encoder 1 and 2, you can excise all the code for Encoders 3-6 and save yourself 5 branches and a bit of extra code in the interrupt handler. Ditto the serial ports. Basically, dump anything in your code that's not serving any purpose.

And by dump he means comment out in case you end up needng it later. For stuff thats going to be perma-commented I like to use #ifdefs

#ifdef IWANTINT3TO6
...interrupt 3-6 and such code...
#endif

So now later if you want to enable them, at the top of your file, just put

#define IWANTINT3TO6

I find it useful to convert the default code in to a series of modules that can be 'enabled' by #define's.

[Kevin Sevcik]

Matt,

Kevin already has most of his code disabled with #ifdef's. It's just trickier to get rid of all the if-elses that way, and you have to make sure you don't accidentally enable those interrupts elsewhere and...

Sometimes it's easier to just decide what you need from the beginning, and really mean it, rather than to have snippets of possibly, maybe useful commented-out code everywhere in your program that do nothing but get in the way and confuse the syntax highlighter. I always advise the programming team to get rid of the vast majority of the default code and its default port mappings, if only to prevent odd things from happening when a PWM cable is plugged in the wrong place.

I'm sure keeping code makes sense when you're first developing your program, but you really should be able to pare things down to what you're actually using for competition code. Unless of course your game plan is to integrate 2 wheel encoders for navigation into your robot on practice day.

[AdamHeard]

Originally Posted by Kevin Sevcik

Matt,

Kevin already has most of his code disabled with #ifdef's. It's just trickier to get rid of all the if-elses that way, and you have to make sure you don't accidentally enable those interrupts elsewhere and...

Sometimes it's easier to just decide what you need from the beginning, and really mean it, rather than to have snippets of possibly, maybe useful commented-out code everywhere in your program that do nothing but get in the way and confuse the syntax highlighter. I always advise the programming team to get rid of the vast majority of the default code and its default port mappings, if only to prevent odd things from happening when a PWM cable is plugged in the wrong place.

I'm sure keeping code makes sense when you're first developing your program, but you really should be able to pare things down to what you're actually using for competition code. Unless of course your game plan is to integrate 2 wheel encoders for navigation into your robot on practice day.

We do things similarly. We keep things commented like he mentioned, but when it comes close to the final code we start to get rid of all of those things.

[Qbranch]

Heck I mean I used an 18F series part similar to the one in the first controller to run two stepper motors independently at different speeds up to 12.5KHz... granted I used the ECCP3 and ECCP2 peripherals on-chip.

Need any help, just hit me up.

-Q

[yongkimleng]

Originally Posted by Qbranch

Heck I mean I used an 18F series part similar to the one in the first controller to run two stepper motors independently at different speeds up to 12.5KHz... granted I used the ECCP3 and ECCP2 peripherals on-chip.

Need any help, just hit me up.

-Q

been reading alot of datasheet.. but i was wondring, what ARE ECCP/CPP ports for? tried to understand and read that ECCP can do things like H-bridge motor controller..

[Qbranch]

ECCP/CCP means Capture/Compare, the pins are triggers off the compares. They are only active if you set them up the right way.

You can use these to create very very accurate frequencies, and can set up to trigger off of a falling edge to create duty cycles. Just read some app notes and the manual, I think you'll understand it. Took me a while, but now that I know, I don't think i'll ever go back to overflow timers again.

With the ECCPs i've made a two axis motion controller based on the 18F8722, while also doing guidance as well as motivation. Once the die issues are fixed this winter, the 8722's HPC Explorer will be my favorite development board to run robots off of.

-Q

[duane]

Originally Posted by cromat44

We do things similarly. We keep things commented like he mentioned, but when it comes close to the final code we start to get rid of all of those things.

This is also what a source code control system is for. An SCCS system like subversion let's you check-in changes to your code as you go. This records the history of your changes as you go along. This allows you to go back to previous versions and see what was changed so you can bring back those things you really didn't mean to remove.

...Duane