pic18f4550 ADC Problem.....

am building a sound card like device that supports multiple inputs...
in brief, the device connects to a pc via usb. a sound source is connect the analog channel 0 with anti-aliasing filter(a butterworth low pass filter of 5120Hz). the point is to convert the analog audio into the pc via the usb ports.
the usb communications works very fine,i've also coded a pc application to write the wave file, the analog converter on the pic is working except that i am not getting the results i want...
the pc generated sound file seems to be running too slow, changing the sampling rate doesn't fix the problem.
the pic18f4550 doesn't have a bipole analog converter, also i didn't succeded to use the Vref+,Vref- on it (in fact it worked but the results were very unacceptable).
so the pic doesn't accept the negative voltage from the sound source it's only converting the positive alternance and missing the negative one!! is this is the problem ?? or i am missing something else ????
i can upload both of the wave files(the original and the generated one) may be it could help.....
i've also tried mounting two resistors in series, i took the anlog input of the pic from the middle, from one end i've connected the audio source and from the other end i've connected a positive supply voltage in order to raise the signal level above the ground reference of the pic, when testing the pic keeps restarting, i've placed a capacitor in series with the pic analog input and tested again, the result was a worst wave file than the first one.....
any help will be highly appreciated....
thanks in advance
LVL 2
selim007Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

markps_1Commented:
Regarding the half wave that you are converting... you need to filter input to positive bias the wave to prevent cut off.

 If you say it is running slow.. Something is going wrong on the conversion.. if you are oversampling.. Make sure you are saving the wave file with the correct sampling rate settings.

http://www.ise.pw.edu.pl/~wzab/picadc/picadc.html
http://arts.ucsc.edu/ems/music/tech_background/TE-16/teces_16.html
http://www.pan.com/earlevel/Digital%20Audio/index.html
http://www.digital-recordings.com/publ/pubrec.html
0
d-glitchCommented:
Several questions:

What is your sampling rate?  I don't see it in the question.
How many poles on your anti-alias filter?  You may need 6 or more to really do the job.

What is amplitude of your audio input signal?  And what does the ADC do if you overload it?  Sometimes they can take a while to recover.  This would mess up the sampling.

It is certainly possible that you are recording only the positive side of the audio signal.  This would sound bad, but it should still be intelligible.  

You might try AC coupling the audio signal to the ADC input.  You just need a capacitor and a pair of resistors to bias the input pin at half the power supply voltage.  You would have to subtract the bais voltage to get back to a bipolar signal.  And you really have to make sure that your amplitude isn't too large.
0
selim007Author Commented:
Dear all,
first thanks for your reply.
markps_1:
as for the oversampling on the pic side(while converting analog to digital),if it occurs, changing the sampling rate of the generated pc wave file will fix the problem which is not my case. in fact i've tried changing it but it's not working....
do you think that oversampling the analog input will produce an output that can't be corrected by changing the wave file sampling rate ??
 d-glitch :
the pic program is generating 22ksps i've alsotried slower sampling rates but always the same results.
the filter is a 3rd order low pass. the amplitude signal is from a variable source and i've adjusted it so it won't overload.
as for the adc overload it's a good point to take a look of it. the input signal may be overloading on the analog input from time to time ... i'll check it anyway but i don't think it's my problem....
0
Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

selim007Author Commented:
in the wave file format 0x80 (128) doesn't mean 0 Volts ?
below 128 is a negative voltage and greater than 128 is the positive boltage right ??
0
markps_1Commented:
  that's the way it goes...0x80 is 0V  

  But you have to positive bias your signal in order to achive that otherwise everytime it goes below 0V it will read 0x00 on the ADC.
0
d-glitchCommented:
I don't know what specs are for the .wav file.

But I have run into problems with twos complement output from ADCs.  
Try inverting the MSB and see if you like the results better.
0
markps_1Commented:


    So for example if your ADC reads from 0 to 5V You raise your AC signal from 0v to 2.5V so your ZERO VOLTS will reach the center point of your ADC. (you may use a voltage diivder, opamp, FET, etc. in order to do that.  )

   Make sure your sampling rate is twice as big as your highest signal frequency.  http://en.wikipedia.org/wiki/Nyquist_frequency
0
d-glitchCommented:
I am suggesting that if the .wav file uses twos complement

1000 0000 is the most negative value

1111 1111 is just less than zero
0000 0000 is zero

0111 1111 is the most positive value.

