Split form here JS https://www.avrfreaks.net/commen...
Copy of a message I sent off to AVRSupport@microchip (as they request for people trying to use MPLAB for AVR):
So I’m running MPLABX “latest” on my Mac, compiling AVR projects, and thought I’d provide some feedback (as requested.)
Product Version: MPLAB X IDE v5.05
Java: 1.8.0_144; Java HotSpot(TM) 64-Bit Server VM 25.144-b01
Runtime: Java(TM) SE Runtime Environment 1.8.0_144-b01
System: Mac OS X version 10.13.6 running on x86_64; UTF-8; en_EN (mplab)
User directory: /Volumes/MacOS/HD-Users/BillW/Library/Application Support/mplab_ide/dev/v5.05
Cache directory: /Volumes/MacOS/HD-Users/BillW/Library/Caches/mplab_ide/dev/v5.05/var
This is essentially the first time I have used MPLAB to any extent; normally I use CLI tools. I’m not sure which of the following comments are specific to the new AVR support, and which are generic to MPLAB, or IDEs in general.
I maintain the Optiboot Bootloader (an old version of which is used on Arduino and many derivatives.)
I’m currently working on porting that to the ATmega4809, “just because.” That means that I’m working with bare metal C code - no ASF, no “Atmel Start”, etc.
I’m using an ATmega4809 Xplained Pro board.
1) The “Disassembly view” is showing a disassembly of the object code. It seems to have some sort of “object code generated from the .o files.” While it’s nice that this includes source lines as well as the assembly code, it has problems:
a) frequently has troubles finding the source for the current PC, even when it’s in the user code. It really ought to disassemble what’s there, anyway.
b) only displays one function at a time. In a disassembly view, I want the big picture.
(never mind - just discovered the “program memory panel” displayed as code.
c) In both the disassembly window AND the Program memory, it doesn’t seem to properly figure out the target of rcall/call instructions. The disassembly window shows “CALL __vectors” or “CALL 0x0” (__vectors is a symbol whose value is zero.) The program memory panel shows “call __vectors” as well. I think it doesn’t understand that “call” is a two-word instruction. (other problem: "-mrelax”, which allows two-word calls to be collapsed into one-word “rcall” when possible, should be a default compile option, and not one that has to be entered manually as an “extra.”
d) I can’t single-step at the assembly-instruction level.
e ) related to (d), I can’t figure a way to step through the code that happens prior to “main” - the “reset” button shows the next thing to be executed is the first line of main(), rather than the restart vector and/or crt code.
2) There doesn’t seem to be an effective way to specify a start option other than 0. Since the new-style chips (eg 4809) have the bootloader in low memory, this is especially a problem. (I supposed it could also be solved with a modified linker script.) Atmel-Studio has a link-option for this that sets “—sections-start=.text=100” (for example), but adding this as an extra option in the MPLAB linker option panel results in a executable that seems to break/hang the debugger. (It shouldn’t. The empty space where theoretically a bootloader would go contains a noop-like instructions that it should just step through before getting to the “jmp” that is in the reset vector at the start of the .text section.) (This happens properly in Atmel Studio’s debugger.)
3) Is it really supposed to be consuming 2.5 CPUs worth of cycles when the debug binary is running, even though there are no breakpoints, no watchpoints, and I can’t imagine what they would be communicating about?? Under similar circumstances, a VM running Atmel Studio debugger is essentially idle. I should mention that this seems to be the case when I’m debugging a PIC evaluation board as well (a PIC16F18446-Xpress board)
4) The bootloader-related BOOTEND and APPEND configuration values of the ATmega4809 are not shown in the “configuration bits” panel.
5) in the IO View, registers of a peripheral seem to be shown in alphabetic order, rather than address order. I don’t see how to sort differently.
A bunch of the sub-byte info is generally messed up (it seems to think that BOOTLOCK is a bit in USARTn.CTRLB, for example.)
6) I don’t see a way to get an assembly listing out of the compile step, either the (relatively useless) .s files that the compiler would generate, or the more useful version generated by using “avr-objdump” on the .elf file.
7) I guess I should add my voice to those who think it’s unacceptable for Microchip to have restricted what is essentially the open-source avr-gcc compiler to -O1 optimization levels. If and when Optiboot is ported to the 4809, the chances that it will “fit” in the allocated space with -O1 optimization are essentially zero.
Other than that, it was pretty nice to be using a full-fledged debugger from a native Mac environment, instead of having to fire up a PC or PC VM to run Atmel Studio.
