New C18 3.0+ Compatible FRC Code

[Mike Mahar]

Originally Posted by 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.

The simple answer is don't use Get_Analog_value. The new code in adc.c should replace it. Instead you should call Get_ADC_Result. Make sure you set NUM_ADC_CHANNELS to the number of analog inputs you are using and allocate them starting with first one and go up from there.

The analog inputs are not instantaneous. You have to start them, then wait a certain amount of time and then read them. The code in adc.c will do that for you and uses a timer to wait. Calls to Get_ADC_Result will simply fetch the result that the library has already captured for you.

The function Get_Analog_value does the start/wait/read operation in-place and takes longer and consumes valuable cycles that could be put to better use doing something else.

[Mike Mahar]

Kevin, I have question about adc.c.
In Timer_4_ISR you have two for loops that cover the same range of indexes.

	if(samples >= adc_samples_per_update)
         	{
		// update the ADC result array
		for(i=0; i < num_adc_channels; i++)
		{
			adc_result[i] = (long)(accum[i] >> adc_result_divisor);
		}
		// reset the sample accumulator(s) to zero
		for(i=0; i < num_adc_channels; i++)
		{
			accum[i] = 0L;
		}
		// signal that a fresh sample set is available
		adc_update_count++;

		// start a fresh sample set
		samples = 0;
	}

Is there some reason that you don't reset the sample accumulator to 0 in the first loop?

if(samples >= adc_samples_per_update)
	{
		// update the ADC result array
		for(i=0; i < num_adc_channels; i++)
		{
			adc_result[i] = (long)(accum[i] >> adc_result_divisor);
                       // reset the sample accumulator to zero
                        accum[i] = 0L;
		}
	
		// signal that a fresh sample set is available
		adc_update_count++;

		// start a fresh sample set
		samples = 0;
	}

I'd think that any cycles saved in an ISR is a good thing.

[billbo911]

Originally Posted by comphappy

.... 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....

I have used this method in the past on my Vex bot. It works fairly well but is not perfect. For use in straight line driving, as in Hybrid mode, it should be sufficient. BTW, make sure you account for the dead-band associated with the Victor.

[Joe Ross]

Originally Posted by 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..

There have been at least two makefiles posted in this thread.

[Kevin Watson]

Originally Posted by Mike Mahar

Is there some reason that you don't reset the sample accumulator to 0 in the first loop?

Beats me. I'll have a look at it when I get home from work.

-Kevin

[Lafleur]

Kevin:

An idea...

A quick and dirty utilizations counter...

Add a global long integer to you project called "cycle". At the end of the while(TRUE) in main.c, do a cycle++ to build a loop counter, this will tell you how many time you have been in the while(TRUE) loop.

In the 26.4ms loop, read the cycle counter, clear it and divide by (264k clock cycles, the number of clock cycles in 26.4ms - the number of cycles used in the while(TRUE) ) This will give you a crude % utilization of the CPU that the teams can use to check on there code efficiency...


also, the counter could be scaled so that one could use an unsigned int

[Loki1989]

how exactically are we supposed to build in 7.21 with the c18 3.10 and now i can't just push F10 to build.

edit:

also when I open it it does not open correctly when I try to open the project files.

[Nathans]

Originally Posted by Mike Mahar

The simple answer is don't use Get_Analog_value. The new code in adc.c should replace it. Instead you should call Get_ADC_Result. Make sure you set NUM_ADC_CHANNELS to the number of analog inputs you are using and allocate them starting with first one and go up from there.

The analog inputs are not instantaneous. You have to start them, then wait a certain amount of time and then read them. The code in adc.c will do that for you and uses a timer to wait. Calls to Get_ADC_Result will simply fetch the result that the library has already captured for you.

The function Get_Analog_value does the start/wait/read operation in-place and takes longer and consumes valuable cycles that could be put to better use doing something else.

How do you allocate the analog inputs with Get_ADC_Result? I found where to set NUM_ADC_CHANNELS, but I haven't found anything about allocating specific inputs. Furthermore, what is used as the argument of Get_ADC_Result?

[Lafleur]

Originally Posted by Lafleur

Kevin:

An idea...

A quick and dirty utilizations counter...

Add a global long integer to you project called "cycle". At the end of the while(TRUE) in main.c, do a cycle++ to build a loop counter, this will tell you how many time you have been in the while(TRUE) loop.

In the 26.4ms loop, read the cycle counter, clear it and divide by (264k clock cycles, the number of clock cycles in 26.4ms - the number of cycles used in the while(TRUE) ) This will give you a crude % utilization of the CPU that the teams can use to check on there code efficiency...



also, the counter could be scaled so that one could use an unsigned int

an error in my logic....

you also need to take the number of loops and multiply by the number of cycles in the loop and use this to subtract from the total number of cycles in the 26ms...


tom lafleur

This is the code I did in a TEST module with only the ATD and Serial ports, I have a timer that interrupts me ever 100ms. I disable all interrupts and use the MPLAB simulator to measure the number of cycles in the main loop. In my case it was 42 cycles. Note, division is only by 10,000 and not 1,000,000 to give a % with out the need to multiply by 100, saving some cycles.

