The WinAVR version of avr-gcc is very old (2010, gcc version 4.3.3), and compiles the current optiboot sources into an object file that is larger than 512 bytes (for the standard compile options.)
In theory, BIGBOOT versions would still be useful, especially on
But it was ALSO recently found to create different and incorrect code when trying to deal with the somewhat odd union that optiboot uses to deal with the non-compiler-allocated buffer:
// read a page worth of contents
bufPtr = buff.bptr;
1fd10: 81 2c mov r8, r1 ;;; r9:r8 = 0x100 (RAMSTART)
;;; which was what we wanted.
1fd12: 99 24 eor r9, r9 ;;; (even if it's a bit weird)
1fd14: 93 94 inc r9
;;; r6 is used as a global register coopy of "buffer"
;;; (loaded somewhat early in the code)
1fc8c: 60 90 00 01 lds r6, 0x0100 ;;; r6 is supposed to be 0x100,
1fc90: 70 90 01 01 lds r7, 0x0101 ;;; but gets @ 0x100 instead!
// later ...
1fd3c: 83 01 movw r16, r6 ;;; get buff from r6
// read a page worth of contents
bufPtr = buff.bptr;
do *bufPtr++ = getch();
1fd3e: 7e d0 rcall .+252 ; 0x1fe3c
1fd40: f8 01 movw r30, r16
1fd42: 81 93 st Z+, r24
1fd44: 8f 01 movw r16, r30
while (--length);
1fd46: 21 97 sbiw r28, 0x01 ; 1
1fd48: d1 f7 brne .-12 ; 0x1fd3e <main+0x124>
`
I feel like I should look for a workaround for this.
The WinAVR version of avr-gcc is very old (2010, gcc version 4.3.3), and compiles the current optiboot sources into an object file that is larger than 512 bytes (for the standard compile options.) In theory, BIGBOOT versions would still be useful, especially on But it was ALSO recently found to create different and incorrect code when trying to deal with the somewhat odd union that optiboot uses to deal with the non-compiler-allocated buffer:
https://www.avrfreaks.net/forum/optiboot-atmega-128a-over-rs485
`Atmel standard (v5.4 based) toolchain:
1fd10: 81 2c mov r8, r1 ;;; r9:r8 = 0x100 (RAMSTART) ;;; which was what we wanted. 1fd12: 99 24 eor r9, r9 ;;; (even if it's a bit weird) 1fd14: 93 94 inc r9
1fd16: 7a d0 rcall .+244 ; 0x1fe0c
1fd18: f4 01 movw r30, r8
1fd1a: 81 93 st Z+, r24
1fd1c: 4f 01 movw r8, r30
1fd1e: f1 e0 ldi r31, 0x01 ; 1
while (--length);
1fd20: af 1a sub r10, r31
1fd22: b1 08 sbc r11, r1
1fd24: c1 f7 brne .-16 ; 0x1fd16 <main+0x112>
4.3.3:
;;; r6 is used as a global register coopy of "buffer" ;;; (loaded somewhat early in the code) 1fc8c: 60 90 00 01 lds r6, 0x0100 ;;; r6 is supposed to be 0x100, 1fc90: 70 90 01 01 lds r7, 0x0101 ;;; but gets @ 0x100 instead!
// later ... 1fd3c: 83 01 movw r16, r6 ;;; get buff from r6 // read a page worth of contents bufPtr = buff.bptr; do *bufPtr++ = getch(); 1fd3e: 7e d0 rcall .+252 ; 0x1fe3c
1fd40: f8 01 movw r30, r16
1fd42: 81 93 st Z+, r24
1fd44: 8f 01 movw r16, r30
while (--length);
1fd46: 21 97 sbiw r28, 0x01 ; 1
1fd48: d1 f7 brne .-12 ; 0x1fd3e <main+0x124>
`
I feel like I should look for a workaround for this.