Implement -c <wildcard>/dev_options for printing programmer entries of avrdude.conf #1059
Conversation
Introduced -p <part>/A, which prints what -p <part>/S used to print, ie, all
components of the part structures including the default ones. Now -p <part>/S
prints the expanded part structure without use of parent and without printing
default values. This functionality is new and predominantly needed for
checking specific avrdude.conf entries, eg, avrdude -p*/St | grep pollindex
The option -p <part>/s continues to print a short entry of `avrdude.conf`
using its parent if so defined:
$ avrdude -p m328p/s
part parent "m328"
desc = "ATmega328P";
id = "m328p";
signature = 0x1e 0x95 0x0f;
;
Also changed usbdev, usbsn, usbvendor and usbproduct components from PROGRAMMER structure to be cached string pointers rather than fixed-size arrays. These will be initialised by pgm_new() with a pointer to nul;
|
I'm getting a compiler error on macOS: After adding |
|
OK - I fixed the MacOS error and warning. I think. The errors we get now may be owing to a changed setup of how flex/bison is being provided for the CI checking. It worked a few minutes ago. |
Thanks! It compiles fine on MacOS now, and it works as described in your first post. Great work! |
Maybe we should move the useful comments away from being throw-away stuff, and get them their own "comment = " grammar entry? Not to be used anywhere inside the normal source code, but that should make it easier to maintain them for conf file rewrites. |
Sounds like a good idea to me! |
|
Currently, there's two types of comments, the "header" on top, and comments between or after lines. Both of them usually provide useful information.
|
|
Nor so sure why the CI build for MSVC failed -- probably a temporary download issue of winflexbison. I can build with VS2022 without issues (also MSYS2 mingw64). |
@stefanrueger |
I just re-triggered the run for it. |
|
@mcuee Clearly, the output on your system misses a lot of lines! Here is what I expect to happen: $ avrdude "-p*" "-c*" >/tmp/avrdude.conf
$ avrdude "-p*/r" "-c*/r" >/tmp/avrdude.raw
$ avrdude "-p*/r" "-c*/r" -C /tmp/avrdude.conf | diff - /tmp/avrdude.raw
$ avrdude "-p*" "-c*" | head
#------------------------------------------------------------
# wiring
#------------------------------------------------------------
programmer
id = "wiring";
desc = "Wiring";
type = "wiring";
connection_type = serial;
;
The file of the generated syntax-correct output: I have made a small change to the source that should not matter (redirection of stderr to stdout replaced by printing directly to stdout). Please could you try again and, if it still does not work, post the generated |
I fear you are right, @MCUdude. I am thinking along the lines of recording in |
@stefanrueger |
Sounds like a good idea!
EDIT:
Apparently yes! |
… otherwise - Replace strdup(s) with cfg_strdup(funname, s) that exits on out of mem - Replace malloc(n) with cfg_malloc(funname, n) that exits on out of mem - Change multiline string scanning in lexer.l to avoid core dump - Remove global variables string_buf and string_bug_ptr - Ensure reading strings unescapes strings C-Style - Ensure writing strings escapes strings C-Style again Commit looks longer than needed as unescape() and auxiliary functions needed to be moved from term.c (not in libavrdude) to config.c (in libavrdude).
This commit deals with default_programmer, default_serial, default_parallel and default_spi. The long term objective is to remove all fixed-size buffers from the structures that lexer.l and config_gram.y deal with.
This commit replaces fixed-string buffers in PROGRAMMER, AVRPART and AVRMEM
that are dealt with by the parser and grammar. Now, string assignments are
always to const char *, ie, these are read-only strings with arbitrary
length.
config_gram.y now only needs to consider one type of string assignment.
This commit also
- Replaces the simple linear-search cache_string() function with faster
hashed cache_string(). Either way, the returned value is likely to be
shared, so should never be free()'d.
- Duplicates hvupdi_support list in pgm_dup() and frees it in pgm_free()
- Adds const qualifier to some function args in avrpart.c and pgm.c
- Hardens some functions against being called with NULL pointers
- Ensures _new() and _dup() functions for parts, programmers and memory
return a suitable memory. Out of memory triggers exit in one of three
functions, cfg_malloc(), cfg_realloc() and cfg_strdup(); there is
rarely anything useful that AVRDUDE or, for that matter, any
application compiled against libavrdude can do once you run out of
memory as AVRDUDE/libavrdude rely heavily on allocation of memory.
|
@MCUdude Yes, creating a syntax-correct avrdude -p*/r -c*/r | sort >/tmp/avrdude.raw
# make some modifications in avrdude.conf to crisp it up
avrdude -p*/r -c*/r | sort | diff - /tmp/avrdude.rawcould act as a proof that changes to |
|
@stefanrueger it would be great if we could re-structure avrdude.conf and implement "proper" inheritance to get the number of lines. Maybe the megaAVR-0, tinyAVR-0,1,2, AVR-Dx and AVR-Ex can feature multiple inheritances? I'm not sure if this will make the conf file more challenging to read, but it will reduce the total number of lines. For example: |
@MCUdude Yes, this is now possible, at the very least by hand. I was thinking that, algorithmically, there is the potential for a chip from a family to first inherit from the ".family" entry and then a potentially second time with a view to get the least lines/chars to describe the part. I wouldn't inherit more often to avoid that a user has to go back several inheritance levels. That could be done either once (in a quick and dirty branch) to generate an equivalent more compact |
|
This commit finalises the PR and for the developer options. Now comments in avrdude.conf are associated to the
This is as good as it gets (I reckon that's sufficient granularity). Remember, this is a developer option, with an intent to make our lives easier. Out of necessity the level of documentation and coverage of edge cases is less than for production user code. Output lines always follow a fixed order, so if a comment refers to a block of assignments, the comment may move as it stays with the associated assignment. Example input: Output: The reason for this is that the comment was associated to the line before |
The generated avrdude.conf by The situation for the jtagkey mentioned is actually okay. |
|
Thanks, @stefanrueger, it works like a charm! Some of the comments in avrdude.conf could need a cleanup or rewrite, but that's for another PR. There are a few compiler warnings though: |
|
MSYS2 mingw64 default build log to show the warnings (seems to be more stringent than Linux and macOS default build). |
|
For compiler warnings, |
|
@mcuee Thanks! I removed the sources for the compiler warning bar one: This is a true warning that is a side effect of needing to adjust a possible change of memory location after a re-alloc, so in a sense this is needed unless one does a larger re-write to store indices relative to the base pointer as opposed to addresses. |
|
Should close Issue #964 |
|
However, I was alarmed to see in @mcuee's output (something that our cmake configuration hides). Just updated |
|
@stefanrueger |
|
@stefanrueger Edit: sorry, that is for git main. Your branch is okay. |
... even if a memory with longer name and same initial part exists
Try
avrdude -c*/hand play with it.Now
avrdude -c* -p*should output a file that could be used to replaceavrdude.conffor the part and programmer definitions.Am aware that currently
avrdude.confhas a lot of very useful comments, particularly the programmers (less so the parts). Am thinking about how to record comments during the lex/yacc parsing phase so that they can be printed at the right location duringavrdude -c* -p*. But that's for another day.