AVR-Chat

i am recieving data serialy from PC to atmega16. i am recieving data 
of four byte frame in avr.then i am setting the avr's ports according 
to data recieved in USART RXC interrupt routine. i is working fine at 
the starting. but after sometime it is mulfunctioning. what should i 
do to resolve the problem.

                    can any body give me its solution.
kindly help me, if you can or if you have any other 
idea................ 
              thanks a lot for it..........

bhadson2001 wrote:
> i am recieving data serialy from PC to atmega16. i am recieving data 
> of four byte frame in avr.then i am setting the avr's ports according 
> to data recieved in USART RXC interrupt routine. i is working fine at 
> the starting. but after sometime it is mulfunctioning. what should i 
> do to resolve the problem.
> 
>                     can any body give me its solution.
> kindly help me, if you can or if you have any other 
> idea................ 
>               thanks a lot for it..........

You do not provide enough information to help solve the problem, so I 
will be general:

#1 you could have a problem with your stack
#2 you could be trashing your buffer
#3 you could have a corrupted data byte that is stopping your Rx routine 
from working....
#4 you could be ending up in an endless loop....

If you can post your code we can look over it.




-- 
Regards,

Kat.

You dont know if the problem is in the communication or the data is messing up the port. So write a serial test that sends a known data packet, and have the receiver check for correct reception. This test confirms that serial comms work (or dont work).

-----Original Message-----
From: bhadson2001 <bhadson2001@yahoo.com>
To: AVR-Chat@yahoogroups.com
Sent: Tue, 5 Feb 2008 5:26 am
Subject: [AVR-Chat] serial communication



i am recieving data serialy from PC to atmega16. i am recieving data 
of four byte frame in avr.then i am setting the avr's ports according 
to data recieved in USART RXC interrupt routine. i is working fine at 
the starting. but after sometime it is mulfunctioning. what should i 
do to resolve the problem.

                    can any body give me its solution.
kindly help me, if you can or if you have any other 
idea................ 
              thanks a lot for it..........



 
Yahoo! Groups Links





________________________________________________________________________
More new features than ever.  Check out the new AOL Mail ! - http://webmail.aol.com


[Non-text portions of this message have been removed]

If it works at first but then quits, I can't help but think you're doing 
something like resetting some of the USART parameters later on in your 
program or rewriting over something you have stored in memory.

Take a look and see if you're changing something like that later on.

Zack

On Tue, 5 Feb 2008, bhadson2001 wrote:

> i am recieving data serialy from PC to atmega16. i am recieving data
> of four byte frame in avr.then i am setting the avr's ports according
> to data recieved in USART RXC interrupt routine. i is working fine at
> the starting. but after sometime it is mulfunctioning. what should i
> do to resolve the problem.
>
>                    can any body give me its solution.
> kindly help me, if you can or if you have any other
> idea................
>              thanks a lot for it..........
>
>

For starters you could show us your code.

DLC

> i am recieving data serialy from PC to atmega16. i am recieving data
> of four byte frame in avr.then i am setting the avr's ports according
> to data recieved in USART RXC interrupt routine. i is working fine at
> the starting. but after sometime it is mulfunctioning. what should i
> do to resolve the problem.
>
>                     can any body give me its solution.
> kindly help me, if you can or if you have any other
> idea................
>               thanks a lot for it..........
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


-- 
Dennis Clark
TTT Enterprises

This is a part of the art that isn't taught much..

How to diagnose or debug a problem.

Basically, you need to divide up your system, to know that "THIS PART
WORKS", and keep sectioning off the problem into a smaller and smaller
space until you have it cornered.

I learned this art in analog electronics, how to divide up the system
and isolate the problem. The approach works just as well with
software, and with microcontrollers it's not all that unusual to have
problems that are both in hardware and in software.

"drive a stake in the gound" with some part of your code that outputs
something you can see, and be absolutely sure that it always works.
Use that to debug other parts of the system.

