How would a user know? #1019
Replies: 15 comments 46 replies
-
|
@stefanrueger But a counter-proposal from my side: can this can be done by a matrix in the wiki? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, by all means, documentation is key! Good idea: a small matrix of 45 programmer types and 5 families would go a long way of helping users. Once that matrix is established, it might still be useful if AVRDUDE knew about that matrix, too. It could then tell a user "ATxyz cannot be programmed with abc; try avrdude -p ATxyz -c \? to see which programmers might work". (Instead of sending commands to a programmer that applies voltages to who knows which pins and eventually fails with a more or less cryptic error message.) How can that matrix be established in the first place? I for one have no idea! |
Beta Was this translation helpful? Give feedback.
-
|
I don't have much clues about AVR32, so no comment about them. The 8-bit AVRs can be divided according to their possible programming protocols:
Based from that, you then only need to see which programmer offers which interfaces; technicall in AVRDUDE, one programmer type that offers different interfaces is mostly handled as separate programmers (by name, not by implementation). |
Beta Was this translation helpful? Give feedback.
-
|
From here: #509 |
Beta Was this translation helpful? Give feedback.
-
|
From Wikipedia: ATtiny seems to be very complicated. ATtiny11 -- HVSP only ATtiny4/5/9/10/20/40 -- TPI ATtiny13/13A/24/24A/25/44/44A/45/84//84A/85: ISP or HVSP or dW ATtiny2313/2313A/4313/43U/48/87/88: ISP or HVPP or dW New ATtiny 0/1/2 series -- updi |
Beta Was this translation helpful? Give feedback.
-
|
It will probably be good to list the programmer's capability. Microchip tools JTAGICE3 and JTAGICE3+ --JTAG, ISP, PDI, debugWIRE, UPDI, aWire Atmel ICE -- JTAG, ISP, PDI, debugWIRE, UPDI, aWire Power debugger -- JTAG, ISP, PDI, debugWIRE, UPDI (including high voltage UPDI), aWire PICKit 4 (avr mode)-- JTAG (not working for avrdude yet, #1052), ISP, TPI (not working yet, #822), PDI, debugWIRE, UPDI (including high voltage UPDI), aWire EDBG/EDBG MSD/EDBGC -- JTAG, ISP, PDI, debugWIRE, UPDI, aWire AVR ONE -- not supported by avrdude? JTAG, ISP, PDI, debugWIRE, aWire Popular programmers jtag2updi -- UPDI (including high voltage UPDI with proper HW support)
serialupdi -- UPDI (including high voltage UPDI with proper HW support)
avr910: ISP Special programmers: stk500v2 compatible: Scratch Monkey (partial implementation of STK500 V2 protocol) ( Bootloaders: The following page is a good one for AVR programmers (in German, but Google Translate works well). |
Beta Was this translation helpful? Give feedback.
-
@dl8dtl here:
I know the difference between HVPP and HVSP, but I didn't think non-high-voltage parallel programming (PP) existed for AVRs.
I'm not sure if this is Microchips fault or not. I bought a PICkit4 about two years ago, and it was less than $50. Now it's almost $80!
As pointed out in #1052, it's not enough to add a JTAG option in avrdude.conf for the PICkit4 and SNAP. There is something different with these than prevents them from working in JTAG mode with Avrdude. |
Beta Was this translation helpful? Give feedback.
-
|
@MCUdude |
Beta Was this translation helpful? Give feedback.
-
|
I have changed all PP to HVPP. uPDI has been changed to UPDI. Notes have been added for JTAGICE 3 UPDI support. Issue #822 and #1052 are now mentioned for PICKit 4 and SNAP. |
Beta Was this translation helpful? Give feedback.
-
|
The price increase of PICKit 4 is probably because of components shortage (or maybe Microchip uses the chance to increase the price). I actually wanted to buy the PICKit 4 (US$76.99) but in the end bought the SNAP (US$34.09). BTW, the price here in Singapore (Mouser Singapore) is a higher than Microchip Direct listed price. Interestingly PICKit 4 price here (S$119.22 or US$86.23) is similar to Atmel-ICE-PCBA (S$122.62 or US$88.69). SNAP is at S$52.78 (US$38.18). |
Beta Was this translation helpful? Give feedback.
-
|
In terms of the programming interface capability of Microchip programmers, it seems to me the XML files in Microchip/Atmel Studio 7 may be of good reference ( But it is not that complete either, for example, it does not mention the high voltage UPDI capability of PICKit 4. There are also good info about min/max ISP/JTAG/PDI/UPDI frequency in the XML files. |
Beta Was this translation helpful? Give feedback.
-
|
The partdesc pull request #1040 is really good and kind of sorted out the issue with part description. What about a similar thing for the programmers? |
Beta Was this translation helpful? Give feedback.
-
That would be really nice! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for supporting the developer options idea, @mcuee and @MCUdude! Yes, I plan to see how useful the These developer options are independent, though, of the idea above to provide the conditional user options above The latter could become documented useful behaviour for the user. |
Beta Was this translation helpful? Give feedback.
-
|
Sterling work, everyone. Many thanks for the insightful discussion re capabilities of parts and programmers wrt to programming modes (PM). I summarise: will give a good bit-field for a Then, For the parts, there is the I think that's the right level of modelling. For example, What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
Looks like a great modeling to me. Thanks. |
Beta Was this translation helpful? Give feedback.
-
I agree! |
Beta Was this translation helpful? Give feedback.
-
|
I just checked the interfaces known to .atdf files: $ grep INTERFACE atdf/* -h | tr '"<>= ' \\n | grep INTERFACE | sort | uniq -c
21 HVSP_INTERFACE
19 HVSP_INTERFACE_STK600
184 ISP_INTERFACE
182 ISP_INTERFACE_STK600
177 JTAG_INTERFACE
45 PDI_INTERFACE
154 PP_INTERFACE
52 PP_INTERFACE_AVRDRAGON
153 PP_INTERFACE_STK600
12 SENSOR_INTERFACE
14 TXM_PINTERFACE_SELECT
83 UPDI_INTERFACESENSOR_INTERFACE and TXM_PINTERFACE_SELECT and seem to be irrelevant by-catch. But seems there is a distinction between PP and PP for AVRDRAGON, same for STK600. Is that somehow relevant? |
Beta Was this translation helpful? Give feedback.
-
Probably there is a subtle difference, I could be wrong but I think the command to trigger the HVPP mode may be a bit different among the three. Probably it is the same between HVSP_INTERFACE (STK500) and HVSP_INTERFACE_STK600. No idea about why ISP_INTERFACE_STK600 is special. |
Beta Was this translation helpful? Give feedback.
-
The atdf files do not see HVUPDI as own interface type. For these, it's just UPDI with HVUPDI_IMPLEMENTATION being a parameter with values 0, 1 and 2. What's the granularity that we should aim for here?
And... for a part with HVUPDI_IMPLEMENTATION=2 does this mean that there are two interfaces UPDI and HVUPDI or is it one interface (UPDI) that must be entered with high voltage applied to a certain pin? |
Beta Was this translation helpful? Give feedback.
-
|
https://microchipdeveloper.com/mplabx:avr-updi-info
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
From the paremeter.txt file: |
Beta Was this translation helpful? Give feedback.
-
|
Apparently AVR DD family is different from the other UPDI device. UPDI One-Wire Interface for External Programming and On-Chip-Debugging (OCD) |
Beta Was this translation helpful? Give feedback.
-
|
Does Asking for those I can figure out 'TPI', 'UPDI', 'JTAG', 'debugWIRE' and 'ISP' from |
Beta Was this translation helpful? Give feedback.
-
Yes: Lines 113 to 172 in 3e49f07 |
Beta Was this translation helpful? Give feedback.
-
|
Currently Eg: |
Beta Was this translation helpful? Give feedback.
-
|
From here.
Let me try here. |
Beta Was this translation helpful? Give feedback.
-
|
I am using Excel to populate the table and then copy/paste the contents here (I can export as csv as well if required). Updated on 22-Oct-2022.
Extra programmers (not in git master yet)
|
Beta Was this translation helpful? Give feedback.
-
Probably, but there are several other programmers with names and descriptions that don't really reveal any useful information, like |
Beta Was this translation helpful? Give feedback.
-
|
Offhand, I guess their scope is limited about the same as the |
Beta Was this translation helpful? Give feedback.
-
|
I can create a big Excel (but not suitable for reading from github comments) which add more fields.
|
Beta Was this translation helpful? Give feedback.
-
@dl8dtl |
Beta Was this translation helpful? Give feedback.
-
We never did. It just throws some kind of errors if you try it on hardware that doesn't support it. This kind of hardware is likely being rare these days anyway, the B hardware was followed up quite quickly, improving also other hardware things (like the robustness against mistreatment). |
Beta Was this translation helpful? Give feedback.
-
|
Great progress. I think this all is now at a state where we can translate the intelligence of the table above into {"2232HIO", "prog_modes", "PM_TPI|PM_ISP"},
{"4232h", "prog_modes", "PM_TPI|PM_ISP"},
{"arduino", "prog_modes", "PM_SPM"},
{"arduino-ft232r", "prog_modes", "PM_TPI|PM_ISP"},
{"arduinoisp", "prog_modes", "PM_TPI|PM_ISP"},
{"arduinoisporg", "prog_modes", "PM_TPI|PM_ISP"},
{"atmelice", "prog_modes", "PM_JTAG"},
{"atmelice_dw", "prog_modes", "PM_PDI|PM_debugWIRE"},
{"atmelice_isp", "prog_modes", "PM_ISP"},
{"atmelice_pdi", "prog_modes", "PM_PDI"},
{"atmelice_updi", "prog_modes", "PM_UPDI"},
{"avr109", "prog_modes", "PM_SPM"},
{"avr910", "prog_modes", "PM_ISP"},
{"avr911", "prog_modes", "PM_SPM"},
{"avrftdi", "prog_modes", "PM_TPI|PM_ISP"},
{"avrisp", "prog_modes", "PM_ISP"},
{"avrisp2", "prog_modes", "PM_TPI|PM_ISP|PM_PDI"},
{"avrispmkII", "prog_modes", "PM_TPI|PM_ISP|PM_PDI"},
{"avrispv2", "prog_modes", "PM_TPI|PM_ISP|PM_PDI"},
{"buspirate", "prog_modes", "PM_ISP"},
{"buspirate_bb", "prog_modes", "PM_TPI|PM_ISP"},
{"butterfly", "prog_modes", "PM_SPM"},
{"butterfly_mk", "prog_modes", "PM_SPM"},
{"bwmega", "prog_modes", "PM_TPI|PM_ISP"},
{"c232hm", "prog_modes", "PM_TPI|PM_ISP"},
{"c2n232i", "prog_modes", "PM_TPI|PM_ISP"},
{"dasa", "prog_modes", "PM_TPI|PM_ISP"},
{"dasa3", "prog_modes", "PM_TPI|PM_ISP"},
{"diecimila", "prog_modes", "PM_TPI|PM_ISP"},
{"dragon_dw", "prog_modes", "PM_debugWIRE"},
{"dragon_hvsp", "prog_modes", "PM_HVSP"},
{"dragon_isp", "prog_modes", "PM_TPI|PM_ISP"},
{"dragon_jtag", "prog_modes", "PM_JTAG"},
{"dragon_pdi", "prog_modes", "PM_PDI"},
{"dragon_pp", "prog_modes", "PM_HVPP"},
{"ehajo-isp", "prog_modes", "PM_TPI|PM_ISP"},
{"flip1", "prog_modes", "PM_SPM"},
{"flip2", "prog_modes", "PM_SPM"},
{"ft232h", "prog_modes", "PM_TPI|PM_ISP"},
{"ft232r", "prog_modes", "PM_TPI|PM_ISP"},
{"ft245r", "prog_modes", "PM_TPI|PM_ISP"},
{"iseavrprog", "prog_modes", "PM_TPI|PM_ISP"},
{"jtag1", "prog_modes", "PM_JTAG"},
{"jtag1slow", "prog_modes", "PM_JTAG"},
{"jtag2", "prog_modes", "PM_JTAG"},
{"jtag2avr32", "prog_modes", "PM_aWire"},
{"jtag2dw", "prog_modes", "PM_debugWIRE"},
{"jtag2fast", "prog_modes", "PM_JTAG"},
{"jtag2isp", "prog_modes", "PM_ISP"},
{"jtag2pdi", "prog_modes", "PM_PDI"},
{"jtag2slow", "prog_modes", "PM_JTAG"},
{"jtag2updi", "prog_modes", "PM_UPDI"},
{"jtag3", "prog_modes", "PM_JTAG"},
{"jtag3dw", "prog_modes", "PM_debugWIRE"},
{"jtag3isp", "prog_modes", "PM_ISP"},
{"jtag3pdi", "prog_modes", "PM_PDI"},
{"jtag3updi", "prog_modes", "PM_UPDI"},
{"jtagkey", "prog_modes", "PM_TPI|PM_ISP"},
{"jtagmkI", "prog_modes", "PM_JTAG"},
{"jtagmkII", "prog_modes", "PM_JTAG"},
{"jtagmkII_avr32", "prog_modes", "PM_aWire"},
{"ktlink", "prog_modes", "PM_TPI|PM_ISP"},
{"linuxgpio", "prog_modes", "PM_ISP"},
{"linuxspi", "prog_modes", "PM_TPI|PM_ISP"},
{"lm3s811", "prog_modes", "PM_TPI|PM_ISP"},
{"mib510", "prog_modes", "PM_TPI|PM_ISP"},
{"micronucleus", "prog_modes", "PM_SPM"},
{"mkbutterfly", "prog_modes", "PM_SPM"},
{"nibobee", "prog_modes", "PM_TPI|PM_ISP"},
{"o-link", "prog_modes", "PM_TPI|PM_ISP"},
{"openmoko", "prog_modes", "PM_TPI|PM_ISP"},
{"pavr", "prog_modes", "PM_ISP"},
{"pickit2", "prog_modes", "PM_ISP"},
{"pickit4_isp", "prog_modes", "PM_ISP"},
{"pickit4_pdi", "prog_modes", "PM_PDI"},
{"pickit4_updi", "prog_modes", "PM_UPDI"},
{"pkobn_updi", "prog_modes", "PM_UPDI"},
{"ponyser", "prog_modes", "PM_TPI|PM_ISP"},
{"powerdebugger", "prog_modes", "PM_JTAG"},
{"powerdebugger_dw", "prog_modes", "PM_debugWIRE"},
{"powerdebugger_isp", "prog_modes", "PM_ISP"},
{"powerdebugger_pdi", "prog_modes", "PM_PDI"},
{"powerdebugger_updi", "prog_modes", "PM_UPDI"},
{"serialupdi", "prog_modes", "PM_UPDI"},
{"siprog", "prog_modes", "PM_TPI|PM_ISP"},
{"snap_isp", "prog_modes", "PM_ISP"},
{"snap_pdi", "prog_modes", "PM_PDI"},
{"snap_updi", "prog_modes", "PM_UPDI"},
{"stk500", "prog_modes", "PM_ISP"},
{"stk500hvsp", "prog_modes", "PM_HVSP"},
{"stk500pp", "prog_modes", "PM_HVPP"},
{"stk500v1", "prog_modes", "PM_ISP"},
{"stk500v2", "prog_modes", "PM_TPI|PM_ISP"},
{"stk600", "prog_modes", "PM_TPI|PM_ISP"},
{"stk600hvsp", "prog_modes", "PM_HVSP"},
{"stk600pp", "prog_modes", "PM_HVPP"},
{"tc2030", "prog_modes", "PM_TPI|PM_ISP"},
{"teensy", "prog_modes", "PM_SPM"},
{"ttl232r", "prog_modes", "PM_TPI|PM_ISP"},
{"tumpa", "prog_modes", "PM_TPI|PM_ISP"},
{"um232h", "prog_modes", "PM_TPI|PM_ISP"},
{"uncompatino", "prog_modes", "PM_TPI|PM_ISP"},
{"usbasp", "prog_modes", "PM_TPI|PM_ISP"},
{"usbasp-clone", "prog_modes", "PM_TPI|PM_ISP"},
{"usbtiny", "prog_modes", "PM_TPI|PM_ISP"},
{"wiring", "prog_modes", "PM_SPM"},
{"xbee", "prog_modes", "PM_SPM"},
{"xplainedmini", "prog_modes", "PM_ISP"},
{"xplainedmini_dw", "prog_modes", "PM_debugWIRE"},
{"xplainedmini_updi", "prog_modes", "PM_UPDI"},
{"xplainedpro", "prog_modes", "PM_JTAG"},
{"xplainedpro_updi", "prog_modes", "PM_UPDI"},I replaced "x(v2)" in the stk500 entry and "?" in the jtagisp entry with "no PM_TPI". Any comments for other changes? This in turn can later be used to output compatibility info when |
Beta Was this translation helpful? Give feedback.
-
I think this line is okay. Users should specify The following line need to be changed as per @dl8dtl since Series B supports TPI and Series A units were rare. |
Beta Was this translation helpful? Give feedback.
-
|
@stefanrueger Other than the above change for
I agree with you -- not to worry about the programmer name as of now. |
Beta Was this translation helpful? Give feedback.
-
|
This discussion can be closed following PR #1099 (but I don't see an obvious way to do this. Thanks for all the valuable contributions to this truly collaborative effort. |
Beta Was this translation helpful? Give feedback.
-
|
Some excellent notes about programmer here by @MCUdude. The way the programmers treat the passed -B value varies greatly. Here's a few examples:
The conclusion is probably that one should specify the bitclock speed every time if the target is running a slow clock or read/write speed is important. |
Beta Was this translation helpful? Give feedback.
-
|
Draft: 15-Nov-2022
|
Beta Was this translation helpful? Give feedback.
-
Looking at AVRDUDE from a user perspective I wondered how we can answer the following hypothetic, though reasonable, questions:
-cprogrammer?, which programming modes?, ...I realise that AVRDUDE can program a lot of chips with a lot of tools (possibly even a toaster :) but how would a user know? Right now I think they stand little chance of sussing this out, falling short of diligently reading 57,000 lines of C, yacc and lex source code and a few hundred data sheets!
First of all, what does AVRDUDE itself know?
avrdude.conf's parts can be listed withavrdude -p \?, and each one falls into one of five categories:-
AVR8Liff!!(part->flags & AVRPART_HAS_TPI)-
AVR8iff(part->flags & (AVRPART_HAS_TPI | AVRPART_HAS_UPDI | AVRPART_HAS_PDI | AVRPART_AVR32)) == 0-
AVR8_XMEGAiff!!(part->flags & AVRPART_HAS_PDI)-
AVR8Xiff!!(part->flags & AVRPART_HAS_UPDI)-
AVR32iff!!(part->flags & AVRPART_AVR32)As an aside, identifying that a part belongs to the
AVR8family is a bit like UK stamps: they are the only stamps in the world without a country name, because when they were introduced, there were no other stamps. This is a programmer's nightmare (AVR8 detection, not stamps) because whenever a new category comes along, the code for recognising anAVR8family part needs rewriting: I suggest introducing a bitAVRPART_HAS_ISPto cater for theAVR8family.There are sub-categories (debug wire, JTAG, ...); here is how AVRDUDE splits its 313 parts:
AVR8LAVR8AVR8andDWAVR8andJTAGAVR8andJTAGandPAGEBITSTREAMAVR8andNOTSERIALandJTAGAVR8_XMEGAAVR8_XMEGAandJTAGAVR8XAVR32andJTAGAs far as I can tell, AVRDUDE knows a lot less about the capabilities of its programmers. There are around 45 different type strings distributed over the around 100 programmers, but that doesn't help a lot with the above questions: 8 x
jtagice3_updi, 8 xavrftdi, 7 xftdi_syncbb, 6 xjtagice3_isp, 5 xusbtiny, 5 xjtagice3_pdi, 4 xserbb, 4 xjtagice3_dw, 4 xjtagice3, 3 xusbasp, 3 xstk500v2, 3 xstk500, 3 xbutterfly, 2 xjtagmkii_pdi, 2 xjtagmkii_avr32, 2 xavr910, 1 xxbee, 1 xwiring, 1 xteensy, 1 xstk600pp, 1 xstk600hvsp, 1 xstk600, 1 xstk500pp, 1 xstk500hvsp, 1 xstk500generic, 1 xserialupdi, 1 xpickit2, 1 xmicronucleus, 1 xjtagmkii_isp, 1 xjtagmkii_dw, 1 xjtagmkii, 1 xjtagmki, 1 xflip2, 1 xflip1, 1 xdragon_pp, 1 xdragon_pdi, 1 xdragon_jtag, 1 xdragon_isp, 1 xdragon_hvsp, 1 xdragon_dw, 1 xbutterfly_mk, 1 xbuspirate_bb, 1 xbuspirate, 1 xarduino,Would it be feasible to have a
capabilityentry in the programmer structure akin to theflagsentry in the parts structure that allowed AVRDUDE to list the capable programmers given a part:And, vice versa, listing the parts that a programmer can cater for:
Beta Was this translation helpful? Give feedback.
All reactions