TMS320F28027F: Simple ADC program?

Hi Marlyn,

Many thanks for a speedy reply! It's nice to know that "help is out there"!  I tried your program and it works fine (I put the last part 'Adc conversion' in a while(1) loop for continuous sampling - and by the way, this part does not need EALLOW). Just a couple of questions:

(1) Is the double sampling (SOC0  & SOC1) necessary? Will it not halve the sampling rate? If it is only a problem with the very first sample, I  could probably live with that. It seems to work OK without the software trigger to SOC0.

(2) The program is now much easier to understand. (I am used to the 38335, which uses sequencing for the ADC.) But your program still calls a lot of code in f2802x_adc.c and (for me) it is difficult to understand why all the code is necessary. Could a lot of it be 'thinned out' for this simple purpose?

(3) In contrast to the 38335, there does not seem to be a ADC clock chain - only an option for dividing the SYSCLK by 2. So the ADC apparently just runs a full (or 1/2) conversion speed. Is that correctly understood?

Regards

Roger

Hi Roger,

Roger Munck-Fairwood said:

(1) Is the double sampling (SOC0  & SOC1) necessary? Will it not halve the sampling rate? If it is only a problem with the very first sample, I  could probably live with that. It seems to work OK without the software trigger to SOC0.

It is only necessary for the first conversion within a sequence of conversions. If you enclosed the code for the conversions within a while (1) loop then just discard the very first SOC0 result (which the code already does) and then continue triggering only SOC1 and logging that result. Alternatively, you could remove the SOC0 trigger and conversion all together and discard the very first SOC1 conversion result. More information on this initial conversion can be found within the F2802x Errata under the (ADC: Initial Conversion) Advisory.

Roger Munck-Fairwood said:

(2) The program is now much easier to understand. (I am used to the 38335, which uses sequencing for the ADC.) But your program still calls a lot of code in f2802x_adc.c and (for me) it is difficult to understand why all the code is necessary. Could a lot of it be 'thinned out' for this simple purpose?

I tried to thin it out as much as I could and only leave necessary code. Could you please give me an example of what lines of code are difficult to understand and I could help walk you through what its doing or why its needed.

Roger Munck-Fairwood said:

(3) In contrast to the 38335, there does not seem to be a ADC clock chain - only an option for dividing the SYSCLK by 2. So the ADC apparently just runs a full (or 1/2) conversion speed. Is that correctly understood?

Yes, this device only has CLKDIV2EN (on Rev A). If you need other values you'll need to change SYSCLK but this will also result in a change to the overall device's operating frequency.

Best Regards,

Marlyn

Hej Marlyn,

Many thanks for the quick reply.

Re. (2): The  new file Example_ADC.c with main() is clear enough now, but there is a lot going on in the support file f2802x_adc.c which seems unnecessary (and confusing) - but it is called from main() (e.g. some averaging going on in  AdcConversion() which is called by AcdOffsetSelfCal() which is called in main()). I wonder if f2802x_adc.c could also be 'thinned out'.

Regards

Roger

Hi Roger,

The 'AdcOffsetSelfCal()' function is called from main in order to re-calibrate the ADC zero offset error. The offset error of an ADC is the deviation between the measured and ideal reading, in terms of Least Significant Bits (LSBs), when a 0 volt (V) input is applied to any of the input pins. Usually offset error is adjusted for by correcting it through the OFFTRIM bits in the ADCOFFSETTRIM register. 

What the AdcOffsetSelfCal function does is:

• Sets the internal mux which connects VREFLO to B5 (This way 0V is observed on B5)
• Applies an artificial offset (+80) to account for any negative offset there may be
• Does conversions on B5 to find the average actual reading with a 0V input
• Writes to the ADCOFFSETTRIM register the new offset value (80 - average conversion)
• Sets B5 back to being a normal ADC input pin

In order to properly calibrate the offset there needs to be a large enough sample size of conversions. AdcConversion() is specifically called in order to do these conversions. The function does 256 conversions. Within this function, the conversions are carried out by doing "pin-pong" sampling, just a technique to help speed up the conversions. Essentially, ADCINT1 is triggered by end of conversion 6, and initiates conversions on SOC8-15. ADCINT2 is triggered by EOC14 and triggers SOC0-7  (this is why they call it ping-pong sampling). All of these conversions are then summed up and averaged in order to get an accurate representation of what the ADC reads when 0V is applied. 

