AVR Freaks

As I haven't see the suggestion elsewhere in the thread yet can I just mention -save-temps.

Now if this is code being built in Arduino (the use of the word "sketch" suggests yes) then I'm not sure how easy it is to add custom commands to the compilation step. But if you can try adding -save-temps. When foo.c or foo.cpp is built this will lead to a file called foo.s being created. Like the .lss file this is the Asm version of the C/C++ you are building but the difference between this and the .lss is that it is "clean" Asm source that can easily be modified then used to build the code (that's exactly what C/C++ compilation does - converts the source to assembler then assembles it using avr-as).

So if you want to "tinker" with the Asm of a C program just use -save-temps then take the generated .s file as the starting point for your "tinkering". Here's an example:

$ cat avr.c
#define F_CPU 3686400UL
#include <avr/io.h>
#include <util/delay.h>

int main(void) {
	DDRB = 0xFF;
	while(1) {
		PORTB ^= 0xFF;
		_delay_ms(200);
	}
}
$ avr-gcc -mmcu=atmega16 -Os -save-temps avr.c -o avr.elf
$ cat avr.s
	.file	"avr.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__ = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
	.text
.global	main
	.type	main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
	ldi r24,lo8(-1)
	out 55-32,r24
.L2:
	in r24,56-32
	com r24
	out 56-32,r24
	 ldi r24,lo8(147455)
    ldi r25,hi8(147455)
    ldi r26,hlo8(147455)
    1:subi r24,1
    sbci r25,0
    sbci r26,0
    brne 1b
	rjmp .
	nop
	rjmp .L2
	.size	main, .-main

In this you can see that the call to _delay_ms(200) in the source (also based on the 3.6864MHz CPU speed) has generated a loop that counts to 147455 (0x023FFF) . If I look at the lss:

	__builtin_avr_delay_cycles(__ticks_dc);
  76:	8f ef       	ldi	r24, 0xFF	; 255
  78:	9f e3       	ldi	r25, 0x3F	; 63
  7a:	a2 e0       	ldi	r26, 0x02	; 2

You can just about see the 0x023FFF encoded in there but the nibbles are embedded into LDI opcodes and are in the "wrong order". You could see this in the .hex:

$ cat avr.hex
:100000000C942A000C9434000C9434000C943400AA
:100010000C9434000C9434000C9434000C94340090
:100020000C9434000C9434000C9434000C94340080
:100030000C9434000C9434000C9434000C94340070
:100040000C9434000C9434000C9434000C94340060
:100050000C94340011241FBECFE5D4E0DEBFCDBF29
:100060000E9436000C9445000C9400008FEF87BB73
:1000700088B3809588BB8FEF9FE3A2E081509040CA
:0E008000A040E1F700C00000F3CFF894FFCFDE
:00000001FF

Trying to find/change this is actually pretty tricky. While you can do this:

$ avr-objdump -mavr -D avr.hex

avr.hex:     file format ihex


Disassembly of section .sec1:

