make: print spinning icon while flashing/resetting #15970

aabadie · 2021-02-09T17:38:54Z

Contribution description

This is an RFC PR that introduces 2 variables to control the output of the flasher. Most of the time it's just noise, especially when pasting them as test output in a PR. The build system also provides the QUIET variable to silent the compiler output and replace it with a nice output. The idea of this PR is to something similar for the flasher and by default, only display the flasher command.

FLASHERLOG and FLASHER_OUTPUT variables are introduced to give a way to control the flasher output.

The proposed behavior is as follows:

by default, when QUIET=1, nothing is printed to stdout and all output goes to a log file defined by FLASHERLOG
if FLASHERLOG is empty, the output goes to stdout
if QUIET=0 and FLASHERLOG is defined, the output goes to stdout and to the log file.
by default, FLASHERLOG is defined as a file inside the application build directory: $(BINDIR)/$(PROGRAMMER).log

Maybe there's a better way to handle this but the proposed solution in this PR is quite simple. The other possibility that I see is to add a wrapper tool that runs the flasher in background with a nice activity printed during flash (dots or progress bar or whatever).

Testing procedure

By default, no flasher output is printed on stdout and the output is available in log file:

$ make BOARD=hifive1b -C examples/hello-world/ flash-only --no-print-directory 
/work/riot/RIOT/dist/tools/jlink/jlink.sh flash /work/riot/RIOT/examples/hello-world/bin/hifive1b/hello-world.bin > /work/riot/RIOT/examples/hello-world/bin/hifive1b/jlink.log
$ cat /work/riot/RIOT/examples/hello-world/bin/hifive1b/jlink.log
### Flashing Target ###
### Flashing at base address 0x20010000 with offset 0 ###
SEGGER J-Link Commander V6.94b (Compiled Jan 26 2021 18:05:49)
DLL version V6.94b, compiled Jan 26 2021 18:05:34

J-Link Commander will now exit on Error

J-Link Command File read successfully.
Processing script file...

J-Link connection not established yet but required for command.
Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-K22-SiFive compiled Jan 18 2021 09:05:42
Hardware version: V1.00
S/N: 979001370
VTref=3.300V
Target connection not established yet but required for command.
Device "FE310" selected.


Connecting to target via JTAG
ConfigTargetSettings() start
ConfigTargetSettings() end
TotalIRLen = 5, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x20000913, IRLen: 05, Unknown device
Debug architecture:
  RISC-V debug: 0.13
  AddrBits: 7
  DataBits: 32
  IdleClks: 5
Memory access:
  Via system bus: No
  Via ProgBuf: Yes (16 ProgBuf entries)
DataBuf: 1 entries
  autoexec[0] implemented: Yes
Detected: RV32 core
CSR access via abs. commands: No
Temp. halted CPU for NumHWBP detection
HW instruction/data BPs: 8
Support set/clr BPs while running: No
HW data BPs trigger before execution of inst
RISC-V identified.
Halting CPU for downloading file.
Downloading file [/work/riot/RIOT/examples/hello-world/bin/hifive1b/hello-world.bin]...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Programming flash [100%] Done.
J-Link: Flash download: Bank 0 @ 0x20000000: 1 range affected (65536 bytes)
J-Link: Flash download: Total: 0.398s (Prepare: 0.049s, Compare: 0.038s, Erase: 0.171s, Program & Verify: 0.119s, Restore: 0.019s)
J-Link: Flash download: Program & Verify speed: 537 KB/s
O.K.

Reset delay: 0 ms
Reset type Normal: Resets core & peripherals using <ndmreset> bit in <dmcontrol> debug register.
RISC-V: Performing reset via <ndmreset>



Script processing completed.

When QUIET=0, all output is printed both on stdout and in a log file:

QUIET=0 make BOARD=hifive1b -C examples/hello-world/ flash-only --no-print-directory 
/work/riot/RIOT/dist/tools/jlink/jlink.sh flash /work/riot/RIOT/examples/hello-world/bin/hifive1b/hello-world.bin | tee /work/riot/RIOT/examples/hello-world/bin/hifive1b/jlink.log
### Flashing Target ###
### Flashing at base address 0x20010000 with offset 0 ###
SEGGER J-Link Commander V6.94b (Compiled Jan 26 2021 18:05:49)
DLL version V6.94b, compiled Jan 26 2021 18:05:34

