Not Able to update Real time ADC Data on TFT Screen

Sumit Mourya said:

When I debug the code I get the pot value on the display once, but when i adjust the potentiometer the value does not change on the display screen.

My friend - good job (Bravo) on:

• using the forum's code editor
• color-coding different code sections for (your) and your helpers ease/clarity

That said - you've NOT complied w/KISS - have you?   Your troubleshooting does NOT directly deal w/that ADC value!   Instead - transfers it (we (only) hope successfully) to your TFT screen.   This signals that, "one or two of two" program elements may be improper:

• your ADC operation - on subsequent ADC loops - may be bad
• your transmission of the ADC value to the TFT - and any further processing - may be bad
• or both

KISS very much assists by enabling your focus on, "One and only one" program element at a time.   Thus should not you employ your IDE to insure that "all subsequent ADC values prove correct" - BEFORE you transfer them to your TFT?   As good as your descriptive write-up is - we don't note that fact!

Now it may be that your IDE does not allow your "read" of the ADC as such intrusion (by the IDE) "spoils" the ADC reading.   Should this prove the case - does it not prove useful to copy your ADC result to (another/SAFER) variable - which may then be (regularly) examined - to greatly improve your test/troubleshoot?

I (now) note that you've done that - your result is w/in variable adcResult.   Does that variable reflect your (changed) pot position?

Also is Port_E pin 5 (really) represented by "ADC_CTL_CH8?   Perhaps you are not really "connected" as you hope...   Have you read the voltage - at the MCU - on your targeted ADC pin.   (Be careful!)

Overall a very nice forum presentation - please do consider KISS - its "free" - immensely helpful - and vastly under-promoted here & "most schools."

Hi Cb1_mobile,

thanks for replying to my post!

POINT 1 :-

when you say " I (now) note that you've done that - your result is w/in variable adcResult.   Does that variable reflect your (changed) pot position? 

Answer - yes it does. when i check  below code using breakpoint at ADCIntClear(ADC0_BASE, 3), i get the changed value (0-4096) on( "watch expression in refresh all windows mode") adcResult when I change the pot position .

while(1)

{

ADCIntClear(ADC0_BASE, 3);
                                    ADCProcessorTrigger(ADC0_BASE, 3);

                                    while(!ADCIntStatus(ADC0_BASE, 3, false))
                                                {
                                                }
                                                ADCSequenceDataGet(ADC0_BASE, 3, ui32ADC0Value);
                                                adcResult= ui32ADC0Value[0];
}

POINT 2 :-

Also is Port_E pin 5 (really) represented by "ADC_CTL_CH8?   Perhaps you are not really "connected" as you hope...   Have you read the voltage - at the MCU - on your targeted ADC pin.

ANSWER-
Iam using TM4C129XNCZAD MCU. The datasheet says that PE5 is AIN8.

I dont know where iam doing it wrong. pls help

Well answered - thank you.   Today is "moving day" @ my firm's (giant) contractor.   May be several hours (perhaps less) before I can reestablish net connection.

As you succeed w/your transfer once - but only once - I suggest that you look very closely at that transfer code - and seek to, "RETURN to the initial conditions" of that first (and only) successful transfer.   It seems likely that (something) is changing - which precludes the (proper) arrival of new data.

As we are (now) operating in accord w/KISS - cannot you monitor the data transfer to the TFT?   Usually it is necessary to "Readdress the screen cursor" so that you may "over-write" the (earlier) data.   I suspect that:

• you are not passing NEW data to the correct screen address (same as the first transfer did)
• your TFT screen handler is NOT replacing the first (successful) value w/subsequent ones

This should get you going until I (or another) returns.   I've been in the display biz for a LONG time - we've not encountered such an issue.   Usually data goes to the WRONG screen location - which enables the FIRST data sent to "persist" - and in this case the new screen data is noted.   (imperfectly positioned/located)

Hi,

I was able to resolve the issue. All i had to do is add the AdcInit() function along with AdcRead(). I was thinking that I have to Intitalize the Adc only once , but that is not the case. Adc initialization has to be done evry time if you want a new value.

Learned something new from this problem.

void OnIntroPaint(tWidget *psWidget, tContext *psContext)

{

   char sensorValue[100];

Adc_Init();

   Adc_Read();

   usprintf(sensorValue,"%d", adcResult );

   GrContextFontSet(psContext, g_psFontCmss32b);

               GrContextForegroundSet(psContext, ClrCyan);

               GrStringDraw(psContext, "Heart Rate = ", -1,

                                            250, 250, 0);

               GrStringDraw(psContext, sensorValue, 10,

                                500, 250, true);

               WidgetPaint(WIDGET_ROOT);

}

Sumit Mourya said:

Adc initialization has to be done every time if you want a new value.

Very much doubt that - my friend!   (i.e. such cannot be true!)

Perhaps Amit (or other) vendor staff will confirm - but in our (many) years of ADC usage - NEVER/EVER have we found the need for "every time" ADC init...

Nor are (we) arguing w/you - yet it is our "duty" to record our "doubt" for the need for Each/Every time an A/D re-init. Such would (gravely) reduce the ADC's throughput - cannot be required.

May I suggest that you review vendor's API Source code - focused upon your ADC Init().   It seems likely that something you're doing is causing some change(s) to that init - and (that) explains why (excess) ADC inits are required.

One other (potential) issue dawns - that being that the ADC init() is NOT (really) required - but the "added time it requires" enables the ADC to continue its operation. You may test for this condition by employing (other, blind to the ADC) function calls (in place of ADC init) (i.e. repeatedly blink an Led) and noting if they too - enable your ADC to function properly...

Sumit Mourya said:

. I just want to know where am I doing it wrong ?

I did give you a suggestion, have you explored it?

Robert