[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] FDEV_SETUP_STREAM problem on ATMega8
From: |
Joerg Wunsch |
Subject: |
Re: [avr-libc-dev] FDEV_SETUP_STREAM problem on ATMega8 |
Date: |
Sat, 7 Jul 2007 08:20:11 +0200 |
User-agent: |
Mutt/1.5.11 |
As Eric Weddington wrote:
> > I am new to this list, so I am sorry if this post is OT.
Btw., it would be more appropriate for the avr-gcc-list (on the same
mailman host). avr-libc-dev, as the name suggests, is rather the
forum for developers of avr-libc.
> > I am building my code at the command line with the following:
> >
> > avr-gcc -mmcu=atmega8 jsp.c -o jsp.hex
> >
> >
> > The code builds without warning and everything seems fine.
> That's odd considering your command line above cannot compile a C
> file directly to a hex file. GCC compiles to object code (.o), then
> linked to an ELF file (.elf), then converted to a hex file (.hex)
> via avr-objcopy.
I think you nailed it down with this, Eric. This command-line just
renamed the ELF file into the .hex suffix, but it remains an ELF file
anyway. If you flash that file into the AVR, strange things will
happen...
I can take the input file as given, and by simply converting the ELF
file to a hex file, make everything work here on an STK500.
> Drop your home-grown do-nothing delay loops and use the ones from
> avr-libc.
They aren't do-nothing loops that get optimized away, Eric, due to the
"asm("nop");" loop body. However, they are anything else but a
suitable delay. I didn't time it, but it appears to me they are much
faster than one millisecond per argument count, and they are *way*
faster when turning on any kind of optimization.
Ultimately (after having a look at <util/delay.h> or
<util/delay_basic.h>), rather get used to use timers, James.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)