J-Link Commander will now exit on Error

J-Link Command File read successfully.
Processing script file...

J-Link connection not established yet but required for command.
Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-K22-SiFive compiled Jan 18 2021 09:05:42
Hardware version: V1.00
S/N: 979001370
VTref=3.300V
Target connection not established yet but required for command.
Device "FE310" selected.


Connecting to target via JTAG
ConfigTargetSettings() start
ConfigTargetSettings() end
TotalIRLen = 5, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x20000913, IRLen: 05, Unknown device
Debug architecture:
  RISC-V debug: 0.13
  AddrBits: 7
  DataBits: 32
  IdleClks: 5
Memory access:
  Via system bus: No
  Via ProgBuf: Yes (16 ProgBuf entries)
DataBuf: 1 entries
  autoexec[0] implemented: Yes
Detected: RV32 core
CSR access via abs. commands: No
Temp. halted CPU for NumHWBP detection
HW instruction/data BPs: 8
Support set/clr BPs while running: No
HW data BPs trigger before execution of inst
RISC-V identified.
Halting CPU for downloading file.
Downloading file [/work/riot/RIOT/examples/hello-world/bin/hifive1b/hello-world.bin]...
Comparing flash   [100%] Done.
J-Link: Flash download: Bank 0 @ 0x20000000: Skipped. Contents already match
O.K.

Reset delay: 0 ms
Reset type Normal: Resets core & peripherals using <ndmreset> bit in <dmcontrol> debug register.
RISC-V: Performing reset via <ndmreset>



Script processing completed.


$ cat /work/riot/RIOT/examples/hello-world/bin/hifive1b/jlink.log
### Flashing Target ###
### Flashing at base address 0x20010000 with offset 0 ###
SEGGER J-Link Commander V6.94b (Compiled Jan 26 2021 18:05:49)
DLL version V6.94b, compiled Jan 26 2021 18:05:34

J-Link Commander will now exit on Error

J-Link Command File read successfully.
Processing script file...

J-Link connection not established yet but required for command.
Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-K22-SiFive compiled Jan 18 2021 09:05:42
Hardware version: V1.00
S/N: 979001370
VTref=3.300V
Target connection not established yet but required for command.
Device "FE310" selected.


Connecting to target via JTAG
ConfigTargetSettings() start
ConfigTargetSettings() end
TotalIRLen = 5, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x20000913, IRLen: 05, Unknown device
Debug architecture:
  RISC-V debug: 0.13
  AddrBits: 7
  DataBits: 32
  IdleClks: 5
Memory access:
  Via system bus: No
  Via ProgBuf: Yes (16 ProgBuf entries)
DataBuf: 1 entries
  autoexec[0] implemented: Yes
Detected: RV32 core
CSR access via abs. commands: No
Temp. halted CPU for NumHWBP detection
HW instruction/data BPs: 8
Support set/clr BPs while running: No
HW data BPs trigger before execution of inst
RISC-V identified.
Halting CPU for downloading file.
Downloading file [/work/riot/RIOT/examples/hello-world/bin/hifive1b/hello-world.bin]...
Comparing flash   [100%] Done.
J-Link: Flash download: Bank 0 @ 0x20000000: Skipped. Contents already match
O.K.

Reset delay: 0 ms
Reset type Normal: Resets core & peripherals using <ndmreset> bit in <dmcontrol> debug register.
RISC-V: Performing reset via <ndmreset>



Script processing completed.

if FLASHERLOG (or FLASHER_OUTPUT) is empty, output is always printed to stdout:

$ FLASHERLOG= make BOARD=hifive1b -C examples/hello-world/ flash-only --no-print-directory 
/work/riot/RIOT/dist/tools/jlink/jlink.sh flash /work/riot/RIOT/examples/hello-world/bin/hifive1b/hello-world.bin 
### Flashing Target ###
### Flashing at base address 0x20010000 with offset 0 ###
SEGGER J-Link Commander V6.94b (Compiled Jan 26 2021 18:05:49)
DLL version V6.94b, compiled Jan 26 2021 18:05:34

