AVR-Chat

AVR-Chat@yahoogroups.com wrote:
> Thanks for the reply, Dave
> 
> Unfortunately the code snippet below is not the "real" code,
> but a quick throw-together to illustrate the problem I'm having.
> 
> In the real code, the variables are initialized with real data.
> Either statically (for testing) or dynamically from a
> pre-defined location in EEPROM.
> 
> ICC actually initializes the value to 0 automatically as part
> of the compile process anyhow ...
> 
> I'm still having no luck trying to solve this problem - might
> try and use a series of if-then-else handlers instead of the
> alternating while loops ... hmmm ...
> 

I guess the problem must be occurring elsewhere in your program, since
there is nothing wrong with what you posted. Are you saying that if you
compile the snippet as you posted it, it still does not work?

I would try posting this to the icc-avr mailing list, where Richard the
author of ICCAVR resides and will help you out if nobody else can.
http://dragonsgate.net/mailman/listinfo/icc-avr

-- 
Tim Mitchell (tim@sabretechnology.co.uk)
http://www.sabretechnology.co.uk
Sabre Technology (Hull) Ltd: Registered in England and Wales 3131504
3a Newlands Science Park, Inglemire Lane, Hull HU6 7TQ

Hi All,

Thanks for all your advice / help on this irritating problem.

Tim, I suspect you are probably correct - the code segment WAS working
fine, it was only when I went back to check the functionality of the
whole appliance that I discovered the problem - so it must be an
interaction between some other part of the code.

Although at the end of the day, all the code is doing is to
essentially compare var-a with var-b and return a result - even when
the dynamic updating is taken out (and manual value assignment is put
in it's place) it does not work.

This is not the 1st weird behaviour with loop checking I've seen with
this compilier, I had another problem also with the while loops that I
had to "fix" by putting if-then-"break" statements in the code to make
the while loops terminate.

The "fix" was to spend 1/2 a day porting the code into AVR-GCC (thanks
for the suggestion / quick start guide Larry!) - apart from a few
annoying things (e.g. itoa/ltoa's parameters in a different order),
about the only thing that avr-gcc picked up wrong with the code was a
couple of unused variables in main(). But the application now works
fine and all the while{} loops now work as they should.

Chalk one up for avr-gcc! I think avr-gcc will definately be the
compiler of choice for the next project!

Now I just have to figure out how to get gcc to stop optimizing out my
delay routines :)  But very minor in the scheme of things.



Thanks again for all the replies / help.


Cheers,


Jon

Check out the libc FAQ it has many hints/tips for variable optimization (or
how to avoid it) and loop stuff.

In short you need to be very aware of variables that are modified outside
the scope of the C compiler: e.g. interrupts.  Then you need to use the
"volatile" keyword.  I find using "volatile" also useful when creating delay
loops.  But better yet, use the supplied libc functions (delay.h) - or
better yet, look at delay.h and see how the compiler guru's did it.  Many
useful lessons there!

Cheers!

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of luthjej
Sent: Monday, January 29, 2007 4:52 PM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Re: C Code weird behaviour help?

Hi All,

Thanks for all your advice / help on this irritating problem.

Tim, I suspect you are probably correct - the code segment WAS working
fine, it was only when I went back to check the functionality of the
whole appliance that I discovered the problem - so it must be an
interaction between some other part of the code.

Although at the end of the day, all the code is doing is to
essentially compare var-a with var-b and return a result - even when
the dynamic updating is taken out (and manual value assignment is put
in it's place) it does not work.

This is not the 1st weird behaviour with loop checking I've seen with
this compilier, I had another problem also with the while loops that I
had to "fix" by putting if-then-"break" statements in the code to make
the while loops terminate.

The "fix" was to spend 1/2 a day porting the code into AVR-GCC (thanks
for the suggestion / quick start guide Larry!) - apart from a few
annoying things (e.g. itoa/ltoa's parameters in a different order),
about the only thing that avr-gcc picked up wrong with the code was a
couple of unused variables in main(). But the application now works
fine and all the while{} loops now work as they should.

Chalk one up for avr-gcc! I think avr-gcc will definately be the
compiler of choice for the next project!

Now I just have to figure out how to get gcc to stop optimizing out my
delay routines :)  But very minor in the scheme of things.



Thanks again for all the replies / help.


Cheers,


Jon



 
Yahoo! Groups Links

Is this something like what you were trying to achieve

Increments otherval to 650 then jumps to Do_other_stuff

Decrements otherval to 649 then increments to 650 and so on forever?

 

Owen.

 

 

 

 

//ICC-AVR application builder : 30/01/2007 8:29:57 PM
// Target : M16
// Crystal: 4.0000Mhz

#include <iom16v.h>
#include <macros.h>

void port_init(void)
{
 PORTA = 0x00;
 DDRA  = 0x00;
 PORTB = 0x00;
 DDRB  = 0x00;
 PORTC = 0x00; //m103 output only
 DDRC  = 0x00;
 PORTD = 0x00;
 DDRD  = 0x00;
}

//call this routine to initialize all peripherals
void init_devices(void)
{
 //stop errant interrupts until set up
 CLI(); //disable all interrupts
 port_init();

 MCUCR = 0x00;
 GICR  = 0x00;
 TIMSK = 0x00; //timer interrupt sources
 SEI(); //re-enable interrupts
 //all peripherals are now initialized
}

//Code that doesn't work:


unsigned int otherval;

void Do_other_stuff(void)
{

/* do other stuff here ( caution void does not pass a value */

otherval --;

}



main ()
{ 
void Do_other_stuff(void);
unsigned int val;


val = 650;
otherval = 0;
while (1)
{
while (otherval < val)
{
otherval++;
}
while (otherval >= val)
{ 
Do_other_stuff();
}
}

}
                  

 



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