• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 83 subscribers
  • Views 1269 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Time consuming of 28335 in getting ADC results

Jack Qian
Prodigy 115 points

Hi,guys

I use the profile viewer in CCS3.3 tosee how much time it takes 28335 to get 12 ADC results.

And I am very surprised to find that the total time for 28335 to get 12 ADC results is about   2us!

I don't  know what is wrong!

The program is(doing the following program for 12 times) :

/*Convert Vuv1*/

Vuv1=AdcRegs.ADCRESULT0>>4;

Vuv1=Vuv1*3*0.0002442002442002442002442;    //0.0002442002442002442=1/4095

  • 0
    TI__Guru 65070 points

    How do you have the ADC setup from a configuration register perspective?
    How are you sequencing through the 12 different results?  Are you converting 12 different analog input channels, or converting the same single analog channel 12 times?
    What are you using to trigger each of the conversions?

  • 0 in reply to BrandonAzbell
    Prodigy 115 points

    Hi  

    I use EPWM PRD event  to trigger the ADC .And in the ADCINT_ISR function,I get the ADC results from 12 different ADC  Result  Registers.

    I run my code from internal SARAM.

  • 0 in reply to BrandonAzbell
    Prodigy 115 points

    Here is my  disassembly. Is this  normal?

     

  • 0 in reply to Jack Qian
    TI__Guru 65070 points

    What are you including in the 2usec measurement?

    Is this from the EPWM trigger event to the 12th ADC conversion calculation?

    Are you able to instrument your code with perhaps toggling a GPIO pin surrounding your targeted code and measure this time on an oscilloscope?

  • 0 in reply to Jack Qian
    TI__Guru 65070 points

    For the line which reads the ADC results out of the ADC registers and places that value into a variable in memory, yes, this is typical.

    The other line seems reasonable as well.

     

  • 0 in reply to BrandonAzbell
    Prodigy 115 points

    BrandonAzbell said:

    What are you including in the 2usec measurement?

    Is this from the EPWM trigger event to the 12th ADC conversion calculation?

    Are you able to instrument your code with perhaps toggling a GPIO pin surrounding your targeted code and measure this time on an oscilloscope?

    The time(2us)  I measured with profile is from the first ADC  onversion calculation to the 12th ADC conversion calculation.

    And I tried the way you metioned above,  toggling a GPIO pin  and using an oscilloscope to see the time.But the result is similar,the time is about 1.8us.

    Does it really take so much time for 28335 to get 12 ADC results?

  • 0 in reply to Jack Qian
    TI__Guru 65070 points

    So, I wasn't thinking about this correctly.  Although it is good to know that you have visual evidence, I wasn't thinking about the math at all.

    You mentioned 12 ADC conversions are taking 2usec.  If you divide this 2usec by 12, you will get the sampling rate per conversion which is 6MHz.

    The maximum sample rate of the ADC on the F28335 is 12.5MSPS (Mega-samples per second).  How do you have the ADC clock configured?

  • 0 in reply to BrandonAzbell
    Expert 2355 points

    Looking at the disassembly, 2.0us seems perfectly plausible. 

    I don't really think its an ADC issue, but rather a code efficiency issue.  From the disassembly, an ADC read, conversion to float and multiplication take 18 cycles.  I assume there is a for loop floating around the 12 iterations, which will add about 8 cycles per iteration.  Thats a total of approximately 26 cycles per iteration which isabout 170ns per iteration at max. clock rate.   Multiplying this by twelve gives just over 2us.

    As for improving this:  There is a bottom line speed which is based on the ADC of 12* (1/12.5M) of about 1us all up.  Any faster than this will mean the ADC conversion may not have completed in time.

    Here are some suggestions about reducing the 2us closer to 1us:

    1) Read from AdcMirrorRegs instead of AdcRegs.  There are waitstates on AdcRegs and that is contributing to the 4xNOP in the middle of your disassembly.  You should be able to save a couple of cycles per iteration to gain about 160ns.

    2) Instead of using a for loop per iteration, do multiple conversions per for loop iteration.  This will reduce this overhead.  This comes at the cost of code space.  If you wrote all 12 out without a for loop you could potentially strip off 640ns but your code will now be ~216 words long instead of ~20 words long.

    3) Hand code it in assembly.  You may be able to make the code more efficient and eak out some more cycles.

    Tim

  • 0 in reply to BrandonAzbell
    Prodigy 115 points

    BrandonAzbell said:

    So, I wasn't thinking about this correctly.  Although it is good to know that you have visual evidence, I wasn't thinking about the math at all.

    You mentioned 12 ADC conversions are taking 2usec.  If you divide this 2usec by 12, you will get the sampling rate per conversion which is 6MHz.

    The maximum sample rate of the ADC on the F28335 is 12.5MSPS (Mega-samples per second).  How do you have the ADC clock configured?

    I'm sorry I didn't express my question clearly.And you misunderstood my question.

    I use EPWM PRD event to trigger ADC unit to convert 12 ADC channels and then in the ADCINT_ISR function,I get the ADC results from 12 different ADC  Result  Registers.

    The time(2us) is just getting the 12 ADC results from ADC  Result  Registers,not converting 12 ADC channels.

     

  • 0 in reply to Tim King61612
    Prodigy 115 points

     I see! I'm improving my code efficiency .

    Thank you very much!

  • 0 in reply to Jack Qian
    Expert 2355 points

    Having a second look at the disassembly I noticed I had made a mistake in my post.  The 4 NOPs have nothing to do with the AdcRegs but to do with the integer to float conversion (4 waitstates to move ACC to R0H - see page 23 of SPRUEO2A.pdf).  However I would still recommend using AdcMirrorRegs as they are right-justified and do not need the shift. This will mean that the FPU can directly read them into FPU registers without having to do the shift in the ACC and incur the 4 waitstate penalty.  I have not tested it myself, so I hope the C compiler is smart enough to not move it via ACC and save you 4-6 cycles (up to 480ns in time over 12 conversions).

    Tim