J-Link Commander will now exit on Error

J-Link Command File read successfully.
Processing script file...

J-Link connection not established yet but required for command.
Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-K22-SiFive compiled Jan 18 2021 09:05:42
Hardware version: V1.00
S/N: 979001370
VTref=3.300V
Target connection not established yet but required for command.
Device "FE310" selected.


Connecting to target via JTAG
ConfigTargetSettings() start
ConfigTargetSettings() end
TotalIRLen = 5, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x20000913, IRLen: 05, Unknown device
Debug architecture:
  RISC-V debug: 0.13
  AddrBits: 7
  DataBits: 32
  IdleClks: 5
Memory access:
  Via system bus: No
  Via ProgBuf: Yes (16 ProgBuf entries)
DataBuf: 1 entries
  autoexec[0] implemented: Yes
Detected: RV32 core
CSR access via abs. commands: No
Temp. halted CPU for NumHWBP detection
HW instruction/data BPs: 8
Support set/clr BPs while running: No
HW data BPs trigger before execution of inst
RISC-V identified.
Halting CPU for downloading file.
Downloading file [/work/riot/RIOT/examples/hello-world/bin/hifive1b/hello-world.bin]...
Comparing flash   [100%] Done.
J-Link: Flash download: Bank 0 @ 0x20000000: Skipped. Contents already match
O.K.

Reset delay: 0 ms
Reset type Normal: Resets core & peripherals using <ndmreset> bit in <dmcontrol> debug register.
RISC-V: Performing reset via <ndmreset>



Script processing completed.

$ FLASHERLOG= QUIET=0 make BOARD=hifive1b -C examples/hello-world/ flash-only --no-print-directory 
/work/riot/RIOT/dist/tools/jlink/jlink.sh flash /work/riot/RIOT/examples/hello-world/bin/hifive1b/hello-world.bin 
### Flashing Target ###
### Flashing at base address 0x20010000 with offset 0 ###
SEGGER J-Link Commander V6.94b (Compiled Jan 26 2021 18:05:49)
DLL version V6.94b, compiled Jan 26 2021 18:05:34

J-Link Commander will now exit on Error

J-Link Command File read successfully.
Processing script file...

J-Link connection not established yet but required for command.
Connecting to J-Link via USB...O.K.
Firmware: J-Link OB-K22-SiFive compiled Jan 18 2021 09:05:42
Hardware version: V1.00
S/N: 979001370
VTref=3.300V
Target connection not established yet but required for command.
Device "FE310" selected.


Connecting to target via JTAG
ConfigTargetSettings() start
ConfigTargetSettings() end
TotalIRLen = 5, IRPrint = 0x01
JTAG chain detection found 1 devices:
 #0 Id: 0x20000913, IRLen: 05, Unknown device
Debug architecture:
  RISC-V debug: 0.13
  AddrBits: 7
  DataBits: 32
  IdleClks: 5
Memory access:
  Via system bus: No
  Via ProgBuf: Yes (16 ProgBuf entries)
DataBuf: 1 entries
  autoexec[0] implemented: Yes
Detected: RV32 core
CSR access via abs. commands: No
Temp. halted CPU for NumHWBP detection
HW instruction/data BPs: 8
Support set/clr BPs while running: No
HW data BPs trigger before execution of inst
RISC-V identified.
Halting CPU for downloading file.
Downloading file [/work/riot/RIOT/examples/hello-world/bin/hifive1b/hello-world.bin]...
Comparing flash   [100%] Done.
J-Link: Flash download: Bank 0 @ 0x20000000: Skipped. Contents already match
O.K.

Reset delay: 0 ms
Reset type Normal: Resets core & peripherals using <ndmreset> bit in <dmcontrol> debug register.
RISC-V: Performing reset via <ndmreset>



Script processing completed.

Issues/PRs references

Depends on ~~#16046~~, ~~#16047~~, ~~#16050~~

fjmolinas

I'm not sure about this one. I do agree that flashing output is too verbose, so we definitely could suppress a part of it. But I definitely think we need some output: flash progress, or at least "Flashing started, Flashing done", the flasher used, maybe there is ways of launching the flashers in amore silent way as well no?

