New C18 3.0+ Compatible FRC Code

[Mike Mahar]

Does this mean that the resolution that IFI published to "fix" the 8.3 volt problem does not work. They recommend changing a high chuck of memory (0xF00 - 0xF5f) to "PROTECTED".

[Kevin Watson]

Originally Posted by Mike Mahar

Does this mean that the resolution that IFI published to "fix" the 8.3 volt problem does not work. They recommend changing a high chuck of memory (0xF00 - 0xF5f) to "PROTECTED".

No, that's not what I'm saying. Clearly the "fix" does work because I don't think anyone has seen the 8.3 volt problem since IFI published the new linker script.

I just thought it was interesting that a bug in my code could induce the same symptom that teams saw two years ago. Although I know how to fix it, I'm not sure I know exactly what caused it. For my own edification I'd like to track it down because it's not obvious to me what is causing it by examining the source code.

-Kevin

[billbo911]

Originally Posted by Kevin Watson

I just thought it was interesting that a bug in my code could induce the same symptom that teams saw two years ago. Although I know how to fix it, I'm not sure I know exactly what caused it. For my own edification I'd like to track it down because it's not obvious to me what is causing it by examining at the source code.

-Kevin

I have complete faith in your ability to find the root cause! But, until you do, and because you know how to fix it, can you share with us how to fix it so we don't run into it until the final fix is released. From your prior comments, it sounds like we just need to completely clear the RAM on reboot. Could we make the changes to our projects to do this, or would it just be easier to replace a particular file with the mods in it already?

BTW, I fully understand your need to know exactly why this problem happens and just knowing how to fix it isn't enough.

[Kevin Watson]

Originally Posted by billbo911

I have complete faith in your ability to find the root cause! But, until you do, and because you know how to fix it, can you share with us how to fix it so we don't run into it until the final fix is released. From your prior comments, it sounds like we just need to completely clear the RAM on reboot. Could we make the changes to our projects to do this, or would it just be easier to replace a particular file with the mods in it already?

BTW, I fully understand your need to know exactly why this problem happens and just knowing how to fix it isn't enough.

As far as I can tell, there are no bugs in my code. The bug I referred to was fixed long ago and the fix incorporated before I released any code. If interested, it's the six lines of assembly under the "initialize memory to all zeros" comment in ifi_frc.c/_startup().

-Kevin

[billbo911]

Originally Posted by Kevin Watson

As far as I can tell, there are no bugs in my code. The bug I referred to was fixed long ago and the fix incorporated before I released any code. If interested, it's the six lines of assembly under the "initialize memory to all zeros" comment in ifi_frc.c/_startup().

-Kevin

Ahh, got it. Your code has this problem corrected already. The error was in older code. COOL!!! I feel better already!

[ayeckley]

There seems to be something amiss when using the combination of MPLAB 8.0, C18 V2.4, the V2.4 beta code and the MPLAB SIM debugger. I think that's a "legal" combination, right? The simulator seems to be going off into the weeds when it hits line 373 (serial port enable) of serial_ports.c. The odd thing is that if you step through it it hangs up on that line, but if you let it run it instead hangs up on line 427 of ifi_frc.c, which is _do_cinit();

Is this just a question of the beta code not supporting MPLAB SIM? I don't think I've seen any _SIMULATOR definitions in either the 2.4 or the 3.1 beta code.

Edit: The same thing happens when I run the 3.1 beta code with C18 v3.1. Maybe I'm the only one trying to use MPLAB SIM? It worked like a champ with last year's code.

[eugenebrooks]

Originally Posted by Mike Mahar

Does this mean that the resolution that IFI published to "fix" the 8.3 volt problem does not work. They recommend changing a high chuck of memory (0xF00 - 0xF5f) to "PROTECTED".

The IFI "fix" did not help the instance of the 8.3 volt problem
that we ran into using the 2006 controller in the game Aim High.
If may have helped some teams, but it did not fix things
for us and I am aware of some other teams that it did not fix
the problem for as well.

We will happily try zeroizing all of memory at startup if we
see 8.3 showing up in the voltage display during this build season.

Eugene

[Kevin Watson]

Originally Posted by eugenebrooks

The IFI "fix" did not help the instance of the 8.3 volt problem that we ran into using the 2006 controller in the game Aim High. If may have helped some teams, but it did not fix things for us and I am aware of some other teams that it did not fix the problem for as well.

Ugh, I spoke with IFI last week and they're of the opinion that the 8.3 volt bug has been fixed. If this bug bites you again, please let IFI know (and if you don't mind, me too).

Originally Posted by eugenebrooks