These functions don't need to be changed. TI provides the code for these in order to help eliminate the ADC offset error. 

Best Regards,

Marlyn

Hej Marlyn,

(Many thanks for your speedy reply! I read you reply with interest and have now got round to considering this subject again...).

OK, I will just use the code in your Example_ADC.c, where it calls InitAdc() and AdcOffsetSelfCal() - and also does all the configuration in the EALLOW part.

(1) It works fine with this loop in main():

while(1)
  {
    // Software Trigger -  Works without (Roger)
    //AdcRegs.ADCSOCFRC1.bit.SOC0 = 1;

    // Software Trigger
    AdcRegs.ADCSOCFRC1.bit.SOC1 = 1;
    
    // Wait for the conversion to be done
    while (AdcRegs.ADCINTFLG.bit.ADCINT1 == 0){}

    // Clear ADCINT1 flag
    AdcRegs.ADCINTFLGCLR.bit.ADCINT1 = 1;
    
    // Store the conversion result
    Voltage1 = AdcResult.ADCRESULT1;

// Do something with the result...

 }

(2) If I just put (once):

AdcRegs.ADCSOCFRC1.bit.SOC0 = 1;

before the loop, and only use SOC1 in the loop, I assume the first value read  AdcResult.ADCRESULT1 in the loop will be correct (but it is not so important with the first value).

(3) If I put both SOC0 and SOC1 triggers in the loop, will this not halve the sampling rate?

(4) But I think I have misunderstood something about the relationship between SOC's and ADCRESULT: Why do you do SOC0 and SOC1 but only read AdcResult.ADCRESULT1?

Regards

Roger

Hi Roger,

Thank you for following up on the thread. The reason why SOC0 and SOC1 are triggered is due to the Errata Notice we have on ADC Initial Conversions (ADC: Initial Conversion)  which states, "When the ADC conversions are initiated by any source of trigger in either sequential or simultaneous sampling mode, the first sample may not be the correct conversion result", as a workaround the following is suggested: "For sequential mode, discard the first sample at the beginning of every series of conversions. For instance, if the application calls for a given series of conversions, SOC0→SOC1→SOC2, to initiate periodically, then set up the series instead as SOC0→SOC1→SOC2→SOC3 and only use the last three conversions, ADCRESULT1, ADCRESULT2, ADCRESULT3, thereby discarding ADCRESULT0". 

If you did some testing and ADCRESULT1 is correct while only calling AdcRegs.ADCSOCFRC1.bit.SOC0 = 1; once outside the loop then you should be able to implement it this way. The errata is for a series of conversations and the workaround is applied as a precaution in case the first conversion result is incorrect. 

Best Regards,

Marlyn

Hej Marlyn,

 Thanks for the continued support. I have a question about the conversion time.

Using this code (based on yours):

while(1){
              // Software Trigger
             AdcRegs.ADCSOCFRC1.bit.SOC1 = 1;

             // Wait for the conversion to be done
             while (AdcRegs.ADCINTFLG.bit.ADCINT1 == 0){}

             // Clear ADCINT1 flag
             AdcRegs.ADCINTFLGCLR.bit.ADCINT1 = 1;

             // Store the conversion result
             AD_Value=AdcResult.ADCRESULT1;
             IO34_Toggle(); // Signal after an A/D conversion is done (for monitoring the period)
    
    } // End while

I measure an IO toggle time of 2.1 microseconds. This seems much longer than the expected time in the data sheet sprui09-TMS320F2802x-Reference-Manual.pdf  Table 6-1 p. 406  , i.e. 333 ns (ACQPS is set to 6 in your code) – even allowing for about 130 ns for executing the IO toggle (which I have measured by only having the toggle in the loop). Is the 2.1 microseconds the expected conversion time using your code?

Regards
Roger

Hi Roger,

I noticed that you have the GPIO toggle within a function call. Can you please toggle the GPIO directly from within the loop to get a closer estimate? If you are toggling the GPIO in a function call then you are also accounting for the time it takes to branch to that function and back.

Also note that you are including the time it takes to clear the ADCINT1 flag, store the result, and trigger the start of the SOC. Something else you could try is setting a GPIO right after you initiate the software trigger and then clearing the GPIO after the conversion is done. If you account for the GPIO setting/clearing time then this should get you much closer to the actual sampling/conversion time.

Best Regards,

Marlyn