Makefile.include

aabadie · 2021-02-16T18:03:31Z

we need some output: flash progress, or at least "Flashing started, Flashing done", the flasher used, maybe there is ways of launching the flashers in amore silent way as well no?

I'm looking into this and it's not easily achievable. Anyway this PR is broken in its current state: it works well with JLink (the programmer I used initially) but with openocd and pyocd it doesn't.
I'm marking this PR as WIP as it needs more work.

aabadie · 2021-02-18T10:40:09Z

@fjmolinas after your initial review, I completely reworked this PR. Now a new programmer wrapper tool is introduced (written in Python) to silence the output of flashers/reset and print a spinning icon instead.
There's no more log file (in the end I found that made little sense for flash/reset) but a PROGRAMMER_QUIET is introduced. Using PROGRAMMER_QUIET=0 and you get the same output as before.

I tried the programmer.py tool with several programmers and found a couple of issues:

edbg was hacking around the usual $(FLASHER) $(FFLAGS) pattern, so a new edbg.sh script is added, similar to jlink/openocd (but way simpler)
the native board was setting true to the FLASHER var but it's useless since an empty value can do the same job and is simpler to handle by the programmer.py wrapper tool
I also noticed that the riotboot/flash% targets are not taking into account the PROGRAMMER variable. This seems like a bug: if one wants to flash using openocd tests/riotboot on a samr21-xpro, edbg is always use to flash riotboot while openocd is used to flash the slot. a36748b fixes this problem. I can open a separate PR if you think it's worth.

fjmolinas · 2021-02-18T11:24:18Z

Looks nice, i'll take a look when I can, but can you split out 4b98bd2 & 6cf7fd8, c98e614, a36748b. Those will be easier to test independently.

kaspar030 · 2021-02-18T11:40:23Z

really? all those extra lines to get a spinning icon?

aabadie · 2021-02-18T12:59:11Z

all those extra lines to get a spinning icon?

Not really. The goal is to keep a way to also print the programmer output as before (using PROGRAMMER_QUIET=0). For the spinning icon, the Python script (and subprocess) makes this easy to implement and read.
The general result is IMHO more user friendly (especially with JLink).
The other changes are either fixing inconsistencies or bugs.

miri64 · 2021-02-19T14:17:57Z

Could this potentially make IDE integration harder (or alternatively easier)?

aabadie · 2021-02-19T14:38:07Z

Could this potentially make IDE integration harder (or alternatively easier)?

Do you have an example of IDE integration ? The only problem I could see is the ascii escape codes used for colors, the carriage return and line clear. But I guess modern terminals should handle that.
From a functional point of view, the new python script is called directly by make and internally it calls the flasher command in background using the subprocess module, so nothing special or not portable I would say.

miri64 · 2021-02-19T14:54:59Z

Do you have an example of IDE integration ?

Something like a GUI progress bar based on parsed terminal output e.g. (I'm thinking for instance of the Ubuntu update manager which does something like that).

miri64 · 2021-02-19T14:56:19Z

From a functional point of view, the new python script is called directly by make and internally it calls the flasher command in background using the subprocess module, so nothing special or not portable I would say.

I guess this could actually make the integration easier, since one could hook into that.

aabadie · 2021-02-19T15:09:04Z

Something like a GUI progress bar based on parsed terminal output

In theory, it's possible to redirect the stdout/stderr of subprocess to anything. For the progress bar, the "progress" makes little sense since we don't have any information about the underlying flash progression. We could estimate it based on the firmware size/programmer but I don't think that's worth. Here the spinning icon make more sense IMHO: it's simpler and shows activity.

miri64 · 2021-02-19T15:25:58Z

In theory, it's possible to redirect the stdout/stderr of subprocess to anything. For the progress bar, the "progress" makes little sense since we don't have any information about the underlying flash progression. We could estimate it based on the firmware size/programmer but I don't think that's worth. Here the spinning icon make more sense IMHO: it's simpler and shows activity.

I would count the usual "Cylon visor" for such a case also as a "progress" bar ;-)

aabadie · 2021-02-19T16:59:05Z

I prefer the Knight Rider (K2000 in France ;)) style :)

