fast ADC conversion for more than one channel

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

fast ADC conversion for more than one channel

Jump to solution
1,334 Views
heinzroitner
Contributor II


Hi Rene Kolarik,

I would like to continue the discussion of thread 329507. We are looking for a fast sample conversion on the internal ADC for 8 channels (for the history of this problem please see threads 317871 and 328250).  Previous implementations using LWADC were either very slow

(450 us) or they did not give 8 different samples.

So we implemented a solution along the description in thread 329507 which is fast and gives different samples. But the debugger shows all kinds of strange behavior as soon as more than one channel is converted.

So the question is: is MQX somehow affected when more channels are converted ? If yes, can you think of another way of implementation ?

Our ISR is:

void iADC_ISR (void * adc_ch)

{

// get last sample

ADC_MemMapPtr adc_ptr = adc_base[current_conv_ch];

uint32_t temp = adc_ptr->R1;

temp = temp & ADC_CDR_CDATA_MASK;

g_iADC0_values[current_conv_ch] = (float)(temp);

// start next conversion

current_conv_ch = (current_conv_ch + 1) % noChannels;

if (current_conv_ch == 0)

{

// stop sampling

}

else

{

adc_ptr = adc_base[current_conv_ch];

uint_32 channel = ADC_CHANNEL(inputs[current_conv_ch]);

adc_base[current_conv_ch]->HC1 = channel | (1 << ADC_HC1_AIEN1_SHIFT);

}

}

We are using the twrvf65gs10 BSP.

Thanks, Heinz

Labels (3)
0 Kudos
1 Solution
908 Views
rendy
NXP Employee
NXP Employee

Hi, first idea - why do you use floats in interrupt handler? Is it really needed? Can it be the source of the problems?

View solution in original post

0 Kudos
8 Replies
909 Views
rendy
NXP Employee
NXP Employee

Hi, first idea - why do you use floats in interrupt handler? Is it really needed? Can it be the source of the problems?

0 Kudos
908 Views
heinzroitner
Contributor II

Hi,

OK thanks this is an error in the ISR above. It looks better now after a few runs.

But I have to test it more and in the full program version. I'll tell you then.

Heinz

0 Kudos
908 Views
heinzroitner
Contributor II

Hi Rene,

yes, all the problems were caused by the premature casting of ADC-values to 'float' in the ISR. This gave us much pain.

I thank you for your help and hope you can assist us next time when we are stuck.

Best regards,

Heinz

0 Kudos
908 Views
rendy
NXP Employee
NXP Employee

I'm glad I could help you, just mark my answer as 'Correct' please.

Thanks

Rene

0 Kudos
908 Views
heinzroitner
Contributor II

Hi Rene,

do you also have an explanation what happened here? This would be helpful.

Thanks, Heinz


0 Kudos
908 Views
rendy
NXP Employee
NXP Employee

Hi,

I will check this with MQX team. There is a section in Vybrid Reference Manual - 37.8.5.6 "Conversion Time Examples" - you can check your time constraints there. If it meets your needs, then there will be probably bottleneck in the MQX. I'll be back as soon as I have more info from MQX team.

Rene

0 Kudos
908 Views
heinzroitner
Contributor II

Hi,

the time between ISRs (i.e time needed for one channel conversion) is 8 us. High speed conversion is enabled. So this looks OK.

One type of strange debugger behavior is the overwrite of a certain variable with floating numbers ending in ..E-42. Can you make sense of this? Somehow this must sneak in from the interrrupt ?

Thanks, Heinz

0 Kudos
908 Views
rendy
NXP Employee
NXP Employee

I've just wrote a post about floats below (Oct 1, 2014 11:43 AM). Is it possible for you to defer float processing out of the interrupt context? Aren't there problems with saving of float registers?

0 Kudos