[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] avr-libc-1.2.1 and atmega8

From: Erik Walthinsen
Subject: Re: [avr-libc-dev] avr-libc-1.2.1 and atmega8
Date: Sun, 30 Jan 2005 15:29:59 -0800
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Joerg Wunsch wrote:
This is an architecture problem.  __mulhi3 is only defined for avr2
and avr3 architectures (old AT90 core that doesn't have hardware
multiplication).  If you're trying to link in objects compiled for the
old core against a libc.a that has been compiled for a new core
(avr4/avr5), you'll get this error.
I wasn't mixing architectures, just using the standard, straight from debian.org packages for gcc-avr-3.4.3, binutils-avr-?? (writing email in windoze, dunno version offhand), and avr-libc-1.0.5. When built for the atmega32 in the device programmer I built for the product I'm shipping, it works just fine. When I change the -mmcu argument to atmega8, it fails. The following code should fail to link for atmega8, with the standard debian tools:

#include <stdio.h>
int main() {

Commenting out fdevopen and the subsequent printf's that obviously rely on it, it compiles and links just fine. Or, target the atmega32,etc. I would have expected that if avr-libc uses multiplication in calloc() and thus in fdevopen/etc., that those same presumably matched tools would be smart enough to actually implement multiplcation, either with a library routine or with native instructions.

In the case of both the atmega32 and the atmega8, MUL/MULS/MULSU are part of the chip (avr4) and therefore it *should* work identically between the two. Obviously something is wrong with one of binutils/gcc/avr-libc that things atmega8 is a dramatically different architecture than the atmega32.

On that subject, I noticed that at least one of the binutils or gcc source trees I was looking at at some point had one or more of the atmega48/88/168 chips listed as the wrong architecture. I don't remember where that was atm, but I'll see if I can find that again and see if it's still a problem in current releases/CVS.

Running ./configure from the toplevel directory is not supported.  You
need to create a separate build directory, and run configure and make
from there.  That's basically what the ./doconf and ./domake scripts
are doing for you.
I've used the script from rod.info to build a toolchain, and it seems to compile/link for the atmega8/atmega48 properly. Now the challenge is to program the chip, which I'm finding I'll have to dive into the just released (literally a day *before* I sent Atmel a note indicating apparently lack of any documentation, which is true as far as their own site goes so far) AVR068 appnote, and update avrdude to support the "STK500 V2" protocol, so a) I can use my recently flashed and thus useless in Linux AVR-ISP, and b) program the q.25 atmega48's I just bought for a bazillion projects.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]