Analog-to-Digital Converter Code

[Kevin Watson]

For those who might be interested, I've just posted new analog-to-digital converter interface code for IFIs robot controllers. A few advantages of using this software include parallel, non-blocking operation of the ADC hardware, precise control over the sampling period, which is important for signal processing and control applications and the ability to make measurements with greater precision using a technique called oversampling. The code can be found here: http://kevin.org/frc. As always, if you find a bug in the code or a problem with the documentation, please let me know.

-Kevin

Here's the readme file:


The source code in adc.c/.h contains software to setup and run
your robot controllers analog-to-digital converter in the
background. A few advantages of using this software include
parallel, non-blocking operation of the ADC hardware, precise
control over the sampling period, which is important for signal
processing and control applications and the ability to make more
precise measurements using oversampling. Number of channels,
sample rate and oversampling parameters can be changed by
editing adc.h and re-compiling.

This software makes the assumption that when it's running, it
solely controls the analog to digital conversion hardware.

WARNING: The higher sampling rates can place quite a load on
the robot controllers CPU. If you get the red-light-of-death
or notice any general wackiness in the operation of your
robot, first try a lower sampling rate to determine if this
is the problem. In general, you should select the lowest
sampling rate that meets your performance criteria.

This source code will work with the Robovation (A/K/A EDU-RC)
robot controller and the FIRST Robotics robot controller.

The included project files were built with MPLAB version 7.20.
If your version of MPLAB complains about the project version,
the best thing to do is just create a new project with MPLAB's
project wizard. Include every file except: FRC_alltimers.lib
and ifi_alltimers.lib and you should be able to build the code.

************************************************** **************

Eight things must be done before this software will work
correctly with your robot controller:

1) A #include statement for the adc.h header file must be
included at the beginning of each source file that calls the
functions in adc.c. The statement should look like this:
#include "adc.h".

2) Initialize_ADC() must be called from user_routines.c/
User_Initialization().

3) On the EDU-RC, all analog inputs must be configured as
INPUTs in user_routines.c/User_Initialization().

4) The call to Set_Number_of_Analog_Channels() must be removed
or commented out in user_routines.c/User_Initialization().

5) The timer 2 interrupt handler, Timer_2_Int_Handler(), and
ADC interrupt handler, ADC_Int_Handler(), must be installed in
User_Routines_Fast.c/InterruptHandlerLow(). See the included
copy of User_Routines_Fast.c to see how this is done.

6) Define the number of analog channels that you'd like this
software to track by opening adc.h and following the embedded
instructions above #define NUM_ADC_CHANNELS.

7) For advanced users, analog channels can be oversampled to
decrease noise and gain resolution in your analog measurements.
The oversampling ratio can be changed from the default x16
by commenting-out the line #define ADC_SAMPLES_PER_UPDATE_16
found in adc.h and then removing the // from in front of one
of the other options. Measurement range and resolution can be
determined from this table:

ADC Samples Effective
Averaged Bits of Measurement Voltage
Per Update Resolution Range Per Bit
___________ __________ ___________ _________
1 10 0-1023 4.88 mV
2 10 0-1023 4.88 mV
4 11 0-2047 2.44 mV
8 11 0-2047 2.44 mV
16 12 0-4095 1.22 mV
32 12 0-4095 1.22 mV
64 13 0-8191 610 uV
128 13 0-8191 610 uV
256 14 0-16383 305 uV

8) Finally, pick the master sample rate by selecting one
of the available rates found in adc.h. The update rate can
be determined using this formula:
Update Rate =
Sample Rate / (Samples Per Update * Number Of Channels)

************************************************** **************

Here's a description of the functions in adc.c:

Get_ADC_Result_Count()
This function returns an unsigned char containing the number
of ADC updates generated since Reset_ADC_Result_Count() or
Initialize_ADC() were called. Use this function to determine
when fresh analog to digital conversion data is ready.

Reset_ADC_Result_Count()
This function can be called to reset the ADC update counter
to zero.

Get_ADC_Result()
This function can be called to retreive analog to digital
conversion results. Call this function with an unsigned char
containing the ADC channel you'd like data from. This function
will return an unsigned int with the last conversion result.

Convert_ADC_to_mV()
This function converts the value generated by the ADC to
millivolts.