aabadie · 2021-02-25T12:00:32Z

Squashed!

fjmolinas

ACK on my side but would like some more voices.

kaspar030 · 2021-02-25T12:21:58Z

If we change "programmer" with e.g., "other-kind-of-tool" and fixup the help messages, this would be a generic "run tool and show spinner instead of output unless an error occurs", right?

aabadie · 2021-02-25T16:44:58Z

If we change "programmer" with e.g., "other-kind-of-tool"

Are you sure "other-kind-of-tool" (or maybe "run-tool-and-show-spinner-instead-of-output-unless-an-error-occurs") would be a good name ?
As its name suggest, it's used to wrap some programmer action calls, another action that could be wrapped is the preflashe (already did that locally) and maybe the preflash delay. They are still related to the programmer being used (like bossa or nrfutil).

In the build/flash/reset/term usual process, I don't see where the spinning icon could be helpful other than with flash and reset. The build output as it is now is small enough while giving useful information, so it don't really need to be wrapped like the programmer. term is interactive.

The pattern $(program) $(flags) is used by the preflash, flash%, reset, term, debug% and emulate targets. This pattern is the base of the wrapper tool. Only preflash, flash% and reset targets are non interactive calls, where the wrapper tool fits exactly.

Do you have another tool in mind where this spinning icon would be worth ?

benpicco

I say we can still change the name later if we add more use cases for this.
Now it would just be confusing.

kaspar030 · 2021-02-25T20:39:40Z

Are you sure "other-kind-of-tool" (or maybe "run-tool-and-show-spinner-instead-of-output-unless-an-error-occurs") would be a good name ?

What I meant is that having a tool that runs a command, printing a spinner and only outputs on error code (or stderr), could be re-used. "other-kind-of-tool" was just to point out that with changed text and name, programmer.py would be that generic tool.
I'm fine with merging as is.

kaspar030 · 2021-02-25T20:41:25Z

Do you have another tool in mind where this spinning icon would be worth ?

wget, git, git-cache, anything that takes time. With the current build system, "make info-boards-supported" with the spinner printed to stderr, so users know something is happening.

janosbrodbeck · 2021-02-28T18:33:21Z

This PR introduced one problem for me: flashing with having multiple boards of the same type attached (in my case two particle-xenon boards). Before this PR the flash process always asked me which device I want to flash:

Now I have just a spinning icon waiting endlessly.
When I terminate the process the old query menu also appears, but then the process is already failed:

The menu is way more convenient than specifying the adapter id.

aabadie · 2021-02-28T20:50:38Z

The menu is way more convenient than specifying the adapter id.

