avr-as help

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey everyone,

I'm just beginning to jump into the world of AVR and I'm having a hard time finding resources on AVR assembler. I've been programming for about 10 years but I've never had a chance to learn ASM; this seems like a perfect opportunity! I'm running Linux and I've got the avr-gcc and avrdude packages up and running. I wrote a quick program in C to test the chip/programmer and everything went well. Can anyone lead me in the right direction? I've searched the forums and Google but I'm not finding any comprehensive resources. I've got the Atmel 8-bit instruction set in front of me but unfortunately it's all a bit too foreign right now.

Thanks!

Ben

Edit:

Here is what I've been able to come up with so far, aside from actually learning the assembly code:

# compile assembly code
avr-as -gstabs -o

# turn object code into hex
avr-objcopy -j .text -O ihex

# program device
avrdude -p attiny2313 -P /dev/parport0 -c bsd -E reset -U flash:w:

If there are any obvious problems here let me know :D

Last Edited: Sun. Dec 9, 2007 - 04:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> If there are any obvious problem

There is: you're loading the relocational object file, rather than
the target file. You'd need to pass it through the linker. The
linker is the tool that assigns absolute memory addresses to the
relocatable regions that are present in the .o files. (file.out
should conventionally rather be named file.o.)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
> If there are any obvious problem

There is: you're loading the relocational object file, rather than
the target file. You'd need to pass it through the linker. The
linker is the tool that assigns absolute memory addresses to the
relocatable regions that are present in the .o files. (file.out
should conventionally rather be named file.o.)

Thanks! Can you tell me the right way to do it with the avr-gcc toolset?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not use Mfile (or just it's template) to make your own Makefile then add your .S file names to the ASRC= line and "make" - simple as that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Why not use Mfile (or just it's template) to make your own Makefile then add your .S file names to the ASRC= line and "make" - simple as that.

Thanks, Mfile got me pretty close. I'd like to write my own Makefile eventually for obvious reasons. But first I'd like to understand exactly how to compile and load everything manually.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uidzer0 wrote:
I'd like to write my own Makefile eventually for obvious reasons.

Reasons that are not obvious to me :?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can always add a -v to the flags passed to the compiler. That will
make the compiler driver (i.e. avr-gcc) tell you the exact options it
is calling the backends with.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks! I created a new Makefile and ran make -n to get the output. Which was exactly what I was looking for.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Reasons that are not obvious to me :?

For the reason they exist... to make things easier.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No it was "writing my own" I was querying - why sweat it - Studio or Mfile already do a grand old job of writing Makefiles for you - so you don't have to worry. As it's quite an advanaced topic (and most people just want to get on and program their AVRs in C or Asm and don't really care how it gets built) it might only be the case that one begins to investigate writing one's own Makefiles when you have a LOT of epxerience of the AVR programming environment in general. In fact that was clearly the goal of the GCC Project system in Studio - to isolate beginners from the techy stuff they didn't need to know about on day one (but sadly they made one or two less than perfect default choises for the user - which is why Mfile is better for the time being)