Re: New C18 3.0+ Compatible FRC Code
 

I wonder if Kevin's release of this updated code (albeit a beta version) implies that the IFI default code will also be heavily revised for 2008. If nothing else, I think it strongly implies that the canonical IFI RC/OI package will be in the KOP this year, even if it is the last time.

Alex

Re: New C18 3.0+ Compatible FRC Code
 

Yes, it certainly is. Thanks for catching it.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Or, given that Dave Lavery has the PsyOps and misinformation dials cranked up to eleven, you might consider that I could possibly be doing his dirty work by misleading everyone. Heck, for all I know, you could be working for Dave too and are planting counter-misinformation :D.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

I noticed this file does not include any encoder-related files. Are you planning to add support to encoders to this code?

Thanks.

Re: New C18 3.0+ Compatible FRC Code
 

It should be pretty easy to write your own encoder code with this architecture's method of handling interrupts. It would only take a few if statements and a couple of very short functions to read from a quadrature encoder. Much of the trouble with writing encoder code is configuring interrupts, and Kevin has already done that here.

You could basically copy and paste the code from the encoder driver's ISRs into the ISRs in this version (or put them in another file and call them from the ISRs, which would probably be more readable) and add the Get_Encoder_x_Count() function. Actually, if you just didn't call the initialization functions, you could probably use the current encoder code verbatim (well, for encoders one and two anyway, for 3-6 you'd probably just want to reuse the code from encoder 1-2 instead of the encoder driver's functions for encoders 3-6). I would say that it would probably be less than 20mins to code.

Re: New C18 3.0+ Compatible FRC Code
 

Great design. Just a word about words.

The *_Spin() functions are great -- it's just that in my little robot namespace world "spin" refers to when the robot turns around its axis. (We set up the joystick so one of the buttons calls the spin() routine that makes the robot turn on a dime.) When I saw "spin" that's what I thought it meant; I had to study the code to see what it really meant.

Is "spin" so standard in the embedded world that I should invent a new term for "turning on a dime"? (Diming? What if you only turn 90 degrees? Is that Quartering?) Or can we name the _Spin() functions something else? _WhileWeAreWaitingForNewData()? _StudyHall()? _Loitering()?

Sorry for the bad jokes, but I'm seriously concerned about overloading the term "spin"...

It just me?

Re: New C18 3.0+ Compatible FRC Code
 

In computer science a "spin loop" is a way to waste time while waiting for something to happen.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

If I get the sense teams will use the new code, I'll create versions with support for some sensors.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

I noted that when I look at the .map file there is no reference to the low.isr.tmpdata in the map file ?? why is this?? I wanted to see how much space the compiler is giving to this... .tmpdata is there...

thanks...

Re: New C18 3.0+ Compatible FRC Code
 

The linker won't create the section if no temp storage is needed. Try enabling one of the interrupts and put this code in the interrupt service routine:

int a = 2;
int b = 3;
int c = 4;
int d;

d = (a + b + c) - (c + a);

Compile and then look at the .map file.

-Kevin

Re: New C18 3.0+ Compatible FRC Code
 

In case we need that extra push over the cliff right about now :)

Alex

Re: New C18 3.0+ Compatible FRC Code
 

Kevin,

If you're looking for a head count for your template, count the TechnoTicks (236) in!

Re: New C18 3.0+ Compatible FRC Code
 

You could also probably count us (8) in too.

I have a somewhat related question that stems from encoders. How fast to digital inputs update? Is it the 26.6ms loop? Faster? I'm asking because I'm wondering about updating the encoder B channel. If it doesn't update fast enough, aren't we risking using an old value and so getting the wrong direction?

Re: New C18 3.0+ Compatible FRC Code
 

Treat the digital I/O as instantaneous. It's faster than the execution speed of the program instructions. What you read from an input pin is the state of the pin at that moment. What you write to an output pin takes effect immediately. There are measurable (but trivial) delays, but unlike PWM and relay outputs, there's no interprocessor software communication in the way to slow things down.

Re: New C18 3.0+ Compatible FRC Code
 

Very cool. Just what I was hoping to hear. Hopefully I'll have this new code driving a robot and looking at encoders before the week is over, and I'll be happy to give you (Kevin) any feedback or bugs I find.