next topic »

[Reply #135 on:]

My 1284s are still in their tube, and the Sanguino I have somewhere that would be easiest to test with is "missing." :-(

If someone can email me the bootloader patched for the 1284P as a hex file, I can test it easily. I have plenty of apps that well exceed the 64KB barrier ;-)

[Reply #136 on:]

If someone can email me the bootloader patched for the 1284P as a hex file, I can test it easily. I have plenty of apps that well exceed the 64KB barrier ;-)

Just sent it to you.

On an unrelated note, the 328p bootloader is now 522 bytes!  10 bytes over.  Using avr-gcc 4.5.3, binutils 2.21, avr-libc 1.7.

EDIT: This is using the tip, 5ec3f2030308.

[Reply #137 on:]

Thanks!  Testing now...

[Reply #138 on:]

No good...


         Programmer Type : STK500
         Description     : Atmel STK500 Version 1.x firmware
         Hardware Version: 3
         Firmware Version: 4.4
         Vtarget         : 0.3 V
         Varef           : 0.3 V
         Oscillator      : 28.800 kHz
         SCK period      : 3.3 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9705
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: reading input file "rp4n_big.cpp.hex"
avrdude: writing flash (127350 bytes):

Writing | ################################################   | 96% 23.02s
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64
Writing | ################################################## | 100% 33.14s

avrdude: failed to write flash memory, rc=-4

avrdude: stk500_cmd(): programmer is out of sync

[Reply #139 on:]

the 328p bootloader is now 522 bytes! [avr-gcc 4.5.3]

Hmm.  Still 500 bytes using 4.3.2
It didn't get bigger from the recent patches, did it?  They weren't expected to change the 328 binary at all!

[Reply #140 on:]

avrdude: writing flash (127350 bytes):

Writing | ################################################   | 96% 23.02s
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64

Hmm, it looks like it got to 96% of a 127k file.  That's pretty good.  I say try on something smaller like 75k.

[Reply #141 on:]

avrdude: writing flash (127350 bytes):

Writing | ################################################   | 96% 23.02s
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64

Hmm, it looks like it got to 96% of a 127k file.  That's pretty good.  I say try on something smaller like 75k.

working on it...

[Reply #142 on:]

avr-gcc 4.5.3

Did you find this somewhere convenient, or put it together from scratch?

[Reply #143 on:]

Actually 127,350 was probably too big because of the space reserved for the boot loader.

I had some trouble compiling a HEX file bigger than 64K. So, I took my big file and cut it down with an editor. I didn't expect it to run, but I did expect it to program in and verify. Here is what I get:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9705
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: reading input file "RP4N_big.hex"
avrdude: writing flash (127350 bytes):

Writing | ################################################## | 100% 22.81s

avrdude: 127350 bytes of flash written
avrdude: verifying flash memory against RP4N_big.hex:
avrdude: load data flash data from input file RP4N_big.hex:
avrdude: input file RP4N_big.hex contains 127350 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 26.72s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x10000
         0xf9 != 0x0c
avrdude: verification error; content mismatch

avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

[Reply #144 on:]

avr-gcc 4.5.3

Did you find this somewhere convenient, or put it together from scratch?

As convenient as it gets.  "apt-get install gcc-avr" from latest Ubuntu 64, 11.10.  http://packages.ubuntu.com/oneiric/gcc-avr

Also for fun just tried it on my hand-built gcc-4.6.2, and in that case it's 524 bytes.  That toolset was self-built (no patches) pulled directly from gnu.org:

* binutils 2.22 http://ftp://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.bz2
* gcc 4.6.2 http://ftp://ftp.gnu.org/gnu/gcc/gcc-4.6.2/gcc-core-4.6.2.tar.bz2
* g++ 4.6.2 http://ftp://ftp.gnu.org/gnu/gcc/gcc-4.6.2/gcc-g++-4.6.2.tar.bz2
* avr-libc 1.8.0 http://download.savannah.gnu.org/releases/avr-libc/avr-libc-1.8.0.tar.bz2

Anyway this is no problem for me because I can easily bump up to the next bootloader size, but probably worth knowing about because now 500 bytes are wasted.

[Reply #145 on:]

Ah.  I'll have to update/reinstall my ubuntu vm.  10.x looks set back to 4.3 (and the update isn't going so well.  Grr.)
Fink LOOKS like it should install 4.5.3 as well, but it's not finding what it thinks is the correct version of binutils.

[Reply #146 on:]

Fink?  So you run mac?

I did this on mac, running CMarrin's avrtools distro http://avr.marrin.org/2011/04/24/mac-avr-toolchain/
    - avr-binutils (version 2.21)
    - avr-gcc (version 4.5.2)
        - gmp (version 5.0.1)
        - mpfr (version 3.01)
        - mpc (version 0.9)
    - avr-libc (version 1.7.1)

It came in at 496 bytes.

[Reply #147 on:]

The optiboot website says Mega support coming soon. Does the current version support Megas? I'm really after faster uploads as it seems to take ages to program and my code is only 20k in size.

Iain

[Reply #148 on:]

preliminary analysis shows that some functions got shorter (thus 4.5.2 going down to 496), but 4.5.3 lost the ability to chain jumps.  This adds about an instruction per command.  Also, I think it's broken.  There's some code that assumes that a stack frame is set up, but since the build suppresses all the normal initialization, it isn't...

Also, disassembly seems to be broken :-(   Ubuntu seems to only be installing binutils 2.20 now.   I wonder if that's this problem?

[Reply #149 on:]

I don't currently have any plans to support the Mega boards.  I've updated the (long obsolete) homepage to remove the "coming in a few days" list...