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
prior to this, the concatenate assumed it was concatenating a firmware
with a full *storage section*, e.g. the already-padded 8192 bytes, but
it's equally valuable now that I'm creating configs to have just a
config section + footer, which needs to be padded 8192. now concatenate
supports both
now you don't need to fiddle with specific byte ranges of a dump, you
can just dump the whole board if that's more convenient, and
visualize-storage will parse that
also more testing in general
