[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] avrstudio and avr-gcc
From: |
Joerg Wunsch |
Subject: |
Re: [avr-gcc-list] avrstudio and avr-gcc |
Date: |
Fri, 9 May 2003 09:45:01 +0200 (MET DST) |
"=?iso-8859-9?Q?=D6mer_Sinan_KAYA?=" <address@hidden> wrote:
> In this function i use 512 as the blocksize and address of the
> reader pointer for first param , when i debug and see = what the
> value of blocksize is , i see 0x033e0527.Am i missing something = ?
If you are prepared to compile your own GNU binutils (Eric recently
posted a pointer here for a description what is needed to do this),
you're welcome to become an alpha tester for the GNU binutils patch
that enables objcopy to convert ELF/stabs debugging information to
COFF debugging information. I'd hope it'll solve your problem as
well.
(Right now, i'm still producing source patches every day or every
second day, that's why i require alpha testers to be able to compile
their own binaries -- lacking MS Windows, i cannot do this myself.)
> I've attached a sample project for avrstudio to the mail which might
> be = put to the project directory so that people might start
> debugging = directly.("classic hello world application",i dont know
> where output of = printf goes, libc documentation says that it has
> to be directed to a = file descriptor)
It goes to nowhere the way you're doing it. You need to fdevopen() a
device (and to supply your own routines to put a character down to
whatever device you've chosen -- there's a sample routine in the docs
for simple UART output).
Anyway, the classical C "hello world" application is certainly not
suited very well for a microcontroller environment:
. printf() & Co are huge, they probably won't even fit into a 2 KB
device
. it requires you to have at least a V.24 interface (which apart from
the UART, requires you to have the level converters)
. it requires quite a bit more of hardware setup and system
initialization than what i'd consider a good beginner's project
. with AVR studio lacking any form of terminal emulation connected to
a U(S)ART of the AVR, you stand no chance to simulate it there (*)
That's why avr-libc comes with that small little demo.c project, that
is fully explained, and requires nothing more but a simple LED
connected to a port pin.
(*) There used to be some stupid TTY ``emulation'' in AVR Studio 3
that is not even supported yet again in AVR Studio 4. It's been done
by a cruel hack that we could perhaps eventually also support in
avr-gcc/avr-libc, but it bypasses any actual UART simulation. In
contrast, VMLAB can simulate a true TTY connected to a simulated UART
(including the gibberish you get if you miss to select the correct
baud rate ;-).
> ------=_NextPart_001_0010_01C31416.E763F6B0
> Content-Type: text/html;
[Please don't post HTML]
--
J"org Wunsch Unix support engineer
address@hidden http://www.interface-systems.de/~j/