You can disable the spinning icon by adding PROGRAMMER_QUIET=0 to the command line. I know it's not perfect but pyocd is the only programmer with this behavior and it will be hard to print the menu automatically (unless we revert that PR).
I checked the pyocd code and this menu cannot be disabled when several boards are found (and maybe take the first one found, there's something for that in the pyocd code but no cli option...). That would require to PR that upstream.

janosbrodbeck · 2021-02-28T20:58:29Z

But why even change the behavior then? Is it really worth to have a spinning icon then? It looks nice, yes...but IMHO I would really prefer the old way when there is no way to provide this menu. It feels a bit like a regression.

aabadie · 2021-02-28T21:17:26Z

If you don't want the spinning icon, you can add PROGRAMMER_QUIET=0 to the command line and you'll have the menu (it works, I just tried it).

I would really prefer the old way when there is no way to provide this menu. It feels a bit like a regression.

I agree that for this particular case, an interactive menu printed when multiple boards are connected, there is a regression. From There's no easy way to determine automatically that multiple boards (recognized by pyocd) are connected, this is really a pyocd thing. Your problem could be fixed by simply disabling the spinning icon when pyocd is used.

benpicco · 2021-02-28T21:36:43Z

If you don't want the spinning icon, you can add PROGRAMMER_QUIET=0 to the command line and you'll have the menu (it works, I just tried it).

But that requires the user to know about this option. Currently the help text

(for full programmer output add PROGRAMMER_QUIET=0 or QUIET=0 to the make command line)

is only printed if the flashing was successful. If programming fails due to the new option, the user has no idea how to disable it (or that it could be related to the failure in the first place)

I think we should employ a similar approach as with spell check here: Have the option to revert it quickly if it turns out to be a nuisance.
With spellcheck this turned out not to be the case, here I'm not so sure.

I do like eyecandy, but if it comes at the price of reduced usability, that's a problem.

janosbrodbeck · 2021-02-28T21:52:37Z

But even with this option, I would have to use it every time now. And writing make flash term BOARD=particle-xenon is easier and quicker than make flash term BOARD=particle-xenon PROGRAMMER_QUIET=0. And I'm lazy to be honest. So I would prefer to disable the spinning icon for pyocd as default.

For the eyecandy: Eyecandy is cool, but with pyocd we have now even less information than before. Before, there was a very informative progress bar. Now it's just the spinning icon. In case of my problem the spinning icon was not helpful. The icon was spinning, but it didn't do anything and there was no hint that there was a problem or that the progress got stuck. With a progress bar you would see that it doesn't move.

fjmolinas · 2021-03-02T09:32:07Z

But even with this option, I would have to use it every time now. And writing make flash term BOARD=particle-xenon is easier and quicker than make flash term BOARD=particle-xenon PROGRAMMER_QUIET=0. And I'm lazy to be honest. So I would prefer to disable the spinning icon for pyocd as default.

For the eyecandy: Eyecandy is cool, but with pyocd we have now even less information than before. Before, there was a very informative progress bar. Now it's just the spinning icon. In case of my problem the spinning icon was not helpful. The icon was spinning, but it didn't do anything and there was no hint that there was a problem or that the progress got stuck. With a progress bar you would see that it doesn't move.

I agree that in this case, it is a regression, for now I opened a PR to disable the spinner for pyocd. Unless similar functionality is implemented later on in the wrapper. If more issues pop up later on we can re-examine this feature and this fix.

benpicco · 2021-04-22T12:51:13Z

I want to retroactively withdraw my ACK on this PR.
It was a bad idea, this wrapper just creates unnecessary friction and does nothing but wasting people's time.

aabadie added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: build system Area: Build system Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR labels Feb 9, 2021

aabadie requested a review from fjmolinas February 9, 2021 17:49

aabadie mentioned this pull request Feb 9, 2021

make/emulate: fix bugs when using flash target #15971

Merged

aabadie force-pushed the pr/make/redirect_flash_output branch from f603cb9 to 92ad5b9 Compare February 10, 2021 08:32

fjmolinas reviewed Feb 16, 2021

View reviewed changes

Makefile.include Outdated Show resolved Hide resolved

aabadie added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Feb 16, 2021

aabadie force-pushed the pr/make/redirect_flash_output branch 2 times, most recently from 3a089a8 to 6cf7fd8 Compare February 18, 2021 10:32

aabadie removed the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Feb 18, 2021

aabadie changed the title ~~make: add variables to redirect the flasher output~~ make: print spinning icon while flashing/resetting Feb 18, 2021

aabadie mentioned this pull request Feb 18, 2021

boards/native: set FLASHER as empty #16046

Merged

aabadie added the State: waiting for other PR State: The PR requires another PR to be merged first label Feb 18, 2021

This was referenced Feb 18, 2021

makefiles/boot: use same PROGRAMMER to flash riotboot #16047

Merged

tools/edbg: add and use wrapper shell script #16050

Merged

aabadie force-pushed the pr/make/redirect_flash_output branch from a5380c1 to 3a750a0 Compare February 19, 2021 13:44

aabadie force-pushed the pr/make/redirect_flash_output branch from 3a750a0 to 85075fd Compare February 21, 2021 16:57

aabadie added 5 commits February 25, 2021 12:59

dist/tools: add programmer wrapper script

976eda9

Makefile.include: use programmer wrapper to silent output

c181ba2

makefiles/vars.inc.mk: document PROGRAMMER_QUIET variable

a47bf12

makefiles/boot: map PROGRAMMER_QUIET to riotboot/flash%

af37f5b

dist/iotlab: return ret code within a single call

5a8094e

aabadie force-pushed the pr/make/redirect_flash_output branch from 5e710a6 to 5a8094e Compare February 25, 2021 11:59

fjmolinas approved these changes Feb 25, 2021

View reviewed changes

benpicco approved these changes Feb 25, 2021

View reviewed changes

aabadie removed the Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR label Feb 25, 2021

kaspar030 merged commit 363412c into RIOT-OS:master Feb 25, 2021

aabadie deleted the pr/make/redirect_flash_output branch February 27, 2021 17:40

fjmolinas mentioned this pull request Mar 2, 2021

makefiles/tools/programmer: do not use wrapper with pyocd #16121

Merged

kaspar030 added this to the Release 2021.04 milestone Apr 23, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

make: print spinning icon while flashing/resetting #15970

make: print spinning icon while flashing/resetting #15970

aabadie commented Feb 9, 2021 •

edited

Loading

fjmolinas left a comment

aabadie commented Feb 16, 2021

aabadie commented Feb 18, 2021

fjmolinas commented Feb 18, 2021

kaspar030 commented Feb 18, 2021

aabadie commented Feb 18, 2021 •

edited

Loading

miri64 commented Feb 19, 2021

aabadie commented Feb 19, 2021 •

edited

Loading

miri64 commented Feb 19, 2021 •

edited

Loading

miri64 commented Feb 19, 2021

aabadie commented Feb 19, 2021

miri64 commented Feb 19, 2021

aabadie commented Feb 19, 2021 •

edited

Loading

aabadie commented Feb 25, 2021

fjmolinas left a comment

kaspar030 commented Feb 25, 2021

aabadie commented Feb 25, 2021

benpicco left a comment

kaspar030 commented Feb 25, 2021

kaspar030 commented Feb 25, 2021

janosbrodbeck commented Feb 28, 2021 •

edited

Loading

aabadie commented Feb 28, 2021

janosbrodbeck commented Feb 28, 2021 •

edited

Loading

aabadie commented Feb 28, 2021

benpicco commented Feb 28, 2021

janosbrodbeck commented Feb 28, 2021 •

edited

Loading

fjmolinas commented Mar 2, 2021

benpicco commented Apr 22, 2021

make: print spinning icon while flashing/resetting #15970

make: print spinning icon while flashing/resetting #15970

Conversation

aabadie commented Feb 9, 2021 • edited Loading

Contribution description

Testing procedure

Issues/PRs references

fjmolinas left a comment

Choose a reason for hiding this comment

aabadie commented Feb 16, 2021

aabadie commented Feb 18, 2021

fjmolinas commented Feb 18, 2021

kaspar030 commented Feb 18, 2021

aabadie commented Feb 18, 2021 • edited Loading

miri64 commented Feb 19, 2021

aabadie commented Feb 19, 2021 • edited Loading

miri64 commented Feb 19, 2021 • edited Loading

miri64 commented Feb 19, 2021

aabadie commented Feb 19, 2021

miri64 commented Feb 19, 2021

aabadie commented Feb 19, 2021 • edited Loading

aabadie commented Feb 25, 2021

fjmolinas left a comment

Choose a reason for hiding this comment

kaspar030 commented Feb 25, 2021

aabadie commented Feb 25, 2021

benpicco left a comment

Choose a reason for hiding this comment

kaspar030 commented Feb 25, 2021

kaspar030 commented Feb 25, 2021

janosbrodbeck commented Feb 28, 2021 • edited Loading

aabadie commented Feb 28, 2021

janosbrodbeck commented Feb 28, 2021 • edited Loading

aabadie commented Feb 28, 2021

benpicco commented Feb 28, 2021

janosbrodbeck commented Feb 28, 2021 • edited Loading

fjmolinas commented Mar 2, 2021

benpicco commented Apr 22, 2021

aabadie commented Feb 9, 2021 •

edited

Loading

aabadie commented Feb 18, 2021 •

edited

Loading

aabadie commented Feb 19, 2021 •

edited

Loading

miri64 commented Feb 19, 2021 •

edited

Loading

aabadie commented Feb 19, 2021 •

edited

Loading

janosbrodbeck commented Feb 28, 2021 •

edited

Loading

janosbrodbeck commented Feb 28, 2021 •

edited

Loading

janosbrodbeck commented Feb 28, 2021 •

edited

Loading