Updated to full json output as per conversation with @kaspar030 since it will work better with murdock metrics

Updated tests/bench_msg_pingpong to use turo

2020-10-16 11:58:53,897 # START
2020-10-16 11:58:53,904 # main(): This is RIOT! (Version: 2020.10-devel-1992-gc7e3a-pr/testhelpers)
2020-10-16 11:58:54,906 # {"data": {"n":100397}}
2020-10-16 11:58:54,908 # {"data": {"ticks":717}}
2020-10-16 11:58:54,908 # {"data": {"ticks":746}}
2020-10-16 11:58:54,910 # {"result": "Success"}

Updated tests/periph_cpuid

2020-10-16 11:48:47,764 # START
2020-10-16 11:48:47,771 # main(): This is RIOT! (Version: 2020.10-devel-1992-g7668-pr/testhelpers)
2020-10-16 11:48:47,773 # Test for the CPUID driver
2020-10-16 11:48:47,778 # This test is reading out the CPUID of the platforms CPU
2020-10-16 11:48:47,778 # 
2020-10-16 11:48:47,779 # CPUID_LEN: 12
2020-10-16 11:48:47,784 # {"data": [48,255,108,6,78,84,52,56,17,40,16,67]}
2020-10-16 11:48:47,786 # {"result": "Success"}

I will run murdock to test metrics

This does seem to increase build size... I thought I could make some gains by using the fmt library... Darn.

2020-10-16 11:58:54,906 # {"data": {"n":100397}}
2020-10-16 11:58:54,908 # {"data": {"ticks":717}}

why not just {"n":100397}?

I wanted to somehow namespace data.

This does seem to increase build size... I thought I could make some gains by using the fmt library... Darn.

yeah, all stdio code is still used (just by "Hello, this is RIOT!")...

yeah, all stdio code is still used (just by "Hello, this is RIOT!")...

gross, oh well, that is optimization (probably also used in the interactive sync).

yeah, all stdio code is still used (just by "Hello, this is RIOT!")...

I guess #13710 will help with that!

@fjmolinas & @kaspar030
if someone has time I would like this (or similar functionality) to move forward.

@kaspar030 ping,

There is an issues with this:
The tests written with this will look less and less like examples due to using this module instead of printf...

If we say the convenience of this is work that (and you should be able to replace these with just a printf) then we can move forward and even make a riotctrl parse that can interpret this.

After talking with @leandrolanzieri and @jia200x it seems that we think the best way is to have a way to open a result container chronologically print the data from the results and close it (ideally with an exit status similar to linux).
We can always do helper functions that takes care of the opening and closing so for simple tasks it won't be a burden.

Structure can be enforced with the CI for example, every command would have an exit status.

Adding a generic parser to riotctrl should be easy.

The one thing that wasn't agreed on is to allow unformatted data from DEBUG prints or generally from a printf as part of the output, the parser could somehow ignore that.

I will survey some serializer APIs to see what would be needed and provide something a bit more complete, and maybe a test that can show the capabilities a bit better.

closed with #15950