fast ADC conversion for more than one channel

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

fast ADC conversion for more than one channel

跳至解决方案
2,757 次查看
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

标签 (3)
0 项奖励
回复
1 解答
2,331 次查看
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 项奖励
回复
8 回复数
2,332 次查看
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 项奖励
回复
2,331 次查看
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 项奖励
回复
2,331 次查看
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 项奖励
回复
2,331 次查看
rendy
NXP Employee
NXP Employee

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

Thanks

Rene

0 项奖励
回复
2,331 次查看
heinzroitner
Contributor II

Hi Rene,

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

Thanks, Heinz


0 项奖励
回复
2,331 次查看
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 项奖励
回复
2,331 次查看
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 项奖励
回复
2,331 次查看
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 项奖励
回复