avrdude memory type enhancement

[stefanrueger]

There isn't really a good authority how the memory should be called that houses the lock bits. Neither the data sheets nor the atdf files have a systematic way of naming. AVRDUDE calls these memories lock unless it's a TPI part (t4, t5, ..., t40, t102, t104), in which case it's lockbits.

Or and that's the surprising bit: if it's the ATmega406 then this memory is also called lockbits.

Any rhyme or reason?

[dl8dtl]

No idea, and actually, I've never even held an ATmega406 in my fingers. It's a quite exotic part – even though it's still in production these days.

The datasheets of the non-Xmega AVRs call it "lock bit byte", the Xmegas call it "lock bit register".

[stefanrueger]

And the ATDFs call that register variously, lockbit (241x), lockbits (45x, Xmegas) and (... wait for it ...) key (37x, Dx).

How about calling the ATmega406's memory lock in avrdude.conf.in based on the strength of the datasheet that also calls that byte lock bit byte. It doesn't terribly matter, but it's kinda a bit more systematic. What actually should happen is that there ought to be an int parameter in each memory section whose bits tell us what the function of that memory is. This saves "AVRDUDE" from faffing around with quite a few strcmp() to figure that out, eg, MEM_IS_FLASH would be set for apptable, application, boot and flash, whilst the various fuses would have MEM_IS_CONFIG or similar. Mucho eleganto.

[dl8dtl]

How about calling the ATmega406's memory lock

I am always hesitant to change things that have alway^H^H^H^H^Hfor a long time been the way they are. You never know whom you might shoot into the foot with renaming things. Frankly, I don't even have the slightest idea whether there's even a single ATmega406 AVRDUDE user – but I am sure, if you gratuitously rename things (even if for a good reason), you might suddenly learn how many active users of it have already been out there. :-)

That's opensource life: if something works, you'll (almost) never hear about it from the users.

[stefanrueger]

for a long time been the way they are

Fair point as to external representation.

For internal use in the code base, I advocate utilising a new memory field mem_type; basically either an internal cache that stores the result of the string of initial strcmp()s to determine the type, or an external facing avrdude.conf entry that can be set (and inherited). Then it doesn't matter (at all) how a memory is called as long as there are no name conflicts. Fun fact: memory names are sometimes invented by AVRDUDE anyway (good); for example, efuse neither occurs as string in the ATmega328P datasheet nor its ATDF (I know: I counted twice).

Attribute	Memory
MEM_IS_EEPROM	eeprom
MEM_IS_FLASH	flash application apptable boot
MEM_IS_CONFIG	lfuse hfuse efuse fuse fuse0 wdtcfg fuse1 bodcfg fuse2 osccfg fuse3 fuse4 tcd0cfg fuse5 syscfg0 fuse6 syscfg1 fuse7 append codesize fuse8 fuse9 bootend bootsize fuses
MEM_IS_LOCK	lock lockbits
MEM_IS_CALIBRATION	tempsense calibration osccal16 osccal20 osc16err osc20err
MEM_IS_SIGNATURE	signature
MEM_IS_ID	signature prodsig sernum usersig
MEM_IS_USER	userrow usersig
MEM_IS_SRAM	data

Note these are soft-assigned: usersig has two attributes, as does signature.

[mcuee]

@stefanrueger

Your proposal seems to be a good one. Maybe we can change this issue into an enhancement.