[GN] Flashing for nrf5 examples #2344
Conversation
Strawman for one method of building flashable binaries and a consistent method of flashing them, for parity with some existing `make flash` commands and ultimately for automated testing. This is temporarily wholly inside examples/lock-app/nrf5 in order to experiment with minimal disruption but is intended to become generic. issue project-chip#1520 GN build parity - flashing
|
This pull request introduces 1 alert when merging a1ce584 into 5a61d31 - view on LGTM.com new alerts:
|
examples/lock-app/nrf5/BUILD.gn
Outdated
| # configuration, and that does not seem compatible with Pigweed's toolchain | ||
| # utilities. | ||
|
|
||
| template("flashable_executable") { |
There was a problem hiding this comment.
isn't this specifically nrf5_executable?
There was a problem hiding this comment.
There's nothing really nrf5-specific about it. Many platforms need the objcopy step (or equivalent) and all (?) need the flash-script-builder part. Or, are you suggesting an nrf5_executable layer to contain the platform-specific details like -Oihex?
|
Please move to a common file and also change the lighting app. |
Yes, that's exactly the problem with objcopy not being a config-able first-class tool. |
…p#2310) * Remove include dependency on underlying crypto libraries * Restyled by clang-format * Use nlassert, cpp style cast * Restyled by clang-format * use inline methods to cleanup the code * Restyled by clang-format Co-authored-by: Restyled.io <commits@restyled.io>
|
This pull request introduces 1 alert when merging fd0630d into 9e21bbe - view on LGTM.com new alerts:
|
Strawman for one method of building flashable binaries and a consistent method of flashing them, for parity with some existing `make flash` commands and ultimately for automated testing. This is temporarily wholly inside examples/lock-app/nrf5 in order to experiment with minimal disruption but is intended to become generic. issue project-chip#1520 GN build parity - flashing
and that one script erases (if requested), flashes the softdevice (maybe unless --skip-softdevice passed?), flashes the application, then resets the device? For softdevice handling I'm thinking we should always do the equivalent of
unless told otherwise. One less thing that can go wrong. It's pretty fast.
e.g. have the generated file be simply a function call something like (maybe we should even copy the softdevice .hex file into the output dir to make SOFTDEVICE_PATH a saner path) |
On second thought, we need to wait for automake removal for this.
|
Doesn't this essentially boil down to two command lines? Would it be possible to simplify? |
Hi @kpschoedel. Thank you for this contribution! Would you mind terribly filling out the PR template? Problem<Please describe the problem you're addressing in a way that makes it easy for reviewers to identify how your changes might impact the project.> Summary of Changes<Please describe what you had to touch and how in order to address the problem(s) above> |
Sure. I had it separate because I was aiming for the .flash.py script having nothing platform-dependent.
Sure, it will just take me a moment to learn python packaging.
That's more difficult because the softdevice.hex file doesn't have a fixed name (in Make it's |
Unfortunately, I don't think so. In Make it's a few lines but in GN only programs that are part of its built-in concept of a toolchain are easy to run. So the goal here is to hide the effort under //gn so that at least a program's BUILD.gn is simple. |
48a6eb5 to
8c5caad
Compare
It has a fixed name, s140_nrf52_7.0.1_softdevice.hex Could be an argument in case someone wants to override (the right arg might be "SDK version") |
OK, I'll do that and strip out the Makefile-inspired globbing. |
Let's compare apples to apples here. Are these the same problem?
If we want 2 line approach, then we can certainly check in a 2 line script and call it done. But I think we'll quickly get tired of copy pasting 2 line scripts around (and in reality, this is already more complicated than above - there's the softdevice, and maybe some error handling is warranted e.g. device isn't plugged in, do you need to go install some udev rules?).
|
Make-based builds for nrf5 lock-app and lighting-app had a
make flashcommand to flash the device. GN builds have not had this functionality.With this change, GN builds produce a Python script with the executable name followed by
.flash.pywhich when run flashes an attached device in the same way thatmake flashdoes for Make builds. It is intended that this will evolve into a consistent method for all relevant build artifacts across all platforms, for developers and automated testing. The GNflashable_executable()template is platform-independent and extended with the platform specifics bynrf5_executable().The generated
.flash.pyscript is a minimal wrapper that passes file names to a more generic nrf5 flashing utility script. Similarly, changes to the application BUILD.gn are minimal.issue #1520 GN build parity - flashing