And then there is what I have taught my students and preach a bit about
on the 'net.  It comes in part from Sherlock Holmes and part from my own
experience:

Data Watson!  Data!  You cannot make bricks without straw.

and

If the data does not make any sense, examine your assumptions, at least
one of them is incorrect.

DLC

> This is a part of the art that isn't taught much..
>
> How to diagnose or debug a problem.
>
> Basically, you need to divide up your system, to know that "THIS PART
> WORKS", and keep sectioning off the problem into a smaller and smaller
> space until you have it cornered.
>
> I learned this art in analog electronics, how to divide up the system
> and isolate the problem. The approach works just as well with
> software, and with microcontrollers it's not all that unusual to have
> problems that are both in hardware and in software.
>
> "drive a stake in the gound" with some part of your code that outputs
> something you can see, and be absolutely sure that it always works.
> Use that to debug other parts of the system.
>
>
>
> Yahoo! Groups Links
>
>
>
>


-- 
Dennis Clark
TTT Enterprises

To add to this, building your program as a set of modules makes this 
process a lot easier.  Your main program would be a series of calls to 
subroutines that would return to the main program when they're done 
doing what ever it is they do.  Doing a flow chart helps in this 
process.  It takes a little more time up front, and forces us to put 
some forethought into what our program is going to do in the beginning, 
but saves time in the long run.

Of course, there are always those who hate to document...


REB


David VanHorn wrote:

>This is a part of the art that isn't taught much..
>
>How to diagnose or debug a problem.
>
>Basically, you need to divide up your system, to know that "THIS PART
>WORKS", and keep sectioning off the problem into a smaller and smaller
>space until you have it cornered.
>
>I learned this art in analog electronics, how to divide up the system
>and isolate the problem. The approach works just as well with
>software, and with microcontrollers it's not all that unusual to have
>problems that are both in hardware and in software.
>
>"drive a stake in the gound" with some part of your code that outputs
>something you can see, and be absolutely sure that it always works.
>Use that to debug other parts of the system.
>
>
>  
>

Too quick with the send button...

If your main program is nothing but a series of calls to subroutines, 
you can divide and conquer by commenting out a particular subroutine 
during test in order to see if that's where your problem is.  This also 
allows for easier simulation and test in that you can test individual 
modules independently of the rest of the program.

It's always easier to beat a critter into submission a little at a time 
than to take everything on all at once.  Those of us with simple minds 
must find simple solutions.  But this, too has been learned in an analog 
world...block out a system, break all of those blocks into smaller and 
simpler blocks.  The system is nothing more than a set of simple 
circuits put together to form a complex function...bricks used to build 
a wall.


REB


Roy E. Burrage wrote:

>To add to this, building your program as a set of modules makes this 
>process a lot easier.  Your main program would be a series of calls to 
>subroutines that would return to the main program when they're done 
>doing what ever it is they do.  Doing a flow chart helps in this 
>process.  It takes a little more time up front, and forces us to put 
>some forethought into what our program is going to do in the beginning, 
>but saves time in the long run.
>
>Of course, there are always those who hate to document...
>
>
>REB
>
>
>David VanHorn wrote:
>
>  
>
>>This is a part of the art that isn't taught much..
>>
>>How to diagnose or debug a problem.
>>
>>Basically, you need to divide up your system, to know that "THIS PART
>>WORKS", and keep sectioning off the problem into a smaller and smaller
>>space until you have it cornered.
>>
>>I learned this art in analog electronics, how to divide up the system
>>and isolate the problem. The approach works just as well with
>>software, and with microcontrollers it's not all that unusual to have
>>problems that are both in hardware and in software.
>>
>>"drive a stake in the gound" with some part of your code that outputs
>>something you can see, and be absolutely sure that it always works.
>>Use that to debug other parts of the system.
>>
>>    
>>
>  
>