int util;
long int cycle = 0; is a global in the code, it needs to be long because of the multiplication need a long

in the main loop I have a cycle++;

// here we will calculate the % of the CPU we are using
// we are here every 100ms, that 1,000,000 cycles of the processor at 40MHz
// utilization = the number of times in the do nothing loop, * the number of cycles in
// the main loop. 42 is current number of cycles in main loop

util = 100 - ((cycle * 42)/10000);
cycle = 0;

[Kevin Watson]

Originally Posted by Lafleur

Kevin:

An idea...

A quick and dirty utilizations counter...

Add a global long integer to you project called "cycle". At the end of the while(TRUE) in main.c, do a cycle++ to build a loop counter, this will tell you how many time you have been in the while(TRUE) loop.

In the 26.4ms loop, read the cycle counter, clear it and divide by (264k clock cycles, the number of clock cycles in 26.4ms - the number of cycles used in the while(TRUE) ) This will give you a crude % utilization of the CPU that the teams can use to check on there code efficiency...


also, the counter could be scaled so that one could use an unsigned int

Cool. I've been thinking about adding a few cool features like a system clock (uS?, mS?, real time?) and scheduler. Perhaps I should start another thread for wish list items?

-Kevin

[wireties]

A Makefile (forced to call it Makefile.txt to upload) for Linux in included. I'm using cxoffice (a canned wine setup) but it can be easily altered to work with plain old wine or to run under Windoze. This compiled Kevin's latest stuff with no errors but with a bunch of signed/unsigned warnings. I have not run the code on the robot yet!


Enjoy

[bronxbomber92]

Hi,

EDIT - We've got a working install of mplab 8.00, but we can't seem to get 3.00 installed. We run through the installer fine, but it doesn't seem to actually install.. MPLAB is still using 2.40, and we can't find the installation directory of 3.00 - only 2.40.

I'm trying to install mplab 8.00 and the 3.0 compiler, I downloaded the software on the first post, and the tried running it over the install of mplab 7.20. It seemed to install, but now when ever we open mplab it says 8.00 is not enabled, but we can still use 7.20. How is the best way to install it and the compiler with pre-existing versions all ready installed?

[NetElemental]

Kevin, First of all thanks, this will be a great help.

Our team has a 2005 robot controller and operator interface mounted to a board for testing purposes when it is not practical to use the current robot controller (e.g., the current controller is on the robot, and the robot is being built or modified). We swapped out the libraries and linker files for the ones corresponding to the PIC18F8520, changed the target to the 8520, and tried to compile. We got this error(in your ifi_frc_gyro code, if it's relevant):

C:\Users\NetElemental\Documents\Code\ifi_frc_gyro\ifi_code.c:33:Error [1105] symbol 'ifi_analog_channels' has not been defined

inaccuracy

The line code corresponds to

29  #if defined(__18F8722)
30    OpenADC( ADC_FOSC_RC & ADC_RIGHT_JUST & ADC_0_TAD,
31             ADC_channel & ADC_INT_OFF & ADC_VREFPLUS_VDD & ADC_VREFMINUS_VSS,15);
32  #else
33    OpenADC( ADC_FOSC_RC & ADC_RIGHT_JUST & ifi_analog_channels,
34            ADC_channel & ADC_INT_OFF & ADC_VREFPLUS_VDD & ADC_VREFMINUS_VSS );
35  #endif

Any ideas? We couldn't find ifi_analog_channels in either .lib file. What would your suggestion be?

Thanks,
James

[Lafleur]

CPU Utilization

In a quick test I did today, using a ATD sample rate of 200Hz, I had 19% utilizations of the processor. Changing only the ATD sample rate to 6400Hz, utilization went to 43%.

[Kevin Watson]

Originally Posted by NetElemental

Kevin, First of all thanks, this will be a great help.

Our team has a 2005 robot controller and operator interface mounted to a board for testing purposes when it is not practical to use the current robot controller (e.g., the current controller is on the robot, and the robot is being built or modified). We swapped out the libraries and linker files for the ones corresponding to the PIC18F8520, changed the target to the 8520, and tried to compile. We got this error(in your ifi_frc_gyro code, if it's relevant):

C:\Users\NetElemental\Documents\Code\ifi_frc_gyro\ifi_code.c:33:Error [1105] symbol 'ifi_analog_channels' has not been defined

inaccuracy

The line code corresponds to

29  #if defined(__18F8722)
30    OpenADC( ADC_FOSC_RC & ADC_RIGHT_JUST & ADC_0_TAD,
31             ADC_channel & ADC_INT_OFF & ADC_VREFPLUS_VDD & ADC_VREFMINUS_VSS,15);
32  #else
33    OpenADC( ADC_FOSC_RC & ADC_RIGHT_JUST & ifi_analog_channels,
34            ADC_channel & ADC_INT_OFF & ADC_VREFPLUS_VDD & ADC_VREFMINUS_VSS );
35  #endif

Any ideas? We couldn't find ifi_analog_channels in either .lib file. What would your suggestion be?

Thanks,
James

Replace "ifi_analog_channels" with "ADC_15ANA" and it should compile.

-Kevin