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>
current libraries seem to have problems on Windows with thinking files
are duplicated when they are not, making it impossible to compile .proto
files at runtime in this tool on that platform. this adds a fallback of
using shipped, precompiled files in the package. I was already intending
on providing this as an option anyway, so might as well start doing it
now.
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
with this, the combining methods can combine both a board and user
config into one binary, which is a step closer to having a command that
does it, and then we can start removing BoardConfig.h from the firmware
build and replace it with patched binaries.
to test it, another retrieval method was added too, and this will
probably be used for more dump commands or a better info or something
like that
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this is just to clarify the purpose of this since a related method is
coming soon for the board config
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this allows for putting a JSON representation of a config into the user
config area of a binary to be flashed on the board. this allows for
conveying configs as simple JSON files and using them to convey specific
binaries by parts
this is the start of the support to use JSON files on a *new* section of
the binary reserved for board default configs
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
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
Brian S. Stephan