Initialize_ADC()
This function initializes the ADC hardware and software. It
should be called from user_routines.c/User_Initialization().
Once called, analog to digital conversions will automatically
take place in the background.

Disable_ADC()
This function disables the ADC hardware and software. To
minimize the load on the microcontroller, this function should
be called when the ADC functionality is no longer needed.

Initialize_Timer_2()
This function initializes and starts timer 2, which initiates
a new analog to digital conversion each time the timer 2
interrupt service routine is called. This is called by
Initialize_ADC() above and shouldn't be called directly.

Disable_Timer_2()
This function is called from Disable_ADC() to disable timer 2
and shouldn't be called directly.

Timer_2_Int_Handler()
This function is automatically called when timer 2 causes an
interrupt and shouldn't be called directly. New analog to
digital conversions are initiated from this function.

ADC_Int_Handler()
This function is automatically called when new analog to
digital conversion data is ready and shouldn't be called
directly.

[mechanicalbrain]

wow thanks allot!

[Kevin Watson]

I've updated the ADC code to version 0.3. The new version uses the "special event trigger" functionality of the CCP2 module to automatically start an analog to digital conversion without software intervention. This new version generates half of the interrupts/sec of version 0.2. As always, the code can be found here: http://kevin.org/frc

-Kevin

[Kevin Watson]

Well, I finally posted (http://kevin.org/frc) the ADC and Gyro code for the 2006 robot controller. Sorry about the delay, but I ran into a nasty bug that caused me to spend a few days in the fourth and fifth levels of programmer hell. The bug was in the design of the PIC18F8722 (yes, a bug in the sillicon) and I had to figure out what was going on. Anyway, the gyro code works really, really well with the gyro in the kit of parts. The accelerometers also work really well, but I need to do more testing before I unleash that code.


-Kevin

[Joel J]

Let's suppose there are four analog signals being sampled and "buffered" by your code. The gyro is running on ADC_CH0 and the other three channels are for other devices. How do we know when the gyro specifically has new data available? I saw the ~update_count~ variable, but it seemed to just indicate when any new sample is available, not when the sample for a specific channel is. Am I going to have to modify your code (maybe add an array of update_counts, with each index correspondent with the channel's freshness of data?) to allow this functionality, or is it already there and I'm just not seeing it?

[Kevin Watson]

Let's suppose there are four analog signals being sampled and "buffered" by your code. The gyro is running on ADC_CH0 and the other three channels are for other devices. How do we know when the gyro specifically has new data available? I saw the ~update_count~ variable, but it seemed to just indicate when any new sample is available, not when the sample for a specific channel is. Am I going to have to modify your code (maybe add an array of update_counts, with each index correspondent with the channel's freshness of data?) to allow this functionality, or is it already there and I'm just not seeing it?The update flag only gets incremented after all enabled ADC channels have been refreshed. You can get less latency (if that's what you're after) by doing the modification you described, or by just moving the gyro to the last enabled channel and continue using Get_ADC_Result_Count().

-Kevin

[PhilBot]

Hi Kevin...

Excellent code. I'm trying to get some early Auto-Heading code testing done using an existing Robot. I was hoping I could use the team's little 2003 EDU robot as a test platform.

I'm an experienced embedded programmer, but new to the IFI hardware.

I tried deploying your gyro code on the small EDU controller. I discovered that when I included the new ADC module I got a program run error light, so I dropped back to the standard iti_utilities code for the ADC conversion. (I assumed a basic hardware incompatibility....)

My only problem is that now I'm not sure where to put the call to Process_Gyro_Data().

I'd like to put it in User_Routines_Fast.c but I don't have your ADC code installed so I don't know when the converters have got new values. D'oh.

Am I flogging a dead horse here, or is there a simple way to use the standard IFI analog utilities to drive your Gyro code? I'm only using a single analog channel (for the Gyro) so that may simplify things. I don't need fully calibrated data for my initial testing... I just need it to basically run. If I can get the calls IN, I can get the rest to work.

Thanks for your time.
Phil.