At 10:36 PM 5/02/2008, you wrote:
>#4 you could be ending up in an endless loop....

My GUESS is #5 Using the internal clock.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

Hi All. Look at my source code, i couldn't find my fault there.
I want to get 40Khz, but in VMLAB it shows 29Khz.here is my source code.

/*****************************************************
This program was produced by the
CodeWizardAVR V1.24.8b Professional
Automatic Program Generator
© Copyright 1998-2006 Pavel Haiduc, HP InfoTech s.r.l.
http://www.hpinfotech.com

Project : 
Version : 
Date    : 13.02.2008
Author  : Khahramon                            
Company : TUIT                           
Comments: 


Chip type           : ATmega16
Program type        : Application
Clock frequency     : 4,000000 MHz
Memory model        : Small
External SRAM size  : 0
Data Stack size     : 256
*****************************************************/

#include <mega16.h>
#define xtal 4000000

#define hz 40000


interrupt [TIM1_OVF] void timer1_ovf_isr(void)
{
// i need 40Khz signal in PORTA.0, that's way i took 80kHz interrupt 
TCNT1=0x10000-(xtal/1/(2*hz));
PORTA.0^=0x01;


}

void main(void)
{

PORTA=0x00;
DDRA=0x01;
TCCR1A=0x00;
TCCR1B=0x01;
// i need 40Khz signal in PORTA.0, that's way i took 80kHz interrupt 
TCNT1=0x10000-(xtal/1/(2*hz));

ICR1H=0x00;
ICR1L=0x00;
OCR1AH=0x00;
OCR1AL=0x00;
OCR1BH=0x00;
OCR1BL=0x00;



// External Interrupt(s) initialization
// INT0: Off
// INT1: Off
// INT2: Off
MCUCR=0x00;
MCUCSR=0x00;

// Timer(s)/Counter(s) Interrupt(s) initialization
TIMSK=0x04;

// Analog Comparator initialization
// Analog Comparator: Off
// Analog Comparator Input Capture by Timer/Counter 1: Off
ACSR=0x80;
SFIOR=0x00;

// Global enable interrupts
#asm("sei")

while (1)
      {
         
      };
}
/***********************************
Can you help me where's my mistake

At 03:11 PM 14/02/2008, you wrote:
>Clock frequency     : 4,000000 MHz
>
>/***********************************
>Can you help me where's my mistake

Is your clock REALLY 4MHz? Have you set the necessary fuses?

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

yes, i'm sure about that! I'm sending you my CodeVersionAVR , VMLAB and Proteus project version!

John Samperi <samperi@ampertronics.com.au> wrote:                               At 03:11 PM 14/02/2008, you wrote:
 >Clock frequency     : 4,000000 MHz
 >
 >/***********************************
 >Can you help me where's my mistake
 
 Is your clock REALLY 4MHz? Have you set the necessary fuses?
 
 Regards
 
 John Samperi
 
 ********************************************************
 Ampertronics Pty. Ltd.
 11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
 Tel. (02) 9674-6495       Fax (02) 9674-8745
 Email: john@ampertronics.com.au
 Website  http://www.ampertronics.com.au
 *Electronic Design * Custom Products * Contract Assembly
 ********************************************************
 
 
     
                               

 Send instant messages to your online friends http://uk.messenger.yahoo.com 

[Non-text portions of this message have been removed]

--- In AVR-Chat@yahoogroups.com, "khahramon0786" <khahramon0786@...> 
wrote:
>
> // i need 40Khz signal in PORTA.0, that's way i took 80kHz interrupt 
> TCNT1=0x10000-(xtal/1/(2*hz));

Shouldn't that be  TCNT1=0x10000-(xtal/(1/(2*hz))); ??

At 01:34 AM 16/02/2008, you wrote:
>  I'm sending you my CodeVersionAVR , VMLAB and Proteus project version!

And what am I supposed to do with that? Sorry for asking silly
questions.......

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************