00000000 <.sec1>:
   0:	0c 94 2a 00 	jmp	0x54	;  0x54
   4:	0c 94 34 00 	jmp	0x68	;  0x68
   8:	0c 94 34 00 	jmp	0x68	;  0x68
   c:	0c 94 34 00 	jmp	0x68	;  0x68
  10:	0c 94 34 00 	jmp	0x68	;  0x68
  14:	0c 94 34 00 	jmp	0x68	;  0x68
  18:	0c 94 34 00 	jmp	0x68	;  0x68
  1c:	0c 94 34 00 	jmp	0x68	;  0x68
  20:	0c 94 34 00 	jmp	0x68	;  0x68
  24:	0c 94 34 00 	jmp	0x68	;  0x68
  28:	0c 94 34 00 	jmp	0x68	;  0x68
  2c:	0c 94 34 00 	jmp	0x68	;  0x68
  30:	0c 94 34 00 	jmp	0x68	;  0x68
  34:	0c 94 34 00 	jmp	0x68	;  0x68
  38:	0c 94 34 00 	jmp	0x68	;  0x68
  3c:	0c 94 34 00 	jmp	0x68	;  0x68
  40:	0c 94 34 00 	jmp	0x68	;  0x68
  44:	0c 94 34 00 	jmp	0x68	;  0x68
  48:	0c 94 34 00 	jmp	0x68	;  0x68
  4c:	0c 94 34 00 	jmp	0x68	;  0x68
  50:	0c 94 34 00 	jmp	0x68	;  0x68
  54:	11 24       	eor	r1, r1
  56:	1f be       	out	0x3f, r1	; 63
  58:	cf e5       	ldi	r28, 0x5F	; 95
  5a:	d4 e0       	ldi	r29, 0x04	; 4
  5c:	de bf       	out	0x3e, r29	; 62
  5e:	cd bf       	out	0x3d, r28	; 61
  60:	0e 94 36 00 	call	0x6c	;  0x6c
  64:	0c 94 45 00 	jmp	0x8a	;  0x8a
  68:	0c 94 00 00 	jmp	0	;  0x0
  6c:	8f ef       	ldi	r24, 0xFF	; 255
  6e:	87 bb       	out	0x17, r24	; 23
  70:	88 b3       	in	r24, 0x18	; 24
  72:	80 95       	com	r24
  74:	88 bb       	out	0x18, r24	; 24
  76:	8f ef       	ldi	r24, 0xFF	; 255
  78:	9f e3       	ldi	r25, 0x3F	; 63
  7a:	a2 e0       	ldi	r26, 0x02	; 2
  7c:	81 50       	subi	r24, 0x01	; 1
  7e:	90 40       	sbci	r25, 0x00	; 0
  80:	a0 40       	sbci	r26, 0x00	; 0
  82:	e1 f7       	brne	.-8      	;  0x7c
  84:	00 c0       	rjmp	.+0      	;  0x86
  86:	00 00       	nop
  88:	f3 cf       	rjmp	.-26     	;  0x70
  8a:	f8 94       	cli
  8c:	ff cf       	rjmp	.-2      	;  0x8c

The address/opcode bytes there mean this code cannot be easily re-assembled. However back at the .s file that I created using -save-temps, say I want to double the speed of the LED flashing by halving the delay from 147,455 to 73,728, I could just do this:

$ sed 's/147455/73728/' avr.s > avrupdate.S
$ avr-gcc -mmcu=atmega16 avrupdate.S -o avr.elf
$ avr-objdump -j .text  -D avr.elf | tail -n 18
  72:	80 95       	com	r24
  74:	88 bb       	out	0x18, r24	; 24
  76:	80 e0       	ldi	r24, 0x00	; 0
  78:	90 e2       	ldi	r25, 0x20	; 32
  7a:	a1 e0       	ldi	r26, 0x01	; 1
  7c:	81 50       	subi	r24, 0x01	; 1
  7e:	90 40       	sbci	r25, 0x00	; 0
  80:	a0 40       	sbci	r26, 0x00	; 0
  82:	e1 f7       	brne	.-8      	; 0x7c <main+0x10>
  84:	00 c0       	rjmp	.+0      	; 0x86 <main+0x1a>
  86:	00 00       	nop
  88:	f3 cf       	rjmp	.-26     	; 0x70 <main+0x4>

0000008a <_exit>:
  8a:	f8 94       	cli

0000008c <__stop_program>:
  8c:	ff cf       	rjmp	.-2      	; 0x8c <__stop_program>

And here I have modified the source to change 0x023FFF to be 0x012000, built it from the Asm (.S) and the disassembled the code once built to reveal that my delay change to 0x012000 has worked.

Bottom line: explore the world of -save-temps

However you can get a .lss file easily enough.  When you 'verify' or 'upload' a sketch, the results of the build are placed into a temporary directory.  On my Linux machine that's found in /tmp/build<some-random-number>/.

Therein you'll find a .elf file which you can pass to avr-objdump with -S.  You can do the same with the .hex file also produced.