Well, I finally posted (http://kevin.org/frc) the ADC and Gyro code for the 2006 robot controller. .

-Kevin

[Kevin Watson]

Hi Kevin...

Excellent code. I'm trying to get some early Auto-Heading code testing done using an existing Robot. I was hoping I could use the team's little 2003 EDU robot as a test platform.

I'm an experienced embedded programmer, but new to the IFI hardware.

I tried deploying your gyro code on the small EDU controller. I discovered that when I included the new ADC module I got a program run error light, so I dropped back to the standard iti_utilities code for the ADC conversion. (I assumed a basic hardware incompatibility....)

My only problem is that now I'm not sure where to put the call to Process_Gyro_Data().

I'd like to put it in User_Routines_Fast.c but I don't have your ADC code installed so I don't know when the converters have got new values. D'oh.

Am I flogging a dead horse here, or is there a simple way to use the standard IFI analog utilities to drive your Gyro code? I'm only using a single analog channel (for the Gyro) so that may simplify things. I don't need fully calibrated data for my initial testing... I just need it to basically run. If I can get the calls IN, I can get the rest to work.

Thanks for your time.
Phil.Phil,

Gyro code for the EDU-RC can be found on my website.

-Kevin

[PhilBot]

Oops.

I'm in "drinking from a fire-hose" mode and never seem to look in the right place for information. Just when I think I've downloaded enough... I find more.. After posting, I discovered your adc_readme file which let me go through and add your stuff to our teem's prior EDU-RC code. Now I don't get an error & the gyro seems to be working as with the 2006RC.

Now with this new information I can double check against your webiste archives if need be.

Thanks.
I'll look harder next time.
Phil

Phil,

Gyro code for the EDU-RC can be found on my website.

-Kevin

[Der Rowan]

Hello all,

First off, I want to thank kevin for writing this code.
This *should* help us use all those sensors we just looked at and admired last year as rookies.

Unfortunately, our team is not gifted with a large number (read - 0) dedicated programmers. So I'm not too far ahead of the kids at this point which disappoints me because I cant really help them the way I should be (when I barely know anything myself).

But I did read all the readme.txt files associated with the code Kevin's supplied, and I have 2 main questions which deal with getting the code and hardware on the same page.

1. After I hook up my PWMs to the sensor (take your pick) and plug it into the RC's analog input, how do I make the code know which port I'm looking at?

and

2. How do I test / troubleshoot / even see the output from the sensor?
Is there some easy way to use a "print to a .txt file" or something? (something I'd try on a PC) Better yet, what is the BEST way to get all the information? I'm seeing outputs in some of these posts mentioning the same kind of scaling that you see when you output to one of the motors. So should I find some way to get the info back to the dashboard (which I still need to set up). Even with that, we need to integrate (for many of the sensors) and seeing the value at any one time wont tell us too much.

Hope I'm not being too redundant or posting in the wrong place. If any of my questions indicate that I'm just fundamentally wrong, point that out too, please.

It's all for the kids and the future,
Aaron

[Dave75]

Well, I finally posted (http://kevin.org/frc) the ADC and Gyro code for the 2006 robot controller. ...
Kevin,

The adc_readme.txt says to remove the call to Set_Number_of_Analog_Channels() in user_routines.c. But the user_routines.c file included in the same zip (frc_adc.zip) still has it in. Same situation in the user_routines.c file in the frc_gyro.zip.

So, should the call remain as is, or be commented out?

Thanks

[Kevin Watson]

Kevin,

The adc_readme.txt says to remove the call to Set_Number_of_Analog_Channels() in user_routines.c. But the user_routines.c file included in the same zip (frc_adc.zip) still has it in. Same situation in the user_routines.c file in the frc_gyro.zip.

So, should the call remain as is, or be commented out?

ThanksHmmm... I guess I should follow my own instructions <grin>. Actually, it doesn't matter as long as the call to Initialize_ADC() happens after the call to Set_Number_of_Analog_Channels() (it does in all the ADC-related code I've posted). If you're happy with my code, I'd just remove the call to Set_Number_of_Analog_Channels(), otherwise just comment it out in case you want to fall back to IFI's code.

-Kevin

[Chriszuma]

Okay, I know this is getting kind of abstract, and not truly necessary to a "black box" understanding of this code, but how exactly does oversampling work? I looked it up on wikipedia, and all i got was more confused. I understand that is is supposed to give more precision, but I really don't understand how.

Thanks.

[Alan Anderson]

Oversampling is essentially taking a number of samples and averaging them. If you average four samples, you get the equivalent of two more bits of resolution, but it takes four times as long to get the value. It trades time for precision.

[Chriszuma]

so then does it take values 4x faster? It seems like taking the average over 4 program cycles would make it less precise.

[Joel J]

Yes, it samples faster than the rate the data is being sent.

I have another question for Kevin (of course, I'm trying to optimize everything, but I don't want to make a bad move while doing this):

Is there a specific reason for switching from doing both the initiation of and saving of an ADC sample in the timer interrupt? I remember in last year's gyro code that both functions were done in the same place, whereas now you are using both the timer interrupt, and the ADC interrupt to take the samples. Is it safe to kinda shift the ADC functionality to the timer interrupt and reduce the extra overhead by removing the ADC interrupt altogether? Or do the two of them together execute faster, somehow, than the single timer?

Before you:
- Started the initial A/D conversion in Initialize_XXXX()
- Saved the value at the start of the timer2 interrupt
- Did the if/else/etc to put the value in the right place
- Started another A/D conversion by setting the GO bit.
- Exited the timer2 interrupt.

And if I get the go ahead, I'll just do this again.

[Joe Ross]

so then does it take values 4x faster? It seems like taking the average over 4 program cycles would make it less precise.

The following whitepaper goes much more in depth and may make more sense: http://www.chiefdelphi.com/forums/papers.php?s=&action=single&paperid=234

[mgurgol]

Well, I finally posted (http://kevin.org/frc) the ADC and Gyro code for the 2006 robot controller. Sorry about the delay, but I ran into a nasty bug that caused me to spend a few days in the fourth and fifth levels of programmer hell. The bug was in the design of the PIC18F8722 (yes, a bug in the sillicon) and I had to figure out what was going on. Anyway, the gyro code works really, really well with the gyro in the kit of parts. The accelerometers also work really well, but I need to do more testing before I unleash that code.


-Kevin
I have downloaded the FRC_GYRO code, compiled and linked it in MPLAB, and it controls the gyro great, thanks.

When I copy the FRC_Library into my 2006 project code (to update from the 8250 (2005) to the 8722 (2006) controller, I am getting a link error saying that symbol ifi_packet_num1 has multiple definitions. I was able to determine that there is a copy of ifi_utilities.o (where ifi_packet_num1 is defined) in the FRC_Library (that wasn't there in 2005). I was able to work around the problem by removing ifi_utilites.c from the project, and it linked fine.

My question is: Is there some setting I am missing in my project that would allow the linker to use the first instance of the object file it comes across versus including all versions. I see ifi_utilities.c in the frc_gyro (gyro.mcp) project, and the link works correctly. Since I don't modify ifi_utilities.c my work around shouldn't be a problem, but I would like to know why one project will link correctly, while another one won't.

Thanks, Mark

[Chriszuma]

The following whitepaper goes much more in depth and may make more sense: http://www.chiefdelphi.com/forums/papers.php?s=&action=single&paperid=234
Wow, that really explained it well. Thanks.

[Joel J]

Yes, it samples faster than the rate the data is being sent.

I have another question for Kevin (of course, I'm trying to optimize everything, but I don't want to make a bad move while doing this):

Is there a specific reason for switching from doing both the initiation of and saving of an ADC sample in the timer interrupt? I remember in last year's gyro code that both functions were done in the same place, whereas now you are using both the timer interrupt, and the ADC interrupt to take the samples. Is it safe to kinda shift the ADC functionality to the timer interrupt and reduce the extra overhead by removing the ADC interrupt altogether? Or do the two of them together execute faster, somehow, than the single timer?

Before you:
- Started the initial A/D conversion in Initialize_XXXX()
- Saved the value at the start of the timer2 interrupt
- Did the if/else/etc to put the value in the right place
- Started another A/D conversion by setting the GO bit.
- Exited the timer2 interrupt.

And if I get the go ahead, I'll just do this again.
As I was waiting for your reply I took a look at the spec sheet for the PIC18f8722. It says there is a set delay of at least 2.5 microseconds that has to exist between the setting of an analog channel and the initiation of its conversion (to allow the sample and hold capacitor to start charging). Is this the reason for the seperation of the two actions?

I also see the following:
Acquisition time may be set with the ACQT2:ACQT0 bits (ADCON2<5:3>) which provides a range of 2 to 20 TAD. When the GO/DONE bit is set, the A/D module continues to sample the input for the selected acquisition time, then automatically begins a conversion. Since the acquisition time is programmed, there may be no need to wait for an acquisition time between selecting a channel and setting the GO/DONE bit. which makes it seem as though the PIC could implement a delay by itself. But taking another look at your code, I noticed that you enabled manual acquisition (ADCON2<5:3> = 0). Did you find the PIC to be unreliable in this area, or have I totally missed the point?

I'll wait for your feedback before continuing.

[Kevin Watson]

Yes, it samples faster than the rate the data is being sent.

I have another question for Kevin (of course, I'm trying to optimize everything, but I don't want to make a bad move while doing this):

Is there a specific reason for switching from doing both the initiation of and saving of an ADC sample in the timer interrupt? I remember in last year's gyro code that both functions were done in the same place, whereas now you are using both the timer interrupt, and the ADC interrupt to take the samples. Is it safe to kinda shift the ADC functionality to the timer interrupt and reduce the extra overhead by removing the ADC interrupt altogether? Or do the two of them together execute faster, somehow, than the single timer?

Before you:
- Started the initial A/D conversion in Initialize_XXXX()
- Saved the value at the start of the timer2 interrupt
- Did the if/else/etc to put the value in the right place
- Started another A/D conversion by setting the GO bit.
- Exited the timer2 interrupt.

And if I get the go ahead, I'll just do this again.



This is a great question. When I modified the code last Summer to separate the ADC and gyro functionality, I added the ability to sample multiple ADC channels using a simple round-robin algorithm. If you read the pic18f8520 data sheet you'll notice the second paragraph on page 217 which states: "After the A/D module has been configured as desired, the selected channel must be acquired before the conversion is started...To determine acquisition time, see Section19.1 “A/D Acquisition Requirements”. After this acquisition time has elapsed, the A/D conversion can be started."

What this means is that you need to allow sufficient time for the sample-and-hold capacitor to charge between the time you change the channel and can actually start the conversion. Providing this delay within an ISR is, to say the least, un-cool. My solution was to start the conversion using the timer 2 ISR and manage data and change the ADC channel in the ADC ISR. The sample-and-hold capacitor then has ample time to charge between the ADC and timer 2 ISRs. This is how the currently posted code works.

The pic18f8722, used in the current robot controller, has added circuitry to automatically provide the acquisition delay before conversion begins (see page 277 of the p18f8722 data sheet). In the next revision of the ADC code I suspect that I'll be able to do away with the ADC interrupt and do everything in the timer 2 ISR. Perhaps this would be a good programming exercise for you?

-Kevin

[Joel J]

ok, great!

I'll modify your code for use now, and then I'll swap in your next revision when you make it gold.

Thanks for the feedback.

[McLOVIN]

For some reason our team is having great difficulty in getting the analog inputs to work, no matter what we plug into the inputs or print. We have initialized them and receive no errors yet no inputs are received. We have attempted testing a gyro, accelerometer, ultrasonic sensor, and variable resistor (potentiometer) but none have made a difference.

[lukevanoort]

For some reason our team is having great difficulty in getting the analog inputs to work, no matter what we plug into the inputs or print. We have initialized them and receive no errors yet no inputs are received. We have attempted testing a gyro, accelerometer, ultrasonic sensor, and variable resistor (potentiometer) but none have made a difference.
There is a #define statement in adc.h that is something like NUMBER_OF_CHANNELS (I'm going from memory here, so I don't know exactly what the statement actually defines). Is that defined as 16? We had some analog input trouble last year when we only had 1 channel active and were trying to tune four PID loops using pots that were connected to analog ports that weren't enabled, which didn't work very well, but caused no compile-time errors.

[McLOVIN]

Actually that wasn't the problem, but we seem to have fixed it. Our problem actually was that the interrupt Timer_4_ISR was defined in both adc.c, adc.h and timers.c and .h. No errors appeared but it didnt allow inputs.

[Kevin Watson]

Actually that wasn't the problem, but we seem to have fixed it. Our problem actually was that the interrupt Timer_4_ISR was defined in both adc.c, adc.h and timers.c and .h. No errors appeared but it didnt allow inputs.This is documented in the readme.txt file included with the software. Specifically, items 2 and 3:


By default the analog to digital and gyro software is disabled.
Perform these steps to get your gyro working:
1) Enable the Initialize_ADC() and Initialize_Gyro() functions in
teleop.c/Initialization().
2) Enable the timer 4 interrupt service routine in ifi_frc.h
3) Make sure timer 4 is disabled at the top of timers.h.
4) Depending on the operating modes you will be using the gyro,
place calls to the Process_Gyro_Data() function in the disabled.c/
Disabled_Spin(), autonomous.c/Autonomous_Spin() and/or teleop.c/
Teleop_Spin() functions.
5) Add gyro bias calibration code that will execute before you
use your gyro. Example calibration code has been placed in
disabled.c/Disabled() that can be used for the competition (this
requires that you use a mode dongle to emulate the field
controller, which will put you in disabled mode for a period of
time before transitioning to autonomous mode). For testing
purposes you can also use the example code in teleop.c/Teleop()
to make sure your gyro is working.
6) Follow the instructions in adc_readme.txt, adc.h, gyro_readme.txt,
and gyro.h for information related to installation and calibration
of your gyro.
7) If building for the 2004 or 2005 PIC18F8520 based robot controller,
you will need to use the adc_8520.c source file instead of adc.c.
The header file adc.h will work with either version.
8) If building for the 2004 or 2005 PIC18F8520 based robot controller,
you will need to enable the ADC interrupt service routine in
ifi_frc.h


