Closed MCUdude closed 12 months ago
It would be really neat to have something like this. However, the table width has to be calculated by finding the longest memory name and memory size:
avrdude> part
AVR Part : ATmega4808
Serial number : 0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09
Prog. interfaces : UPDI, SPM
Flash size: : 48 kiB
EEPROM size: : 256 bytes
Memories :
| Memory: | Size: | Page size: | Read/write: |
|-----------------|-------|------------|-------------|
| fuses | 1 | 1 | R/W |
| fuse0/wdtcfg | 1 | 1 | R/W |
| fuse1/bodcfg | 1 | 1 | R/W |
| fuse2/osccfg | 1 | 1 | R/W |
| fuse5/syscfg0 | 1 | 1 | R/W |
| fuse6/syscfg1 | 1 | 1 | R/W |
| fuse7/append | 1 | 1 | R/W |
| fuse8/bootend | 1 | 1 | R/W |
| lock | 1 | 1 | R/W |
| prodsig/sigrow | 128 | 128 | R/W |
| signature | 3 | 1 | R |
| tempsense | 2 | 1 | R |
| sernum | 10 | 1 | R |
| osccal16 | 2 | 1 | R |
| osccal20 | 2 | 1 | R |
| osc16err | 2 | 1 | R |
| osc20err | 2 | 1 | R |
| data | 0 | 0 | |
| io | 4352 | 1 | R/W |
| sib | 32 | 1 | R |
| userrow/usersig | 64 | 64 | R/W |
| eeprom | 256 | 64 | R/W |
| flash | 49152 | 128 | R/W |
avrdude> part
AVR Part : ATtiny13
Prog. interfaces : ISP, SPM
Flash size: : 1 kiB
EEPROM size: : 64 bytes
Memories :
| Memory: | Size: | Page size: | Read/write: |
|-------------|-------|------------|-------------|
| eeprom | 64 | 4 | R/W |
| flash | 1024 | 32 | R/W |
| lfuse | 1 | 1 | R/W |
| hfuse | 1 | 1 | R/W |
| lock | 1 | 1 | R/W |
| signature | 3 | 1 | R |
| calibration | 2 | 1 | R |
| io | 64 | 1 | |
Great plans! I like the includion of the serial number (where available). How about a format such as 0001.0203.0405.0607.0809?
I would defo include offset in hex for XMEGAs and modern parts as a wrong value could be the cause for trouble; also it gives you a sense that one memory (eg, boot or sernum) is part of another (flash or sigrow). What are your plans for order? I'd suggest offset order and if offset is the same then the order in which they appear in avr_mem_order
. Headers don't need a colon, Read/write could be abbreviated as R/W; I'd use a - for neither R nor W. (Technically R/W depends on the programmer and it's hard to figure out whether a bootloader offers R or W; eg io for classic parts could actually be R/W given the right bootloader!).
@stefanrueger
How about a format such as 0001.0203.0405.0607.0809?
Is it big endian? Is it little endian? I think it needs annotation because it's not clear.
Following general principles, the notation '00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f' is safe.
One thing to consider is that the part
command doesn't read any memories, it just prints information from Avrdude.conf.
and when using -v, The table and other device information is printed before establishing connection with the target. And this means that it won't be possible to print the serial number unless we have a connection.
I just used the same order as the current implementation uses. And if it's difficult to determine if a memory is R/W, maybe it's best to no R/W to the table?
The terminal
part
command outputs information about the connected part. This command, however, was developed when there were only "classic" AVRs, but now we got "modern ones" (with UPDI) and Xmegas.This is the current output for a measly ATtiny13:
And this is the output for an ATmega4808:
Both contains tons of information, and most of it isn't really useful others than Avrdude developers that cares about chip erase delays and min/max write delays.
How about we redo the entire thing, and only prints "useful information" for the average enthusiast? If more detailed information are needed, use the developer options instead, or read the avrdude.conf.
Now I need to know what you guys think are "necessary information" for the
part
command.