View previous topic :: View next topic |
Author |
Message |
edbfmi1
Joined: 18 Jul 2006 Posts: 103
|
ADC not repeatable |
Posted: Thu Jun 26, 2008 10:18 am |
|
|
Hello again,
Compiler - PCM 3.249
microchip - PIC16C71
Emulator - PICMASTER
I am having a problem with my ADC routine.
I am using all 4 channels on my 16C71.
I have removed all of the other areas of my program and will include
only the main body and subroutine in question.
When I run the program the values for the 4 adc values (speed, ramp, off_delay, on_delay) are not constant. If a supply a steady signal to the associated pins the values of the read ADC can fluctuate by as much as +/- 10.
i.e. If i put in a rock solid 2.5V to the 4 analog pins (as verified by an o-scope) the values read can be anywhere from 115 to 135 when it should be 125.
Anyone see something obviouse I am missing???
Thanks,
Code: |
#include <16C71.h>
#fuses HS,NOWDT,NOPROTECT
#use delay(clock=4000000)
#BYTE intcon = 0x0B
int8 softstart; // speed offset time for soft starting
int8 ramp; // Ramp analog value
int8 on_delay; // on_delay analog value
int8 off_delay; // off_delay analog value
int8 speed; // speed pot analog input
int8 adc_delay_counter; // Counter used to allow the analog channals time to stablize
int8 channel_select; // used to select which RTD is being monitored
int8 StatusBits1;
#bit startup = StatusBits1.7
# separate
void Select_ADC()
{
delay_cycles(1);
switch(channel_select)
{
case 0: // Read Speed input
delay_cycles(1);
speed = read_adc();
if (speed <= 35) speed = 35;
if (speed >= 240) speed = 240;
delay_cycles(1);
break;
case 1: // Read ramp input
delay_cycles(1);
ramp = read_adc();
if (ramp < 5) ramp = 5;
delay_cycles(1);
if (speed >= 24)
{
softstart = speed - 22;
}
else
{
softstart = 23;
}
delay_cycles(1);
break;
case 2: // Read off_delay input
delay_cycles(1);
off_delay = read_adc();
if (off_delay >= 253) off_delay = 253;
if (off_delay <= 1) off_delay = 1;
delay_cycles(1);
break;
case 3: // Read on_delay input
delay_cycles(1);
on_delay = read_adc();
if (on_delay >= 253) on_delay = 253;
if (on_delay <= 1) on_delay = 1;
delay_cycles(1);
set_adc_channel(0);
if (startup == TRUE)
{
delay_cycles(1);
intcon = 0;
delay_cycles(1);
clear_interrupt(INT_EXT);
enable_interrupts(INT_EXT);
delay_cycles(1);
set_rtcc(1);
enable_interrupts(GLOBAL);
startup = FALSE;
set_rtcc(1);
}
break;
}
}
void main()
{
disable_interrupts(GLOBAL);
port_b_pullups(false);
SETUP_ADC_PORTS(ALL_ANALOG);
SETUP_ADC(adc_clock_div_32);
SETUP_TIMER_0(RTCC_INTERNAL|RTCC_DIV_32); // (4MHz Crystal)
SET_ADC_CHANNEL(0);
speed = 35;
StatusBits1 = FALSE;
channel_select = 3;
on_delay = 0;
off_delay = 0;
startup = TRUE;
while (1==1)
{
delay_cycles(1);
if (adc_delay_counter < 250)
{
delay_cycles(1);
adc_delay_counter++;
}
else
{
delay_cycles(1);
adc_delay_counter = 0;
if (channel_select < 3)
{
channel_select++;
}
else
{
channel_select = 0;
}
delay_cycles(1);
Select_ADC();
delay_cycles(1);
set_adc_channel(channel_select + 1 );
}
}
}
|
|
|
|
rnielsen
Joined: 23 Sep 2003 Posts: 852 Location: Utah
|
|
Posted: Thu Jun 26, 2008 10:41 am |
|
|
Each time you select a new channel you need to have a delay for the holding capacitor to charge to the new voltage level of the newly selected channel. I don't think the few clock cycles are enough time to allow this. Try placing a delay of at least 10us (possibly more) right after your channel select statement. If things are still a bit jittery try a larger delay and experiment with what works best.
Ronald |
|
|
edbfmi1
Joined: 18 Jul 2006 Posts: 103
|
|
Posted: Thu Jun 26, 2008 11:01 am |
|
|
I added a 100msec delay after the channel select as shown below but it did not help. Did I put it in the right place?
Code: |
set_adc_channel(channel_select + 1 );
delay_ms(100);
|
|
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Jun 26, 2008 11:56 am |
|
|
Make a very small program that tests only one channel. Cut out 90%
of your code (in fact, 95%). Then see if it works. If it doesn't, then
look for the reason. If it does work, then add a 2nd channel. Switch
between the channels. See if it works or fails. This will give you a clue
as to the problem. |
|
|
edbfmi1
Joined: 18 Jul 2006 Posts: 103
|
|
Posted: Thu Jun 26, 2008 12:53 pm |
|
|
Ok I simplified the program to as simple as possible.
I still get random values (+/- 10 of what is to be expected)
I did verify my dc signal at the analog pin and it is a rock solid 2.5Volts
Any ideas??
Code: |
#include <16C71.h>
#fuses XT,NOWDT,NOPROTECT
#use delay(clock=4000000)
int8 ramp; // Ramp analog value
int8 on_delay; // on_delay analog value
int8 off_delay; // off_delay analog value
int8 speed; // speed pot analog input
void main()
{
disable_interrupts(GLOBAL);
port_b_pullups(false);
SETUP_ADC_PORTS(ALL_ANALOG);
SETUP_ADC(adc_clock_div_32);
SETUP_TIMER_0(RTCC_INTERNAL|RTCC_DIV_32); // (4MHz Crystal)
SET_ADC_CHANNEL(0);
on_delay = 0;
off_delay = 0;
ramp = 0;
speed = 0;
while (1==1)
{
delay_cycles(1);
set_adc_channel(0);
delay_ms(100);
delay_cycles(1);
speed = read_adc();
delay_cycles(1);
}
}
|
|
|
|
edbfmi1
Joined: 18 Jul 2006 Posts: 103
|
|
Posted: Thu Jun 26, 2008 1:17 pm |
|
|
I figured it out!!!
After studying the code I was sure it was good so burned a chip with the code.
The sytem worked just as expected.
The problem was in the emulator not the code.
Thanks again for the help.
Have a blessed day all. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
|
libor
Joined: 14 Dec 2004 Posts: 288 Location: Hungary
|
|
Posted: Sat Jun 28, 2008 10:19 am |
|
|
Sorry for the off-topic question.
These C series are one-time-programmable chips, aren't they ? I imagined ...I would never dare to say my program code is finished and perfect*, and program it once for eternity.
I am just wondering what might be the reason to use an OTP device nowadays when there are so many flash devices available ?
You just had such a chip laying around, or are there some other advantage I am not aware of to use a C series chip for a project?
* a second thought: an OTP device might have a good effect on my productivity. With these flash devices my projects are never ready, I keep constantly rasping on their code... |
|
|
edbfmi1
Joined: 18 Jul 2006 Posts: 103
|
|
Posted: Sat Jun 28, 2008 2:38 pm |
|
|
As far as using the OTP chips. I have been writing code for Pic Micros since the early 90's. (Mostly in assembly code.) I have several thousand $$ wrapped up in emulators, probe heads, programmers etc for the C series micros. I tried to use the ICD2 and a new flash chip for this project but I could not get it to work, even with the help of this forum.
See this link. http://www.ccsinfo.com/forum/viewtopic.php?t=35043&highlight=
Due to the fact that I only make a profit when I sell something there comes a point in time when it has to be "finished" but might not be "perfect." If we had to wait until things wre perfect Microsoft would still be in the development stage - which probably would be a good thing come to think of it.
Anyway I needed to drop back to the "C" series chip and my old emulator to complete the project.
I would love to migrate to the newer Flash chips. If anyone has a recommendation for a good Emulator or ICD I would love to hear about it |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Sun Jun 29, 2008 6:11 am |
|
|
When I started working with PICs, many years ago, there were no flash chips and C chips came with and without erasing windows. You developed code on a windowed (expensive and thick) chip till the code was shippable. Then you burned non-windowed chips for the final product.
Some of the products we are still selling were designed 15 or 20 years ago and the parts lists still specify C series chips. If it ain't broke, don't fix it. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
Humberto
Joined: 08 Sep 2003 Posts: 1215 Location: Buenos Aires, La Reina del Plata
|
|
Posted: Sun Jun 29, 2008 7:21 am |
|
|
edbfmi1 wrote:
Quote: |
As far as using the OTP chips. I have been writing code for Pic Micros since the early 90's.
(Mostly in assembly code.) I have several thousand $$ wrapped up in emulators, probe
heads, programmers etc for the C series micros.
|
edbfmi1, I also used to work with those windowed and OTP chips, used to work with those
emulator tools and I started coding in assembler too. Every one of all these enumerated
stuffs + the odd behaviour of the early C Compilers are the responsible of most the white
hairs that I actually have.
You will get all the new available tools, C Compiler (it is by far more stable than the old ones)
+ ICD (CCS or Microchip IDE) at a fraction of the money that you spent, with the advantage
that you can save a lot of time in the test & debugging stage, that is the most time consuming.
For ANY reason I would'nt put my hand in those tools again.
Humberto |
|
|
edbfmi1
Joined: 18 Jul 2006 Posts: 103
|
|
Posted: Sun Jun 29, 2008 9:24 am |
|
|
Humberto wrote:
Quote: |
You will get all the new available tools, C Compiler (it is by far more stable than the old ones)
+ ICD (CCS or Microchip IDE) at a fraction of the money that you spent, with the advantage
that you can save a lot of time in the test & debugging stage, that is the most time consuming.
|
What tools are you talking of? I tried for several weeks to use the ICD2 from microchip along with CCS version 4.011 and the PIC16F716.
I "upgraded" to the version 3.249 (similar to the Vista to XP upgrade) at the advise of Ttelmah in the link I talked about earlier in this post but sitll had troubles.
I could not get it to debug even a simple program that looked at one input and change one output. If you analyzed the .lst you would see that the compiler seemed to compile it correctly but the ICD2 would not follow during the debug process.
I would be very interested to hear your opinions on what a good system would be. I am willing to spend the $$ to get a new development system that can cut down on my time to market for new products and take advantage of what the "F" parts have to offer.
Thanks, |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
|
libor
Joined: 14 Dec 2004 Posts: 288 Location: Hungary
|
|
Posted: Sun Jun 29, 2008 12:46 pm |
|
|
Quote: | I could not get it to debug even a simple program that looked at one input and change one output. |
In similar situations I usually get help from Occam's razor to close in on the problem. What is more likely ?
1. Microchip is continuing to sell over 2 billion pieces of chips making a multibillion dollar revenue in a tight competition with TI, Intel, Samsung, Renesas, Freescale, ST, Atmel, and other microcontroller makers with a totally undebuggable (ie. incompetitive) product line.
2. I have made some errors |
|
|
edbfmi1
Joined: 18 Jul 2006 Posts: 103
|
|
Posted: Sun Jun 29, 2008 3:04 pm |
|
|
Libor:
I admit I do make mistakes but I am capable of following directions and writing simple single in/single out code.
I beg to differ with your logic that just because a company sells a lot of product it must be bug free. That would mean that we should never have a problem with a computer, an operating system, an ipod, a car, software, etc ........
All I am saying is that I sell several thousand custom controls every year. Before I am willing to put my name on them they ARE bug free and the users of my systems do not have to spend countless hours trying to make a buggy first release work. (e.g. version 4.011 of the PCM compiler) The PCM issues are well discussed in the sticky note under the General CCS C Discussion.
On the rare occasion they do have a question with one of our systems they can get through to technical support (usually me) with one phone call.
No voice mail, no FAQ, No "Please Press 1 for English" phone mazes...
I do not make them rely on my customer base and Customer Forum for advise on my products.
Yes I am frustrated with the level of support I get from CCS and Microchip. But Intel Atmel and the rest offer similar "Customer Non-Support" so I will stick with what I am using and make the best of it. |
|
|
|