-Kevin

[windell747]

Hi Kevin, We have recently come to realize that the p1_y and p1_x ADCs are somewhat noisy. The output value varies randomly maybe about +/-10 of 127 when the joystick is connected, but not touched. Does your code address this problem? We were trying to work around the problem using a comb digital filter.

Thanks,
Windell

[Kevin Watson]

Hi Kevin, We have recently come to realize that the p1_y and p1_x ADCs are somewhat noisy. The output value varies randomly maybe about +/-10 of 127 when the joystick is connected, but not touched. Does your code address this problem? We were trying to work around the problem using a comb digital filter.

Thanks,
WindellNo, that code runs on the PIC inside the operator interface, which I didn't write. I would try using a running average of 2-4 samples to see if it quiets down.

-Kevin

[srinivas]

This is a great question. When I modified the code last Summer to separate the ADC and gyro functionality, I added the ability to sample multiple ADC channels using a simple round-robin algorithm. If you read the pic18f8520 data sheet you'll notice the second paragraph on page 217 which states: "After the A/D module has been configured as desired, the selected channel must be acquired before the conversion is started...To determine acquisition time, see Section19.1 “A/D Acquisition Requirements”. After this acquisition time has elapsed, the A/D conversion can be started."

What this means is that you need to allow sufficient time for the sample-and-hold capacitor to charge between the time you change the channel and can actually start the conversion. Providing this delay within an ISR is, to say the least, un-cool. My solution was to start the conversion using the timer 2 ISR and manage data and change the ADC channel in the ADC ISR. The sample-and-hold capacitor then has ample time to charge between the ADC and timer 2 ISRs. This is how the currently posted code works.

The pic18f8722, used in the current robot controller, has added circuitry to automatically provide the acquisition delay before conversion begins (see page 277 of the p18f8722 data sheet). In the next revision of the ADC code I suspect that I'll be able to do away with the ADC interrupt and do everything in the timer 2 ISR. Perhaps this would be a good programming exercise for you?

-Kevin

Hello Kevin
When our team is using your FRC gyro code. there seems to be a problem. The motors are twitching. That is the arm and shoulder motors are coming back but are not staying in there.
Can u please tell us what to do about that. We caliberated the victors and checked the victors and checked the voltages. But when we use the default code without gyros the code works fine.

Please let us know what is happenning.

Thank you
Srinivas

[Joe Ross]

Hello Kevin
When our team is using your FRC gyro code. there seems to be a problem. The motors are twitching. That is the arm and shoulder motors are coming back but are not staying in there.
Can u please tell us what to do about that. We caliberated the victors and checked the victors and checked the voltages. But when we use the default code without gyros the code works fine.

Please let us know what is happenning.

Thank you
Srinivas

What PWMs are your victors connected to? PWMs 13-16 are controlled by the user processor and subject to glitches under high load when using IFI's Generate_PWMs function. If you move those motors to another PWM or use Kevin's replacement PWM code, it should work better.