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

[Erik Walthinsen]

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() {
  fdevopen(....);
}

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.