I'm not sure I fully understand, but it sounds like you have a parser for this binary format, and you control the code for it. So this answer is built on that assumption.
A parser will in some way be filling up structs, classes, or whatever data structure your language has. If you implement a
ToString for everything that gets parsed, then you end up with a very easy to use and easily maintained method of displaying that binary data in a human readable format.
You would essentially have:
byte arrayOfBytes; // initialized somehow
Object obj = Parser.parse(arrayOfBytes);
And that's it, from the standpoint of using it. Of course this requires you implement/override the
ToString function for your
Object class/struct/whatever, and you would also have to do so for any nested classes/structs/whatevers.
You can additionally use a conditional statement to prevent the
ToString function from being called in release code so that you don't waste time on something that won't be logged outside of debug mode.
ToString might look like this:
return String.Format("%d,%d,%d,%d", int32var, int16var, int8var, int32var2);
return String.Format("%s:%d,%s:%d,%s:%d,%s:%d", varName1, int32var, varName2, int16var, varName3, int8var, varName4, int32var2);
Your original question makes it sound like you've somewhat attempted to do this, and that you think this method is burdensome, but you have also at some point implemented parsing a binary format and created variables to store that data. So all you have to do is print those existing variables at the appropriate level of abstraction (the class/struct the variable is in).
This is something you should only have to do once, and you can do it while building the parser. And it will only change when the binary format changes (which will already prompt a change to your parser anyways).
In a similar vein: some languages have robust features for turning classes into XML or JSON. C# is particularly good at this. You don't have to give up your binary format, you just do the XML or JSON in a debug logging statement and leave your release code alone.
I'd personally recommend not going the hex dump route, because it's prone to errors (did you start on the right byte, are you sure when you're reading left to right that you're "seeing" the correct endianness, etc).
Example: Say your
ToStrings spit out variables
a,b,c,d,e,f,g,h. You run your program and notice a bug with
g, but the problem really started with
c (but you're debugging, so you haven't figured that out yet). If you know the input values (and you should) you'll instantly see that
c is where problems start.
Compared to a hex dump that just tells you
338E 8455 0000 FF76 0000 E444 ....; if your fields are varying size, where does
c begin and what's the value - a hex editor will tell you but my point is this is error prone and time consuming. Not only that, but you can't easily/quickly automate a test via a hex viewer. Printing out a string after parsing the data will tell you exactly what your program is 'thinking', and will be one step along the path of automated testing.