Anyone have luck using the built-in mEDBG from these boards as stand-alone programmer and debugger? The manual here shows you can disconnect the debugger from the target board, but its not clear whether you can use it with another target MCU (I have an Attiny816 with UPDI). I use Atmel Studio 7 for programming...
The board I'm looking at
https://www.mouser.com/datasheet/2/268/50002683A-1315528.pdf
I figure this is cheaper than getting an Atmel ICE or PICKit 4.
Absolutely! I've even designed a board for it, so you could use an Arduino Pro Micro instead!
Great! Now I can finally "buy" that loaded shopping cart in Mouser...
Thanks!
Based on a design by @DrAzzy (SerialUPDI) which uses simply a USB/UART adapter and software included in the megaTiny core, I made a quick UPDI programmer which gives a relatively smooth workflow from loading a program to to connecting to the UART/serial console and testing/operation. These is (currently) one manual operation to swap the roles between programming and connecting to the UART/serial console.
Someone pointed out to me that that it could even be simpler. Little more than a DPDT switch.
As I understood, however, with some modification to the pymcuprog python code, on which Dr Azzy's solution is based, to propagate either the RTS or DTR signals, the role swapping of the USB/UART adapter could be entirely automatic.
The @hansibull UPDI programmer solution also looks very interesting.
I'd prefer something that is integrated and works with Atmel Studio since that's where I do my programming, hence the cheaper Curiosity board, than the more expensive Atmel-ICE.
FYI: nEDBG (ie: Curiosity) is more future proof than mEDBG (ie: Xplained) for programming and debugging new AVR Dx and Ex devices...
@mraardvark the nice thing about the mEDBG is that everyone can turn their Arduino Pro Micro into a fully working UPDI programmer. It's only a matter of loading a hex file.
I have very little experience with SAMD's but would can the nEDBG hex file be flashed onto a blank SAMD over USB using DFU? It would be nice to offer a versatile 3rd party programmer that utilized the nEDBG code. Do you know if there are any restrictions when it comes to distributing nEDBG binaries, like selling hardware with nEDBG firmware preloaded?
EDIT:
Seems like there are way more SAMD21G18 hardware out there than there are SAMD21E18. Do you know if they are binary compatible, so that the nEDBG firmware would work on the G18?
A fair argument - that there is plenty of capable hardware out there already... but the unfortunate reality is that mEDBG is a "snapshot" that supports very few devices.
Similarly to the mEDBG, the nEDBG is not 'locked'... but it also doesn't have any special 'licence agreement' other than that you agree to when downloading the pack, or buying the hardware...
Did we exchange a few mails about this a year or so ago? 
Was that you? 
The mEDBG is great for programming megaAVR-0 and tinyAVR-0,1,2's but I'd love to provide a more future-proof programmer that also works with Avrdude (through the Avrdude #10000 patch). I'd love to continue the conversation!
I already have a JLINK programmer for the Cortex M0 so that's already covered. I also have an AVR Dragon that support the older PDI interface but not UPDI. It would have been nice if Atmel/Microchip released a firmware for the Dragon that would transform it into a PDI/ICSP/UPDI programmer. But too late for me for that, the ship has sailed and my new dev kit/programmer is already on the way.
How do you use "future proof" and "avrdude" in the same sentence and keep a straight face?
avrdude is and has been a nearly unmitigated disaster nearly as long as I have been using Arduino (which I think was around when the guy bailed) the only mitigation has been a handful of patches practically forced onto the Arduino folks (or, in one of those rare cases where shit rolls uphill, apparent,y someone from Microchip) because of the scope and severity of it's impact......What was the last count of open, untriaged issues on their bug tracker? Was it still in 4 digits or has it hit 5 by now?
Seeing as nobody has been doing more than base minimum gun--to-head maintenance on it for years, and that it hasn't been properly maintained at any point in time since it's creation, avrdude doesn't seem like a good horse to hitch your cart to. If it weren't for some problem with installling the python USB dependancies via board manager or something (that's Quentin's department not mine, and I never kneew what the issue was, just that he suddenly got all pessimistic when I suggested it), I would be calling out to pymcuprog not avrdude to upload via the Microchip programmers.
I have also wished badly that I had the time to implement STK500 and the other protocols people care about in a python program..... a good fraction of the problem with avrdude is just plain kitchensinkism. (far from the only problem but.....)
More or less true, but it's better maintained than most of the other software for those obscure "edge" programming hardware.
[quote]a good fraction of the problem with avrdude is just plain kitchensinkism.
[/quote]
(directly resulting from that obscure edge programmer support, I guess!)
Arguably, there isn't much need to support a lot of those, any more. Not when a $5 Arduino Clone can talk to a PC and run one of the more "standardized" protocols. But I bet a lot of people would be annoyed if avrdude "maintenance" included things like removing PonyProg support...
I have also wished badly that I had the time to implement STK500 and the other protocols people care about in a python program.
Python has looked unexpectedly obnoxious when it comes to supporting 8bit byte streams 
(perhaps I'm just missing something.)
You're right about the whole maintenance thing. It hasn't been updated in years, and even trivial bugs like missing variants in the default avrdude.conf (ATmega324PA for instance).
The whole software project so large and complex that a person like me could never maintain something like this at all. A while ago I tried to look into why my MPLAB SNAP wouldn't work with Avrdude, but I quickly gave up after looking in the source files. Luckily this was fixed in patch #10000, but has yet to be merged upstream.
However, there are reason why I love Avrdude and perfer to use it whenever I can.
If "serial UDPI" was added as a supported protocol in Avrdude I'd be so happy! But that would probably never happen.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
