Re: New C18 3.0+ Compatible FRC Code
 

Ahh. I understand. No ISR at all. That would make it run slightly slower than 100hz, but will probably help performance slightly (due to the lack of the ISR). Thank you very much.

EDIT: Actually, I am not sure if it will run any more slowly at all. This looks great.

EDIT 2: Timer 0 does not seem to have the support to run to a predetermined value like timers 2,3,4. Should we use timer 2 instead? Another question. None of these timers actually allow us to run a 100hz cycle, even with 1:16 pre- and post-scalers. The slowest we can do is 150hz. Am I missing a way to do it, without using a second flag, or should we just use 150hz (or a double flag)?

EDIT 3: I just ran into another potential obstacle. Our calculations say that we will get at most 15 ticks from the encoder per cycle. That does not seem like a very high resolution. We're currently trying to see if this will actually be an issue, and if so, what we could do about it.

Re: New C18 3.0+ Compatible FRC Code
 

I see the linker problem when enabling some but not all of the encoders in the 3 to 6 range.

Chad

Re: New C18 3.0+ Compatible FRC Code
 

The ISR linker issue occurs if encoders_3 and beyond are enabled because...

ENABLE_INT_3_6 must be defined in ifi_frc.h, in order to use encoders in the range 3_6

This causes 'calls' to the ISR routines from ifi_frc.c lines 326 to 338.

But if this code block is enabled, all the interrupt code must exists in encoder.c.

That only happens if ENABLE_ENCODER_3 through ENABLE_ENCODER_6 are ALL defined in encoder.h which compiles in ALL the ISRs in encoder.c.

The define hierarchy needs to be fixed, or use all of 3_6 ISRs or none of them.

Chad

Re: New C18 3.0+ Compatible FRC Code
 

Yep, it doesn't quite work correctly. Thanks for catching my gaff. I'll have an update probably tomorrow.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,
First I would like to say, Thank you in advance.


Is it possible that once you make this modification to the project files and post them, that you could also list the files that were modified so we would be able to just copy the modified files into our already customized projects and then just rebuild. It would save quite a bit of time if we didn't have to make all the customizations again. If not, no sweat, we could always use the practice. :cool:

Re: New C18 3.0+ Compatible FRC Code
 

Does it give anyone heartburn if I just release one build for each of the two compiler versions that has support for the ADC, gyro and encoders already built in? You'd be able to remove funtionality by commenting out a few #defines.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I have no problem with that.

Re: New C18 3.0+ Compatible FRC Code
 

IMHO, that would be ideal!!!

I don't mind hacking together various functions, in fact, I have learned a lot by doing this in the last couple years. But, if it is together already, it would be VERY convenient! ;)

Re: New C18 3.0+ Compatible FRC Code
 

I know this might be kinda random, but does anyone know if we are allowed to use any kind of gps system in our robot sense it's location on the field?

Re: New C18 3.0+ Compatible FRC Code
 

This seems like a more efficient approach for both you and people using the code.

Re: New C18 3.0+ Compatible FRC Code
 

This post is irrelevant to this topic, but in any case GPS is too inaccurate for this use. Also, it involves receiving external communications, which I understand is against the rules.

Re: New C18 3.0+ Compatible FRC Code
 

Excellent idea!

BTW, would you think that using 4 interrupts,INT's 3-6, at 128 ints/sec (every ~8ms) would be overstressing the processor? My students want to control our mecanum drive with an encoder on each wheel; I favor the gyro approach.

Thanks again for your work for the teams!

Re: New C18 3.0+ Compatible FRC Code
 

How are people implementing these updates?

Re: New C18 3.0+ Compatible FRC Code
 

We would definitely prefer it that way.

Re: New C18 3.0+ Compatible FRC Code
 

That sounds good. Doing code management through a one way CVS or some such code repository arrangement where our work can be locally merged but we can stay up to date with you would be nice :)

Chad