sys: Initial import of analytical object dump (od) module

[miri64]

I was fed up to always rewrite object dumps.This introduces a module for this. Might also be useful to analyse output in wireshark

[OlegHahm]

I have no clue how this should be used. Can you provide a README?

[miri64]

Isn't that what the doxygen documentation is for? Where it is unclear? The idea is to use it mainly for debug (and if we have something like a fs in the future to dump files in binary form). Just call

od(&var, sizeof(var), 0, 0);
/* or */
od_dump_hex(&var, sizeof(var), 0);

from whereever you need a quick overview of the bits'n'bytes in var

[miri64]

This was motivated mainly to find the errors in the Neighbor Discovery more easily

[miri64]

Also it's inspired by od(1), but in function form and not as command-line tool.

[OlegHahm]

Doxygen says Dumps *data* to stdout (which can be basically said about every print function) and referring to a tool that talks about files.

So, it's printing a piece of memory in a octal representation?

[miri64]

*data* refers to the variable, but okay I'll rework the doc a little bit more clearly tomorrow now.

So, it's printing a piece of memory in a octal representation?

Octal, decimal, hexadecimal, what ever you like ;-)

[miri64]

better?

[OlegHahm]

👍

[OlegHahm]

(That's not an ACK yet.)

[miri64]

(Did not take it for that) ;-)

[miri64]

@N8Fear please comment in the PR's file changes, not the commits.

[OlegHahm]

    char foo[128];
    od_hex_dump((void*) &foo, 128, 0); 

    foo[5] = 44; 
    od_hex_dump((void*) &foo, 128, 0);

on native:

000000 0000000000000000 0000000000000000 0000000000000000
000003 0000000000000000 0000000000000000 0000000000000000
000006 0000000000000000 0000000000000000 0000000000000000
000009 0000000000000000 0000000000000000 0000000000000000
00000c 0000000000000000 0000000000000000 0000000000000000
00000f 0000000000000000
000000 00002c0000000000 0000000000000000 0000000000000000
000003 0000000000000000 0000000000000000 0000000000000000
000006 0000000000000000 0000000000000000 0000000000000000
000009 0000000000000000 0000000000000000 0000000000000000
00000c 0000000000000000 0000000000000000 0000000000000000
00000f 0000000000000000

Looks okay.

On IoT-Lab_M3:

000000 000000000000000lx 000000000000000lx 000000000000000lx
000003 000000000000000lx 000000000000000lx 000000000000000lx
000006 000000000000000lx 000000000000000lx 000000000000000lx
000009 000000000000000lx 000000000000000lx 000000000000000lx
00000c 000000000000000lx 000000000000000lx 000000000000000lx
00000f 000000000000000lx
000000 000000000000000lx 000000000000000lx 000000000000000lx
000003 000000000000000lx 000000000000000lx 000000000000000lx
000006 000000000000000lx 000000000000000lx 000000000000000lx
000009 000000000000000lx 000000000000000lx 000000000000000lx
00000c 000000000000000lx 000000000000000lx 000000000000000lx
00000f 000000000000000lx

Broken formatter?

[miri64]

This looks a little bit mind-bending to me right now. Will look into it (this time for real) tomorrow.

[miri64]

printf for 64-bit numbers seems to be broken on iot-lab_M3. See #1891

[OlegHahm]

ACK

[LudwigKnuepfer]

file does not have a C++ compatible header: 'sys/include/od.h'

[miri64]

öhm, how do I make this?

[LudwigKnuepfer]

git grep extern core

[OlegHahm]

git grep cplusplus

[miri64]

got it

[LudwigKnuepfer]

@authmillenon got it ;)

[miri64]

@OlegHahm re-ACK?

[OlegHahm]

Yes, squash and go