Putting straight binary into an audio device that was expecting twos complement would sound horrible.
It flips each half of the sine wave so the peaks are near zero and the base is near the maxima.
Think happy positive smiles and sad negative frowns.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
markps_1Commented:
d-Glitch... I've had that problem too.. I agree with you.. That's a commom mistake.
0
selim007Author Commented:
i also agree with u guys...just give me a while to test
0
selim007Author Commented:
after checking the .wave file structure i've found that the two's complement is only used in 16bits format and higher. in the 8bits format it uses a binary offset....
am still failing to get the dc bias works....
it's not that simple as i thought..... a simple 2 resistors with a coupling capacitor didn't worked....
when tested on the oscilloscope the signal still as it's + and - signals !!!
i don't understand....
0
selim007Author Commented:
i've tried the two's complements(by xoring the byte with 255 then adding one) on the 8bit format but it didn't work
0
selim007Author Commented:
in summary i have 1 problem and 1 question:
1- i've failed building the dc bias
2- is it possible that the sampling rate isn't constant on the pic which is causing the troubles ???
0
NetTechDudeCommented:
-------------- 1 ----------------------
To do DC-bias:

Signal source -> 22µF capacitor -> ADC input (capacitance doesn't matter much, anything from 10µF to 220µF might work)
One resistor from ADC input pin to +5V (or whatever +supply you use): R=100k
One resistor from ADC input pin to ground: R=100k

Test with an oscilloscope or a voltmeter that you ADC input slowly crawls to Usupply/2 after you apply Power to the PIC's circut. Then you're ready to go:
------------------- 2 ------------------------
As I perceive it, the USB framework (do you use parts of Microchip's provided usb code?)
can take virtually milliseconds to complete. During that time, your ADC might not sample, unless it is interrupt driven.
What I'd do:

Setup:
1. CPU Clock = 48 MHZ (derive from internal PLL) to get the fastest execution time for usb/data preparation
2. Get a spare I/O pin and make it an output
3. ADC interrupt enable
4. Timer2 Interrupt enable (or any other 16 bit timer, exchange timer2 in the following text for what you really use)
5. Prescaler -> Timer2, if needed
6. preload Timer2 so it gives you 1/22.050 of a second @ 48 MHZ

Timer2 interrupt routine:
 -> Stop Timer2
 -> preload Timer2 again for 1/22.050 second timing (minus some clocks to get real 22.05 kHz samplerate)
 -> Start Timer2
 -> fires ADC "start sample"

ADC interrupt routine:
 -> Set bit on any spare I/O port for check of timing with oscilloscope
 -> Read ADC, store data in USB TX-Buffer
 -> Clear bit on the I/O port

Then you can see on your spare I/O when sampling occurs because you get a small spike whenever your ADC finishes sampling. When you trigger on one spike and have the followiong in view, you can easily estimate the jitter in % of the cycle time. It will be very little when using interrupts, I hope.

In conjunction with usb, interrupts are your only chance to achive a stable  sample rate.
To preload the correct value into the timer, just substract (65535 - "your timing constant") from the timer register while it's running. Don't stop/start the timer. So the timer fires at a quite regular interval. That is imho better than stopping the timer, setting it to exact (65535 - "your timing constant" - "some time for interrupt entry") and starting it again.
0
selim007Author Commented:
dear NetTechDude :
first thanks for your participation.
the DC bias method you've mentioned is exactly what i have done and it's described in my first posting.
as for the sampling rate:
i am actually using interrupts to handle the sampling rate via tmr0. but the problem is that the ADC convertion routine is fired from a low priority interrupt and i can't use the high interrupt because it has some other jobs to do which is causing a small variation in the sampling rate... that's why i asked the question about the non-constanst samling rate.
as for the usb i am using the tools and codes supplied by jungo (WinDriver).
what i am currently testing is to find out if the usb communication is taking too much time to complete( a time larger than the required time to fill the 64 bytes of sampled data in the buffer). if this is true so i am missing some parts of the analog signal but even i don't think that it will cause the resulting output am getting...anyway am just checking it....
any other suggestions or solutions are highly appreciated
0
selim007Author Commented:
is it possible that the microtroller is causing some interference and is disrupting the functionality of the OPAMP used for anti-aliasing ???
0
markps_1Commented:
in oder for the sampling rate to be constant.. you have to put the ADC on the highest priority interrupt. If you can't do that.. leave a timmer running a adjust the timing of the sampling rate acording with the running timer.. I mean lower the samppling rate up to a point you can have a setady sampling rate. If you can't do that you'll have to move the ADC task off chip.

  Usually on chip ADCs are not as precise as off chip ADCs. Some chips offere the option to put the processor in stand by while the internal ADC does the conversion.

0
markps_1Commented:
s it possible that the microtroller is causing some interference and is disrupting the functionality of the OPAMP used for anti-aliasing ???

 Yes, but not very likelly on such a smal circuit. In any case make sure you have enough decoupling capacitors and also that your ground lines to the ground plane and also make sure that the analog signal lines are as short as possible between ICs.
0
selim007Author Commented:
ok but do we all agree that my problem is due to the unconstant sampling rate ???
0
markps_1Commented:
I mean also make sure your ground lines aren't long and make a straight path to the ground plane.
0
markps_1Commented:
IF you check with your scope and see that an average signal is getting cut off below 0V you still need to shift the signal to the 2.5V centerpoint. That must be part of the problem.
0
selim007Author Commented:
in fact what i don't understand is that after installing the DC bias, the voltage on the analog input is almost 2.5v when no signal is applied.
but when connecting the scope and checking the audio singal on the scope it looks exactly like the original(2parts one positve and another negative)
any comments ?
0
selim007Author Commented:
i mean when applying an audio signal the scope shows positive and negative signal ...
0
markps_1Commented:
Things that might be happening...

   -DC bias is not set correctly...   (make sure you check your signal output before and after your DC bias circuit.. check the strengh of the signal, the voltage top (5V) and down (0v) limits  if nothing is getting cut off.
   -Check if the sampling rate is really constant
   -Check if you are really setting the middle point of the signal at 0x80 on yoru wave file. check for 1's complement format.
   -Check if the problem is not with the dellay of the transmition of the signal. (how are you time coding the samples? Make sure you are not losing samples at random)
   -Make sure your wave file is on the correct format.
0
NetTechDudeCommented:
Is your oscilloscope set to AC or DC coupling ?
What does a voltmeter read when you measure the input voltage into the adc in the voltmeters DC-mode without applying signal ?
Does your input signal (at the PICs ADC input) clip Gnd or Usupply or does any signal in your anti alias filter do this ?
The distortion coming from that would be terrible.
Maybe you disconnect the AA filter for preliminary tests and use a bandwith limited signal source.

Interference:
PICs can make quite some noise in the circuit.
I use some low ESR ceramic caps (~ 100nF) between the adjacant power pins (the pair of Usupply and Gnd next to each other, I just don't remember the numbers)  to get rid of that.
Coupling that into your anti aliasing filter is quite possible, if your filter is build critical enough, it may start swinging. That of course depends on the way the filter is built. To be super-sure try a 3 stage rc filter (el-cheapo layout) during development. Or consider T or (pi) networks.
Those thingies can't swing and is rather bullet-proof ;-) Sound quality won't  be best, but you can test your concept in general. And R/C filters are quick to solder on a breadbord.

Another way to test: Try applying a signal genarators sine, triangle and rectangular waveforms, probably directly to the ADC input. Then you can output a CR/LF separated list of value from your application, spanning several cycles of the input waveform. Feed that into Excel and plot it. You should easily see what kind of disturbance you get.
Eg. if applying triangle waves and the ramp isn't plotted smoothly, you might consider sample rate variation.
If the sine or triangle wave is disturbed at it edges, voltage clipping in the input might be the problem.

Why can't you use a high priority interrupt ? I mean starting tha ADC ist a fast task (1 Step: set that darn _stop/go bit) and there it goes. What can be of higher priority than the sound where the human ear is so sensible to slight distortion ?

Test the sound file capability of yourt program separately by generating computer calculated rectangel and sine waveforms. Play them back using Media Player or wahtever commercial program you prefer and feed you speakers output to the oscilloscope. If you don't see you calculated waveforms, your error is during creation of the wave file.

BTW: I hope your handling of the ADC's high bits and Left/Right adjustments of the result within the ADCH:L register pair is correct. Just to mention it.
0
selim007Author Commented:
as for the i may have to mention that i am ignoring the 2 LSB of the A/D conversion results so i am only using the 8 most significant bits of the results.
0
markps_1Commented:
It is a common practis to ignore a couple of LSBs since the precision is about 1 to 2 LSBs anyway.
0
selim007Author Commented:
i'll try the tests that NetTechDude  suggested maybe i'll find the problem...
i'll try sampling a simple sin wave and check out the results.
this may take a while...
0
selim007Author Commented:
i think that i've found my problem but still not sure about it!
i am using PLL for usb and mcu clock, so the adc is operating at a maximum of 4ksps which means that i can have a maximum frequency of 2khz, my a-a filter is a 5.1khz low pass....the whole thing is a mess here!!!!!
i am testing an off-chip design with the mcp3201 a 100ksps adc with spi interface.
any suggestions ??
0
NetTechDudeCommented:
I quite don't understand: Why do you only get 4ksps ?
I mean: PLL --> 48 MHZ CPU clock.
1/Fosc = 20,8 nS = Tosc

At 48 MHZ you have to set Tad = Tosc * 64, which is equal to Fad = Fosc / 64
this gives Tad = 64 x 20,8 nS = 1,33 µS
One Cycle (10 bit A/D) takes 11 Tad = 14,7 µS
Add the 2,5 µS acquisition time and you get around 17 µS for a full A/D cycle.
17  µS per cycle equals 58 ksps !

With a fast interrupt routine, I think you can easily achive around 40 ksps or a bandwith of 20 kHz.

What values do you have in the following registers ?
ADCON2
OSCCON
CONFIG1L
CONFIG1H
0
mokuleCommented:
Wouldn't You like to consider using external audio codec.
I've used for example TLV320AIC23 for recording audio.
It has integrated amplifiers and oversampling.
0
selim007Author Commented:
NetTechDude:
i was running on a 20Mhz crystal
here's the configuration bits used
Full Speed USB Clock Source Selection: Clock src from 96MHz PLL/2
CPU System Clock Postscaler:[OSC1/OSC2 Src: /4][96 MHz PLL Src: /6]
96MHz PLL Prescaler: Divide by 5 (20 MHz Input)
Oscillator: HS+PLL,USB-HS
how to set the correct configuration bits with a 48MHz crystal while keeping the USB module operational in full speed.
what will be the clock frequency used by the microcontroller core ?
0
NetTechDudeCommented:


>how to set the correct configuration bits with a 48MHz crystal while keeping the USB module operational in full
>speed.
>what will be the clock frequency used by the microcontroller core ?

I quite don't understand your problem. You set PLLdiv to 12 and there you go, if you want to use an 48 MHz crystal.
But what do you expect from an 48 MHz crystal ? You can't get it any faster than could you have it now, when CPU clock is derived from 96MHz/2 PLL (48 MHz). With oscillatortype HS-PLL: set CPUDIV to /2 to get 48 MHz out of your PLL into the cpu nad peripherial clock.

Why'd you use CPUDIV = /6 with the PLL ? That makes all your ADC run with 16 MHz. This is about four times slower than it could work (48 MHz max). This explains why your ADC isn't fast enough, I'd say. Interesting to hear about your ADCON2 setup.

Anyways, could you please quote all binary/hex or decimal values of the registers I asked you to provide?
I'd like to make my own picture of your situation.
ADCON2: address 0xFC0
OSCCON: address 0xFD3
CONFIG1L, CONFIG1H: lowes configuration bits in program memory @ addresses 0x300000 and  0x300001
If you have trouble with the names, please refer to the current datasheet doc. ID "DS39632C" at www.microchip.com
0
selim007Author Commented:
here's the register's values that you requested.
ADCON2:
Left justified/6 Tad/FOSC/16

ASCCON:
ox48 as per the MPLAB simulator

CONFIG1L:
USB clock source comes from the 96 MHz PLL divided by 2/00 = 96 MHz PLL divided

by 2 to derive system clock/100 = Divide by 5 (20 MHz oscillator input)

CONFIG1H:
Oscillator Switchover mode disabled/Fail-Safe Clock Monitor disabled/HS

oscillator, PLL enabled (HSPLL)

now i've discovered another problem this time with the USB streaming speed!
i have 2 endpoints sets on Alternate settings 1 ( as i understand that Alternated settings 0 has a limited bandwidth...)
the first endpoint on address 0x81 is bulk with 64k(tested with no buffering and with double buffering)
the second endpoint on address 0x82 is Isochronous with 256k(also tested with and without double buffering)
the bulk endpoint streaming is only working @ 100kbps max.
as for the ischronous endpoint i keep getting errors saying "Isochrounous transfer completed with errors".
from the pc side i am using a C++ application with multithreadings to listen to pipes.(the application generated by windriver)
i've also stopped displaying the output on the screen and simply counting the data size in order to speed up but i am still running at a very low speed !!
any suggestions regarding the USB issue ?
0
NetTechDudeCommented:
I wish you had posted just the binary values. Maybe I'd find a mistake. As you don't mention Microchips flag/bit names it's somewhat hard to grap what you set up. But I'll get it sooner or later :-(

With Config1 H:L set to the quoted values, you actually have 48 MHz input to your CPU and peripherials.
Have you seen Table 21-1 in the datasheet, document no. DS39632C, pg. 265 ?
(a) With 48 MHz max device frequency (yours) you should use Fad=Tosc/64 i.e. in ADCON2: ADCS2:0 = 110
(b) For aquisition time, Tacq, you need to set it according to Equation 21-1 to 21-3, pg 264. Please recalculate with correct Tad ( 64 / (48 MHz) ) and your values altogether put that into ADCON2: ACQT2:0.  

For purposes orf demonstration I get Tad of 1.3 µS and with the example values from eqn. 21-3 I get a 2 Tad for waiting more than the required 2.45 µS. This makes ADCON2: ACQT2:0 = 001
==> Combined: set ADCON2 = 0x0E

I think with that setup you should have 2 Tad cycles Tacq + 11 Tad cycles for A/D makes 13 cycles of Tad time with 1.3 µS each. This equals 17µS per 10 bit A/D or 57.7  kHz sample rate max.

Besides: I hope you are aware that you can only use high speed usb, low speed is not supported whan running the cpu on 48 MHZ (I just noticed that : pg. 29/30, table 2-3: Oscillator Configuration Options) Low speed isn't suitable for audio either :-(

For clocking stability: Did you consider the CCP2 trigger for A/D operation (chapter 21.8, pg. 268) ?

Please check at least the above points (a) and (b) and tell me what you think about that.

Concerning the USB issue I can't help you as I do only understand usb roughly enough to get microchips sample code working with serial emulation. That gave me a roaring 1 MByte / sec for 3 secs each time I tried and I was quite happy with that. Cpu usage shot to 48% on a hyperthread machine :-) That makes it totally clogged but it works anyways.
0
selim007Author Commented:
the USB is now working fine.
i've readjusted the ad module configuration as discussed above and i've done 2 tests1.
1- i've disabled the ADC module and captured data from pc for 10 seconds so i've got arround 256KB which is fine.
2- i've enabled the ADC module and also captured data for 10 seconds, i've only got 56KB.
which means that the USB firmware is taking arround 39microseconds to send data (64bytes) to the pc.
from the Other side, 64 ADC convertions time  + USB time = 178.57us
which make the ADC convertion time =139.57us
these tests has been done using the TMR0 working on 8bits and 1:8 prescaler(firing the interrupt every 42.67us).
below is some parts of the code:

1- Interrupt routine:
#pragma interruptlow InterruptHandlerLow
void
InterruptHandlerLow (void)
{
   int ADCdata;
   if (UCFGbits.UTEYE!=1)
      USBInterruptHandler();  //USB Interrupts
    if (INTCONbits.TMR0IF)
    {                                   //check for TMR0 overflow
        if(!BusyADC()) //Check if ADC is ready
      {
         if(ADRESH)
              myUSBBuffer[i]=(i);//ADCdata;
         else
           myUSBBuffer[i]=0x0;
         i++;
        if(i==64)
        {
          if((usb_device_state >= CON.FIGURED_STATE) &&       (UCONbits.SUSPND==0)) //device is attached to the pc and not in suspend mode
                    WDF_Poll(myUSBBuffer); //Send data to PC
         i=0;
         }
      ConvertADC();//Start a new AD convertion
      }
      INTCONbits.TMR0IF = 0;            //clear interrupt flag
   }
}

2- Also some of the initialization routines for tmr0 and adc
OpenADC(ADC_FOSC_64 & ADC_LEFT_JUST & ADC_2_TAD, ADC_CH0 & ADC_INT_ON & ADC_VREFPLUS_VDD & ADC_VREFMINUS_VSS,0x0E );
      OpenTimer0(T0_8BIT & T0_SOURCE_INT & T0_EDGE_RISE & T0_PS_1_8 & TIMER_INT_ON);
      INTCONbits.GIE = 1;

any suggestions ??
0
selim007Author Commented:
please note that i am buffering data in a 64 bytes buffer then sending the buffer to the pc, so every 64 ad samples are sent in a time
0
selim007Author Commented:
there's a mistake above:
>from the Other side, 64 ADC convertions time  + USB time = 178.57us
>which make the ADC convertion time =139.57us
correction:
which make the ADC convertion time =139.57us/64
ADC conversion time=2.18us
0
selim007Author Commented:
ADC conversion time =2.18us isn't logic at all !!!
so what do you think it's wrong ?
0
NetTechDudeCommented:
That's kindof crazy what you're doing.
I don't know how your USB-firmware part works, but doesn't WDF_Poll(myUSBBuffer) block until data has been returneds to the pc?
As long as it's running, you get no further interrupt from tmr0.

Please reconstruct that interrupt handling this way:
1. Tmr0 -> Starts ADC
2. ADC interrupt -> Saves values in array; array full ? -> Copy to 2nd buffer-> Set "arry full" flag for main program, reset array pointer (i) so ADC can go on.
3. inside main: "Check for Array full flag" -> WDF_Poll(2nd buffer)
    When starting ADC check for array pointer overflow and emit a warning (i.e. signal on pin as "alert")

That's the way I'd do it. For continuous operation alongsider with USB support, you have to make your ADC really interrupt driven - but don't try to make the whole sampling/sending process interrupt driven.

You even set " & ADC_INT_ON" in OpenADC(), so what do you do for handling the ADC interrupt ?

You get a certain problem with USB, of course. Minimum service interval time is 1 mS. That is Minimum, if lucky. Might be more, occasionally, I think.

At 17µS / sample you have 58 samples / millisecond, If USB leaves out one cycle you're crashing or loosing conversions.
So. Try a bigger buffer and watch for "buffer full" conditions.

-------------ADC SPEED MEASUREMENT ---------------------------- PLEASE TRY IT AT LEAST ONCE THIS WAY !!!!! -------
Please try thisa first to ensure yourself that the conversion speed is really 57 kHz as you can expect it.
1. Set Flag (any spare output pin) = 1
2. Start ADC
3. ADC ready ? No -> Goto 3. Yes -> Goto 4.
4. Reset Flag (any spare output pin) = 0

And then watch that spare output pin on an oscilloscope, measure the length of the pulse which is your ADC time.

This way you are sure about the ADC speed. All the other attempts or calculating or guessing are crap if left unverified.
----------------------------------------------- / ADC SPEED MEASUREMENT ------------------------------------------------------

My C knowledge is a little rust, so please help me with these lines:
---- snip -----
if(ADRESH)
             myUSBBuffer[i]=(i);//ADCdata;
        else
          myUSBBuffer[i]=0x0;
---- snap ----
So... If ADRESH is not equal to 0, feed it the value i, for test I suppose or what ? ADCdata ? Does ADCdata get any value anywhere ?

Maybe more thoughts later on that, I need to reboot :-(
Maybe you can work with what I threw at you in the meantime.
0
selim007Author Commented:
1- my original has the USB tasks in the main loop and not in the interrupt section. the code i've posted was my last test!!!
in fact only the tmr0 is handled with the interrupt routine.
setting the interrupts on for the ADC was also a test that i've supposed that it may increase the performance but after rechecking the code it has no effect except than a time consuming and waste of clock cycles.
as for the section below:
---- snip -----
if(ADRESH)
             myUSBBuffer[i]=(i);//ADCdata;
        else
          myUSBBuffer[i]=0x0;
---- snap ----
it's not the complete code, myUSBBuffer[i]=(i); certainly will not filled by i but with the ADC data after making some calculations. but my formula can't accept 0 values that's why i've made the test!!! here's the original Code:
---- snip -----
if(ADRESH)
         myUSBBuffer[i]=FixData(ADRESH);
else
          myUSBBuffer[i]=0x0;
---- snap ----
sorry for the missing codes... i were testing a couple of things and i've copied the code as it was and pasted it here!
in summary, my code is almost what you have suggested!!
the USB taks are handled from the main loop,
the ADC has not interrupt set.
TMR0 has interrupt set.
the interrupt handling routine will check if the ADC convertion is done; if yes the data will be filled in the buffer and a ready flag will be set.
from the main loop we notice the ready flag and send data to usb.
but my real problem were never in the ADC part. it was in the USB block. i've had some errors in the firmware and the USB were sending faulty data at very low speed!!! i've just finished from fixing the USB and i'll proceed with the ADC part!!!
i'll keep you uptodate.
and thanks anyway for all the effort you have done!!!



0
NetTechDudeCommented:
Maybe selim007 can tell if the thing now works and what his main mistake was.
Then he could also assign the points hinself.

SELIM 007 - please return and assign the points yourself. I'd love to hear where most of the trouble occurred during the final solution to the task.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Components

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.