We will happily try zeroizing all of memory at startup if we see 8.3 showing up in the voltage display during this build season.

Open up ifi_startup.c and replace the call to Clear_Memory() with this code:

// initialize memory to all zeros
_asm
lfsr 0, 0
movlw 0xF
clear_loop:
clrf POSTINC0, 0
cpfseq FSR0H, 0
bra clear_loop
_endasm


-Kevin

[Joe Ross]

Originally Posted by Kevin Watson

Ugh, I spoke with IFI last week and they're of the opinion that the 8.3 volt bug has been fixed. If this bug bites you again, please let IFI know (and if you don't mind, me too).

I did talk to IFI last year, after seeing the bug. However, they were busy fixing radios at that time. There was at least one other team with the problem as well.

You can read about what I found in this thread, starting at post 133. http://www.chiefdelphi.com/forums/sh...t=44954&page=9

[neutrino15]

I am currently in the process of testing the old configure.py makefile with this new code. Has anybody had success?

I use a mac, and seriously do not want to try and update mplab in vmware.. painful memories..

[Nathans]

Our mistake here is probably very silly and obvious, but the solution eludes us nevertheless.

We're trying to get the gryo and accelerometer working, but we get a build error when we try to use the Get_Analog_Value function.

gyro = Get_Analog_Value(rc_ana_in16);

The build error we get is:

Error [1105] symbol 'ADC_CH15' has not been defined

I've gotten as far as the fact that rc_ana_in16 is aliased to ADC_CH15, but no further.

[comphappy]

I am trying to figure out the encoder code, and do not understand how the code knows what way the shaft is turning,
void Int_1_ISR(void)
{
if(ENCODER_1_PHASE_B_PIN == 0)
{
Encoder_1_Count -= ENCODER_1_TICK_DELTA;
}
else
{
Encoder_1_Count += ENCODER_1_TICK_DELTA;
}
}

What really is ENCODER_1_PHASE_B_PIN?
And what port is this interrupt running one Input 1 or 2?

[billbo911]

Originally Posted by comphappy

I am trying to figure out the encoder code, and do not understand how the code knows what way the shaft is turning,
void Int_1_ISR(void)
{
if(ENCODER_1_PHASE_B_PIN == 0)
{
Encoder_1_Count -= ENCODER_1_TICK_DELTA;
}
else
{
Encoder_1_Count += ENCODER_1_TICK_DELTA;
}
}

What really is ENCODER_1_PHASE_B_PIN?
And what port is this interrupt running one Input 1 or 2?

When using a "Quadrature" encoder, there are two signals generated, Phase A and Phase B. Both are square waves with "B" 180 degrees out of phase from "A". When triggered by "A" going high, the ISR looks at "B", if it is low, you are going forward, if "B" is high you are going backward.
In the code it explains how to attach the A and B phases.

Now, if you are not using a quadrature encoder but one with a single output, like the GTS in the kit, then determining direction is a much bigger challenge although, not impossible.

[Kevin Watson]

Originally Posted by comphappy

I am trying to figure out the encoder code, and do not understand how the code knows what way the shaft is turning,
void Int_1_ISR(void)
{
if(ENCODER_1_PHASE_B_PIN == 0)
{
Encoder_1_Count -= ENCODER_1_TICK_DELTA;
}
else
{
Encoder_1_Count += ENCODER_1_TICK_DELTA;
}
}

What really is ENCODER_1_PHASE_B_PIN?
And what port is this interrupt running one Input 1 or 2?

Open up encoder.h and have a look at the comments for the answer to what ENCODER_1_PHASE_B_PIN is. Rotation direction is determined by the logic state of phase b on the rising edge of phase a. Have a look at this illustration for a diagram showing what the waveform looks like. If the encoder were spinning in the opposite direction, the phase b waveform in the illustration would be flipped top to bottom.

-Kevin

[comphappy]

Originally Posted by Kevin Watson

Open up encoder.h and have a look at the comments for the answer to what ENCODER_1_PHASE_B_PIN is. Rotation direction is determined by the logic state of phase b on the rising edge of phase a. Have a look at this illustration for a diagram showing what the waveform looks like. If the encoder were spinning in the opposit direction, the phase b waveform in the illustration would be flipped top to bottom.

-Kevin

I got what port it was hooked up to, I was just trying to figure out what phase b was, as the GTS does not have one, I will just modify the code so that instead of looking at phase b it will look at the PWM > or < 127 to determine the correct operand. I just need to determine the distance travailed on the linear drive.
Thank you for the diagram it was really useful. (BTW I like your code, it is clean and well organized)