AVR-Chat

So you write all your own print to uart routines including things like
handling double? 

Your statement about non-reentrant is a valid reason for keeping them
out of interupt service routines. 

Ripping a string to the Uart is pretty straight forward and I have done
that. Even converting integers is relatively easy but messing with
doubles (really floats) is not something I want to mess with. 

I have been burned with the time it takes to do a printf ( I did not
realize how long it character took until someone here pointed it out to
me ie 1 ms for each byte at 9600 which is why I now do 38k so at least
is is 4 per ms) and had to actually remove the printf to get a section
of code to work right.  But that would be true if you use printf or roll
your own. 

I guess you could use something like dtostr to write a double to your
own buffer that you control but then dtostr would have the similar
problems of printf (probably not as bad though) 

So how do you handle doubles? Or don't you use doubles 
I avoid them if I can by I am working on a latitude longitude that
requires them.

Some advice to the original poster:
Heed David's advice and only use printf when you need it. 

Also I got thinking how did you know the timer was not working? Maybe
you were trying to access the variable outside if the timer interrupt.
If so then maybe the timer was working but your problem was volatile 

Declare the variable like this because the compiler can't always tell
the ms_count is being updated somewhere else.

volatile uint16_t ms_count;


main
{
while (ms_count < 100)
	;
}

The compiler does not see anything changing ms_count in main so it may
optimize the whole thing in an unexpected way.



-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On
Behalf Of David Kelly
Sent: Thursday, June 02, 2005 11:00 PM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Re: Atmega16 Real time clock



On Jun 1, 2005, at 9:01 PM, wbounce wrote:

> Also is is a bad idea to put the printf statement in because it will 
> actaully take several ms to send all that to the uart

IMHO printf() is a bad idea anywhere in a small embedded application,  
not just in in IRQ service routine where it will call other routines  
which are probably not re-entrant.

Is too hard to determine how much memory its generic formatting  
routines will require to generate output.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.



 
Yahoo! Groups Links