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>
makes it so that we retain the old file, e.g. GP2040CE.uf2.old if we're
about to write GP2040CE.uf2
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
now that we create segmented UF2 files properly in concatenate, we need
the ability to read them, which we'd previously saved for later; that
time is now. the reader now supports jumps forward (but not backwards,
and I don't know how likely it is we'll ever see this)
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
previous commit added the ability to pass a list of location+binary
combinations to create UF2s, meaning we no longer need to pad the
concatenated UF2 the same way we pad the raw binary output. this makes
for a more sanely-sized UF2 and faster write
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this is in preparation for making smaller .uf2 files buy not needing
padding, instead passing multiple location+binary combos to the
converter
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
the UF2 file wasn't converted to binary format before searching for the
board/user config sections, so it was reading the middle of the UF2 file
instead of the end of the binary file and returning that there were no
configs
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
naively adding UF2 blocks together is at least wrong by spec; it
produces one file with wrong block counts --- say I'm writing 3770
blocks, the naive uf2(firmware) + uf2(config) solution yields a file
that says it's 3642 blocks for a while, then 128 blocks. picotool kind
of does a "wtf" at this but writes it anyway, but I am not confident
this is safe, so I'll just do the dumb thing again for now (meaning we
pretty much always write 8128 or 8192 blocks when concatenating configs)
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
the prior version, for the board/user configs, took the whole ~2MB
binary file and converted it to a UF2, which made for a lot of chunks
that were just writing 0s, between the end of the firmware and the start
of the config(s). this changes the logic to build each portion as
separate UF2 chunks and then combine them.
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
