I've tried MPLAB X IDE, out of curiosity:
- still works offline, invites for cloud/registration, but not mandatory
- bloated with Facebook, Twitter, etc. icons
- has between 2-7 GB installed
- has a shopping basket in the compiler/debugger menu bar
- their compiler XC8 needs a separate install (not included with the IDE), has a free and a pay version
- it spreads all over the disk, in about 10 different locations
- has an uninstaller but forget crumbs all over the disk, including the udev rules
- has Windows/Linux/Mac versions
Easy to install and use, a decent looking IDE if you can live with its bloatware.
However
-
v4 v5.25 (or v5.35?) was the last version that can still use the PICkit2 to program an MCU from the IDE
-
starting with v5 (v5 is the first supporting Atmel MCUs, too, now at ver MPLAB X IDE v5.45) PICkit2 support was removed, minimal is PICkit3 - either v4 or v5, the standalone programming tool does not support PICkit2, so only programming from the IDE
- I've tried to debug with v4 IDE, original PICkit + its original demo board for PIC16F690,
and it doesn't work ( <--- shouldn't work because PIC16F690 never had debug capabilities), can program but can not debug
- the Microchip IDE I remember using and working properly was called MPLAB IDE (without the X), and it was for windows only
Too big, and certainly not a tool that would trust it to be usable 5 years from now. Even the installers from the last year were having the text white on white, and older versions like v2 refuses to install even with java 8m want java 6.
- the good news is that 'dwdebug' tool (the one based on the reversed engineered debugWIRE protocol), not only can debug in text mod, but it can act like a gdb server for the gcc's gdb debugger. I've tested step by step execution and registry read from gdb-avr, and it worked.
dwdebug device ttyUSB0
Connected to ATtiny13 on /dev/ttyUSB0 at 76043 baud.
0210: f7f1 brne 020e (-1) > u
0212: 9701 sbiw r25:r24, $01
0214: f7d1 brne 020a (-5)
0216: 91ff pop r31
0218: 91ef pop r30
021a: 9508 ret
021c: 9a36 sbi $6, 6
021e: 9936 sbic $6, 6
0220: cffe rjmp 021e (-1) > gdbserver
Didn't receive 0x55 on reconnection, got 80.
Clock speed may have changed, trying to re-sync.
..............Target ready, waiting for GDB connection.
Info : avrchip: hardware has something
Use 'target remote :4444'
Connection accepted.
Got: qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+
Got: vMustReplyEmpty
Got: Hg0
Got: qTStatus
Got: ?
Got: qfThreadInfo
Got: qL1160000000000000000
Got: Hc-1
Got: qC
Got: qAttached
Got: g
Got: qL1160000000000000000
Error reading command. Error code: 0!
0000: c009 rjmp 0014 (+10) > q
A device is connected. Please use one of these quit commands:
qr - Quit leaving device running. Executes a go command before exiting.
qs - Quit leaving the device stopped.
qi - Quit in In-System Programming mode. Use this if you have SCK, MISO and MOSI connected
and want to use SPI programming software such as AVRDUDE.
0000: c009 rjmp 0014 (+10) > qr
These are the registers shown from gdb, after connecting the avr-gdb debugger to the debug server created with dwdebug:
avr-gdb
GNU gdb (GDB) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=avr".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target remote :4444
Remote debugging using :4444
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x00000000 in ?? ()
(gdb) info registers
r0 0x1 1
r1 0x8c 140
r2 0x36 54
r3 0x47 71
r4 0xae 174
r5 0x0 0
r6 0x0 0
r7 0x87 135
r8 0xa2 162
r9 0xc1 193
r10 0x14 20
r11 0x0 0
r12 0x33 51
r13 0xd5 213
r14 0x43 67
r15 0x7b 123
r16 0x9c 156
r17 0x2 2
r18 0xb9 185
r19 0x0 0
r20 0xdc 220
r21 0x0 0
r22 0xa8 168
r23 0xc5 197
r24 0x83 131
r25 0x0 0
r26 0x76 118
r27 0x0 0
r28 0x9e 158
r29 0xf0 240
r30 0x32 50
r31 0x2 2
SREG 0x0 0
SP 0x1f9f 0x801f9f
PC2 0x0 0
pc 0x0 0x0
(gdb) disconnect
Ending remote debugging.
(gdb) quit
IIRC, Eclipse has a GUI for gdb, so it should work to debug AVR targets in GUI mode using a single wire. Must try that, too!
Just in case I will get derail from it and forget what I learned so far:
- AVR microcontrollers (like the ATmega328 from Arduino, or ATmega8, or ATtiny13, etc.) can be programmed in many ways
1. - parallel programming, with lots of wires, good mostly when the MCU was bricked by bad fuses programming
2. - high voltage programming, with +12V on the reset pin, good for MCU with low pin count, where the Reet pin was programmed to become a normal I/O pin
3. - ISP programming, the one that uses MOSI/MISO/SCLK/RESET pins, also the mode available on most boards including Arduino UNO and Nano, usually has a 6 pin connector called ICSP already populated on most boards
4. - debugWIRE, uses only the reset pin as a half-duplex serial port to talk with the MCU. The serial port speed on the debugWIRE (for AVRs) is the MCU clock/128. Since the MCU clock can vary, the host needs a comm port that can be set at an arbitrary speed (note the ttyUSB0 baud rate was 76043
in the example above). At handshake, the debugWIRE host tries various speeds until it receives the expected 0x55 reliably.
From here, half duplex serial at that weird speed it is (unless the MCU clock changes its speed while running - rare but possible). Memory can be read or poked, in AVR the registry and the ports are also mapped as memory, etc. The MCU has dedicated hardware to talk on the debugWIRE, it does not use the AVR core.
There are dedicated hardware breakpoints in the MCU, meaning a separate register to memorize the breakpoint address, and a comparator that continuosly keep an eye on the program counter. When they match, it stops and memory+flags can be read or written. Another way to set a breckpoint is to replace an instruction with the instruction "break".
5. - another mode to program is using a bootloader, like the Arduino does. The MCU can write its own flash, so a small program called bootloader receives somehow (e.g. through a serial port) the program to be written in flash.
- given the above programming modes, debugging can be made many ways, too:
- using the SCPI mode
- using the debugWIRE mode
- using a software stub (a program needs to be added in our own program at compile time, like a little spyware/bootloader kind of, this will consume some flash space and needs to be manually added before compiling)
- and there is the horrible sprint debugging, meaning no debugger, just serial print or blinking pins as a signal
DebugWIRE seems the most appealing because it has dedicated hardware breakpoints registers, and because it uses only the Reset pin, so all the other pins can be used in the final product.
- By default, the debugWIRE mode is disabled, to enable it assert (using ICSP) the DWEN fuse bit and cycle the power of the MCU
- While doing this, the program and memory protect fuse bits must be deasserted
- At next power up, the MCU will be in debug wire mode and it will remain in debugWIRE even after power cycling (and the ICSP mode will remain disabled)
- now debug, inspect variables, change flags, inspect the stack, run step by step or with breakpoints, remove power, etc. do whatever to debug through the debugWIRE
- To get back to the normal ICSP mode, assert (using debugWIRE) the SPIEN bit
- SPIEN asserted enables back the SPI mode (and disable the debugWIRE)
- SPIEN is volatile, so DO NOT power down the MCU, connect the SCPI programmer and de-assert the DWEN fuse. DWEN fuse is not volatile, so now it's all back to normal, and can cycle the power down or do whatever
- in practice, tested only from the command line so far:
- ATtiny13 as target MCU
- PICkit2 controlled by avrdude as ISP AVR programmer (PICkit2 was the only one I found around, and it can be used as an ISP programmer for AVR even if it was made for PIC, but any other AVR ISP programmer will work)
- CH340 generic USB to (TTL) serial adapter as debugWIRE programmer/debugger controlled by dwdebug
- normal dataflow would be
1. Eclipse IDE debugging window ->
2. avr-gdb debugger client ->
3. LAN (localhost) ->
4. dwdebug gdb server ->
5. CH340 USB to serial adapter ->
6. debugWIRE pin (the Reset pin of the ATtiny13)
Briefly tested so far between points 2. to 6. and working.
For ATtiny13 the DWEN fuse is bit 3 of the hfuse byte (there is a high, a low and an extend fuse byte for fuse bits), usually hfuse is 0xff, program it as 0xf7 to assert the DWEN.
# assert DWEN to put the ATtiny13 in debugWIRE mode (hfuse from default 0xff to 0xf7)
./avrdude -p t13 -c pickit2 -C ./../etc/avrdude.conf -U hfuse:w:0xf7:m
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e9007 (probably t13)
avrdude: reading input file "0xf7"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.02s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xf7:
avrdude: load data hfuse data from input file 0xf7:
avrdude: input file 0xf7 contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: safemode: Fuses OK (E:FF, H:F7, L:6A)
avrdude done. Thank you.
If this will works from a GUI, too, will put some pics and connection diagrams
Sorry for the WOT.