I've just grabbed a 1284 with optiboot on it, which seems to have a somewhat messy pin layout. I understand this is mapped from the base AVR ports (probably wrong terminology).
Anyway, Im trying to understand where things like the external interrupts are mapped, is this anything I could read myself to see where they are(eg from a config file somewhere)?
ATmega pins have several functions and they are hardwired to ATmega's pins. The external interrupts are alternative functions of I/O. The datasheet of ATmega describes the mapping. If you have known pin mapping to Arduino it is not a problem to find out where the ext. interrupt is. For an example: INT0 is on the PD2 of ATmega1284P (pin 16 on DIL package) . There are also RXD1 and PCINT26 functionality and according your map it is D6 on Arduino.
I've had a mega2560 for a couple of years and reverse engineered an avrdude subset to upload sketches to it as part of a larger software project. It used stk500v2 programming. Just got a new UNO R3, which programs fine with Arduino 1.6.9. IT uses stk500/optiboot programming sequences. But my old uploader also sort of works, and there is no code in optiboot to recognize v2 sequences! I've added timing measurement to my own v2 uploader, and the first packet (v2 logon) doesn't get picked up for about 100 ms. Then it loads fine, but every 8 packets (1024 bytes) there is a 6 sec delay before the next packet is accepted.
One of my goals in this is to be able to power on/off the board while debugging hardware w/o having to deal with the IDE and its concept of serial ports (moving USB target on Linux)..My own uploader pokes around and finds the new /dev/ttyACMx port without my intervention. So 2 issues:
why does my loader work at all? The IDE generates 2 hex files, one with bootloader(?) and one without. This is new - could the "bootloader" stuck in the sketch be a v2 loader that runs as an application after a timeout??? Or what?
I'm prepared to add stk500 (v1) code to my uploader - it's simpler than the v2. But is there a way to detect WHICH format to send - without the tables of magic numbers for each board/mcu/etc that seems to be how the current software is designed.
If there's a 6-second delay, that almost certainly means that the Uno is resetting and starting over. What makes you think that it's "working" ? Have you uploaded and successfully run a sketch larger than 1024 bytes? (IMO, it SHOULDN'T work at all. v2 wraps everything into "packets" so that the receiver can check CRC/etc. v1 doesn't understand those...)
I think v2 sends a startup string at poweron, while v1 is quiet until the PC sends it commands...
I tested something with Atmel Studio 6.1. I realized that the SP in debugging is set to 4101h (ATmega1284P) at start with no prologue code like the optiboot has - without .initN sections.
The optiboot says that it is done by hardware reset (SP = RAMEND) except of ATmega8,16,32. However for the ATmega1284P, the RAMEND is 40FFh, not 4101h.
Is it bug in AS6.1?
How about real MCU, is it true that hardware reset initialize the SP to 40FFh? I cannot find info in the datasheet.
Interesting finding about SP.
The bootloader starts with this:
Disassembly of section .text:
0001fc00 <main>:
int main(void)
{
1fc00: 00 d0 rcall .+0 ; 0x1fc02 <main+0x2>
1fc02: 1f 92 push r1
1fc04: cd b7 in r28, 0x3d ; 61
1fc06: de b7 in r29, 0x3e ; 62
...
The first command executed is RCALL (jump to the next instruction). It decrements SP about 2 and even the SP is 0x4101
at start, after the first instruction it has a value 0x40FF - RAMEND of ATmega1284P.
I realized that the SP in debugging is set to 4101h
Really? The datasheet I have says pretty clearly that it should be initialized by hardwre to 0x40FF. Section 7.5.1: "SPH and SPL – Stack Pointer High and Stack pointer Low" I dunno what debugging is doing...
The first command executed is RCALL (jump to the next instruction).
This is the compiler setting up a stack frame to briefly save one of the local variables (when it could easily have saved it in other ways.) the "call .+0" is equivalent to the "sub sp, #stackFrameSize" you'd probably see on an ARM, but it's much smaller on the AVR (where SP is off in IO address space, instead of being a register, and can't easily have arithmetic on it.)
This is actually regarded as a bug in optiboot although perhaps it would be more reasonably considered a compiler bug - it showed up in avr-gcc 4.8, got worse in 4.9, and has disappeared in the latest release from Atmel (5.4?)
Section 7.5.1: "SPH and SPL - Stack Pointer High and Stack pointer Low" I dunno what debugging is doing...
My eyes, I am blind... :o Now, I remember I had read it years ago. Sometimes happen to me it is hard to remember things after some time.
I am accustomed that AS has exact behaviour as real MCU. Yesterday, I had no HW available, I want test it today.
Thank you WestfW for an explanation. I used avr-gcc 4.7.2 for years and now I'm using 4.9.2 long time.
As I see on Atmel web, there is 3.5.4 latest toolchain and still it uses avr-gcc 4.9.2.
GCC: 4.9.2
binutils: 2.26.20160125
avr-libc: "2.0.0"
gdb: 7.8
You wrote avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.0_487) 5.4.0. Where is?
As I see on Atmel web, there is 3.5.4 latest toolchain and still it uses avr-gcc 4.9.2.
You wrote avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.0_487) 5.4.0. Where is?
Atmel Studio 7.0.1416
The following changes are done in Atmel Studio 7.0.1416:
Changed driver to WinUSB for AVR DragonTM, AVRISP mkII, JTAGICE mkII, JTAGICE3, AVR ONE!, STK®600, and QT600
:*
Installer improvements
Improved support for installing older device family packs
AVR 8-bit GCC Toolchain 3.6.0 with upstream versions:
– gcc 5.4.0
– Binutils 2.26.20160125
– avr-libc 2.0.0
– gdb 7.8
And I was able to download the macos version 3.6.0.487 binaries from what I guess is Atmel's Source code distribution site, but I don't see the windows or linux "toolchain" downloads for 3.6.0 in the usual places...
Hm, it looks like MAC is little bit ahead. Win & Lnx still refer to older toolchain. I've downloaded AS 7.0.1417 a week ago but have no time to use yet.