this should all be tested now:
1. invoking against precompiled _pb2.py files provided by user
2. invoking against .proto files provided by user which must be compiled
3. invoking with a special option to use shipped (by us) .proto files
which must be compiled
4. erroring because none of the above occurred
this took some reorganization, but this should finally give me stability
in using this in GP2040-CE's build process
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
for some reason the GUI pilot server for testing doesn't go to the end
of the input field for edits, so the things that backspaced over old
values need an extra 'end' keypress now. I didn't look into why this is,
because it's fine in the actual GUI regardless
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
note that the google protobuf project does not recommend shipping
generated _pb2.py files, so that functionality has been removed from the
project. this also partially undoes the previous commit since using the
provided .proto files is less of an issue and also the default now, so
maybe don't spam the console as much
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
newer config structures will convert old configs to the new fields'
defaults, meaning the after won't be the same as the before once there's
a proto change not present in the original file (such as with this proto
bump for 0.7.9), so just do a more rudimentary compare
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this allows for loading an existing GP2040-CE dump or board in BOOTSEL
over USB and saving the parsed configuration to a new .bin/.uf2 file.
might be useful for making quick backups or variants of configs
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
prior MIT-licensed versions can be obtained from the Git history; this
does not revoke those versions
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this also bumps the proto files in the test directory as a matter of
convenience, so some tests got updated accordingly
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
take for instance:
repeated AlternativePinMappings alternativePinMappings = 1 [(nanopb).max_count = 3];
this, in C, creates a three-struct-sized array alternativePinMappings[].
in python, this is the same idea, where profileOptions' field is a
special container to which AlternativePinMappings can be added. this
allows adding elements via the UI. it does *NOT* implement limits (yet?)
so you can add more (and I think the board will just ignore them and
drop them on write)
we can save some config lookups in this case (in particular in the case
where we are working with repeateds and the lookup against an iterable
won't work)
this tree UI allows for viewing and basic editing of a configuration
section from a board. it does a decent job of displaying most of the
settings, and editing is equally convenient, as in it tries to handle
enums correctly, but doesn't validate pins or handle long binary strings
well.
saving is done in place --- if a config/storage section was opened, a
config section (no padding) is what results. if a whole board was
opened, the whole binary is rewritten with the new offset config
section. this way, a whole board dump can be changed in place, or a new
config can be made for use in e.g. concatenate to build an image
many enhancements to come over time
