Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Atmega8 crashes when ADC value reads at a fast rate

Status
Not open for further replies.
The Atmega8 crashes when ADC value reads at a fast rate the problem was the ISR.
I excluded the code belongs to intrupt vector and runs it without error .
Can i avoid this error ? if yes how ?
The purpose of the Intrupt using here is the LCD data will be display the data every 2 minutes.
 
Last edited:

Hi,

The Atmega8 crashes when ADC value reads at a fast rate the problem was the ISR.
What are you talking about? I can´t find an ISR in your code.

Klaus
 

Hi,


What are you talking about? I can´t find an ISR in your code.

Klaus
Code:
ISR(TIMER1_COMPA_vect)
{   DELAY_ms(200);
	  sec_cnt++;
	if(sec_cnt ==10)
	{  
		LCD_Clear();
		DELAY_ms(50);
	    lcd_name_display();
		sec_cnt = 0; 
		//LCD_Init(2,16);
		LCD_Clear();
		data_value();	   
						
	}	
	DELAY_ms(50);
}
 

This thread looks pretty jumbled but I'll ask a couple of
thought questions.

If this is a SAR scheme using controller code, is the input
sampled and held? Trying to do successive approximation
when the input is changing can break the seeking loop
if input change invalidates higher order bit decisions already
made.

Is AC waveform violating any input pin constraints? Such
as swinging well below ground? Does the input common
mode happen to change with the input signal frequency,
or input amplitude change?
 

Hi,

I assume you never showed this piece of code.
Nor did you show the Timer0 setup nor the interrupt setup.
So the complete thred was rather useless in my eyes. A waste of time.

Klaus
 

@thannara123; This was the first time that the ISR handler appeared here, indeed just at the 2nd page of this thread; considering that the title of this thread refers to this exact routine, seems like a sloppiness on your side to give an essential information just at the post #23. Now, looking at the code, it is clear the reason, you are adding the infamous delay there, but you were warned many times to avoid that, along many other good practices you got along other threads. I would expect you put in practice at least part of what was told. It is a little demotivating to repeat the same tips at new code you paste here.

As for the code itself, start a new one, use the interrupt timer just to provide a precise clock which will give you the exact timing for all procedures, and call them at specific time slices. Sometimes it is better to get rid of something that is essentially wrong rather than try to fix it.

- - - Updated - - -

Agreeing with Klaus's opinion, this thread was a waste of time so far and given the diagnosis of terminal illness of your code, this thread will be closed in the hope that next time you put in practice at least part of what has already been already recommended.
 
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top