[avr-gcc-list] stumped by my ATmega48 (again)

[joe]

Hi all,

I thought I was getting the hang of this Atmel programming, but after
dusting things off a bit, I'm stumped again.  I have a demo program
from Matthew MacClary at Oregon State that toggles all output pins
every three seconds.  Pin 15 is hooked up to an LED on my breadboard,
and when I install his prebuilt .hex file, the LED lights right up and
does its thing.

But when I build the same source and then install my hex file, the LED
never lights up.

To try to isolate the problem, I reduced the main program to just this:

DDRB = 0xff;
DDRC = 0x7f; /* PORTC has only 7 pins */
DDRD = 0xff;

PORTB = 0xff;
PORTC = 0x7f;
PORTD = 0xff;
return 0;   /* PATCH for testing!  */

I believe this should set all output pins high.  But again, when I
build and install this, nothing; the LED doesn't light up.  Then I
tried setting all ports to 0x00, but that didn't work either.

I'm really stumped here -- such a trivial program shouldn't depend on
any libraries or whatnot.  And I'm pretty sure the compiler itself
works, because I successfully built a number of much more complex
Orangutan programs a while back.  I'm using the same compile command
that Matthew suggests in his comments:

$ avr-gcc -g -Wall -pedantic -Os -mmcu=atmega48 -c -o main.o main.c
$ avr-gcc -I -g -Wall -pedantic -Os -mmcu=atmega48 -Wl,-Map,main.map -o
main.elf main.o
$ avr-objcopy -j .text -j .data -O ihex main.elf main.hex

..but I get a smaller .hex file than he supplied.  Clearly something's
different with my setup, but what would cause such a simple program to
fail?

Thanks,
- Joe

--
Joe Strout -- [EMAIL PROTECTED]
Strout Custom Solutions, LLC



___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: [avr-gcc-list] Missing Section

[Erik Christiansen]

On Thu, Oct 04, 2007 at 09:05:00AM -0700, Gre7g Luterman wrote:
> --- Erik Christiansen <[EMAIL PROTECTED]> wrote:
> 
> > What does "avr-objdump -h" say about .update?
> 
> $ avr-objdump.exe -h RIO-15C/RIO-15C.elf | grep update
>   0 .update   01a6  1e40  1e40 1f24  2**0

Err, I was hoping to see the next line too, 'cos the section attributes
might just provide the clue. ;-)

> > The linker script snippet for .update would be
> > useful too.
> 
> /* Default linker script, for normal executables */
[snip]

OK, your linker script doesn't differ in substance from mine.

> Were the sections created with just a .S file?  Custom
> sections work fine for me also... as long as there is
> one or more .c files in that section.

With a bunch of .s files. My makefile just did:

CC = avr-gcc
CFLAGS = -g -x assembler-with-cpp -mmcu=atmega64 -DMCU=atmega64
AS = avr-as
ASFLAGS = -gstabs -mmcu=atmega64
LD = avr-ld
LDFLAGS = -M -T ../ld.lnk

%.o: %.s
   $(AS) -I$(INC_DIR) $(ASFLAGS) -o $(OBJDIR)/$@ $<
  
%.o: %.c
   $(CC) -I$(INC_DIR) $(CFLAGS) -c -o $(OBJDIR)/$@ $<
 
  ( cd $(OBJDIR) ; $(LD) $(LDFLAGS) -o all.elf app.elf bootloader.elf > 
all.map)
  avr-objcopy -O binary obj/[EMAIL PROTECTED] obj/[EMAIL PROTECTED]
  avr-objdump -D obj/all.elf > obj/all.lst
  avr-objcopy -O srec obj/[EMAIL PROTECTED] obj/[EMAIL PROTECTED]
  avr-objcopy -O ihex obj/all.elf obj/all.hex

But that project has no .c files, so avr-gcc is not invoked at any
stage. avr-as and avr-ld are used directly. Everything cruised smoothly,
including my .boot section. (I've also used .elephant for various
experiments.)

Erik


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: [avr-gcc-list] Missed optimisations when manipulating bytes

[Eric Weddington]

> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of David Brown
> Sent: Thursday, October 04, 2007 8:35 AM
> To: 'AVR-GCC'
> Subject: [avr-gcc-list] Missed optimisations when manipulating bytes
>
> I was looking at the assembly generated from a program I'm
> working on,
> and it strikes me that there is a lot of scope for improvement in the
> register manipulation when mixing bytes and 16-bit words like in the
> code below.  I've only tested using the latest winavr release (gcc
> 4.1.2), so maybe newer versions are better.
>

Hi David,

GCC 4.2.x and 4.3 (unreleased, currently HEAD) may only be marginally better
based on what I've seen with some limited test cases.

It's somewhat known (at least by those who work closely with the toolchain)
about these issues with optimization. Like all open source projects, we
could always do with more volunteers to help.

Here is the known bug list for the AVR toolchain:

This lists all known bugs for binutils, gcc, gdb, with links to the
individual bug reports, and links to bug lists for other projects: avr-libc,
avrdude, avarice.

There are higher priority GCC bugs that *really* need to get fixed before
missed optimizations can even begin to be looked at, such as:

#31786

A regression for 4.1/4.2/4.3. Causes Internal Compiler Error (ICE) on valid
code.

