AVR-Chat

On Apr 15, 2005, at 6:43 PM, Chuck Hackett wrote:

> Well, I discovered part of my problem.  The program I'm working with
> was originally written for the ImageCraft C compiler and I'm using
> WinAVR(gcc).  I tried to convert everything as well as I could but
> apparently something I don't understand is going on because I
> downloaded the trial version of ImageCraft V7 today and the program ran
> the first time!  I'm thinking that it has something to do with the
> differences in support for stdout (usart) but I haven't nailed it down.

I see a different religious thread there, that of casually using 
library stdio, malloc, etc, in an embedded application. I'm against it. 
Your project may be, "written in C", but its running in a totally 
different environment than a Unix server.

Before committing to avr-gcc for my current project, and my employer's 
future, I spent a good bit of time looking at the code it generated, 
the mechanism for supporting IRQ, and the startup code before main() 
was called. Avr-gcc passed.

Recently my project was in need of memcpy(). I added the required 
#include, made my call to memcpy(), and before trying to run code the 
first time dug into the output of avr-objdump -DS to see what got 
added. Again was pleased at what I found. Was better than writing my 
own, which I would have left in C because its not important enough to 
my project to create my own. Normally, and I still may do so, I'd copy 
the source out of the library and place it in my project rather than 
link against a provided library.

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

> From: David Kelly
> 
> On Apr 15, 2005, at 6:43 PM, Chuck Hackett wrote:
> 
> > Well, I discovered part of my problem.  ....
> > I'm thinking that it has something to do with the
> > differences in support for stdout (usart) but I haven't nailed it down.
> 
> I see a different religious thread there, that of casually using
> library stdio, malloc, etc, in an embedded application. I'm against it.
> Your project may be, "written in C", but its running in a totally
> different environment than a Unix server.
> ....

Hi David,

Being new to this environment I'm still "getting my sea legs" here but I can see
your point.  As a new person on the block, I would assume that library functions
provided by an embedded C compiler suite would be "appropriate" for the embedded
environment if properly used.  Obviously, "properly used" varies by situation:
lots of "printf"s are probably not appropriate when trying to cram significant
functionality into a Atmel "Tiny" chip but may be perfectly appropriate in other
circumstances on a ATMega128.

In a past life I have been in situations where every byte was precious - even to
the point of stealing a display buffer byte for use in the code of a 2Kb
terminal application (Incoterm terminals if anyone knows what they are).

Unless you're developing an application that has high volume and is price
sensitive these days I think memory is cheaper than man-hours.  My projects are
personal, low volume (1 or two) for control, instrumentation, etc. and in my
case I've 'standardized' on the larger chips due mostly to JTAG support, code
"elbow room", SRAM, and interfaces supported (i.e.: flexibility).

So, yes, I think you're correct in saying that "its running in a totally
different environment than a Unix server" but using *well-written* libraries can
provide a lot of tested functionality and cut down implementation time.

Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844
http://www.whitetrout.net/Chuck