#30243

A regression for 4.1/4.2/4.3. Causes Internal Compiler Error (ICE) on valid
code.

#29524

Regression on 4.2/4.3. Too much RAM used: __clz_tab[] linked.

#27386

AVR: wrong code generated when passing three uint64_t arguments to function.

#27192

Call through function pointer goes to wrong address. Wrong code generated.

#25742

Internal compiler error in gen_rtx_SUBREG.

#31644

[avr] can't find a register in class 'BASE_POINTER_REGS' while reloading
'asm'

And there are other bugs that generate wrong-code too. Some of those are for
C++ and since there are not that many users of C++, it is doubtful when they
will get fixed. There are also many "missed optimization" bugs already
listed there.

Even if one cannot help fix these bugs, it is very helpful to go through the
bug list and try to confirm if the bug still exists, which version of the
compiler it works on and doesn't work on, etc. I've been doing a bit of this
myself lately. Of course, in doing this, it is helpful if you are able to
build the toolchain so you can build the latest snapshot and try it out with
these bugs.

So while I deeply appreciate anyone helping to take a look at what can be
improved with optimizations for the AVR target, to really improve the
quality of AVR GCC, we need to fix these bugs that produce wrong code, or
causes an internal compiler error on valid code.

And specifically, I need to get GCC bug #29524 (above) fixed before I
release the next WinAVR with GCC 4.2.2. That bug has been analyzed; we just
need a fix for it that will be able to be contributed back to GCC and will
fit with the rest of the system.

Eric Weddington





___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

RE: [avr-gcc-list] Boot vector setting for GCC

[Eric Weddington]

> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of ABHIJIT KSHIRSAGAR
> Sent: Thursday, October 04, 2007 12:55 AM
> To: avr-gcc-list@nongnu.org
> Cc: [EMAIL PROTECTED]
> Subject: [avr-gcc-list] Boot vector setting for GCC
>
> Hi,
>
> This may seem like a silly question, but how do i get AVR GCC
> to know what is the boot vector address for a device, which I
> set using the fuses (BOOTRST and BOOTSZ) on the chip?
>

Which AVR device are you using?




___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[avr-gcc-list] Missed optimisations when manipulating bytes

[David Brown]

I was looking at the assembly generated from a program I'm working on, 
and it strikes me that there is a lot of scope for improvement in the 
register manipulation when mixing bytes and 16-bit words like in the 
code below.  I've only tested using the latest winavr release (gcc 
4.1.2), so maybe newer versions are better.



typedef unsigned char uint8_t;
typedef unsigned int uint16_t;

// Relevant exerts from  for quick test
#define SPIF7
//#define SPDR_SFR_IO8 (0x2E)
#define SPDR (*(volatile uint8_t*)(0x4E))

uint8_t spiByte(uint8_t b) {
SPDR = b;
while (!(SPSR & Bit(SPIF))) ;
return SPDR;
}

uint16_t spiWord(uint16_t w) {
uint16_t r;
r = spiByte(w & 0xff);  // LSB first
r |= (spiByte(w >> 8)) << 8;
return r;
}


Relevant parts of listing file:

  21spiByte:
  28  8EBD  out 78-0x20,r24
  29.L2:
  31 0002 0DB4  in __tmp_reg__,77-0x20
  32 0004 07FE  sbrs __tmp_reg__,7
  33 0006 00C0  rjmp .L2
  35 0008 8EB5  in r24,78-0x20
  38 000a 9927  clr r25
  39
  40 000c 0895  ret
  41
  68spiWord:
  77 0018 8EBD  out 78-0x20,r24
  78.L10:
  80 001a 0DB4  in __tmp_reg__,77-0x20
  81 001c 07FE  sbrs __tmp_reg__,7
  82 001e 00C0  rjmp .L10
  84 0020 3EB5  in r19,78-0x20
  88 0022 892F  mov r24,r25
  89 0024 9927  clr r25

  94 0026 8EBD  out 78-0x20,r24
  95.L12:
  97 0028 0DB4  in __tmp_reg__,77-0x20
  98 002a 07FE  sbrs __tmp_reg__,7
  99 002c 00C0  rjmp .L12
 101 002e 2EB5  in r18,78-0x20
 105 0030 832F  mov r24,r19
 106 0032 9927  clr r25

 108 0034 3327  clr r19
 109 0036 322F  mov r19,r18
 110 0038 2227  clr r18
 112 003a 822B  or r24,r18
 113 003c 932B  or r25,r19
 116 003e 0895  ret


The spiByte function is fine, but the spiWord function leaves plenty of 
scope for improvement:


spiWord:
out 78-0x20, r24
.L1:
in __tmp_reg__, 77-0x20
sbrs __tmp_reg__, 7
rjmp .L1
in r24, 77-0x20

out 78-0x20, r25
.L1:
in __tmp_reg__, 77-0x20
sbrs __tmp_reg__, 7
rjmp .L1
in r25, 77-0x20

ret


mvh.,

David


___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[avr-gcc-list] Boot vector setting for GCC

[ABHIJIT KSHIRSAGAR]

Hi,

This may seem like a silly question, but how do i get AVR GCC to know what is the boot vector address for a device, which I set using the fuses (BOOTRST and BOOTSZ) on the chip? 

Abhijit K.







___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list