nasa / trick

Trick Simulation Environment. Trick provides a common set of simulation capabilities and utilities to build simulations automatically.
Other
25 stars 15 forks source link

trickview byteswapping options #482

Closed excaliburtb closed 6 years ago

excaliburtb commented 6 years ago

With the increase of including more FSW-like models, it would be beneficial to provide some byteswapping capabilities of certain variable types especially integers for display. This could allow one to view messages that are in a different endianness than native.

alexlin0 commented 6 years ago

We do have some byteswap routines. Header found in ${TRICK_HOME}/include/trick/trick_byteswap.h in Trick 17. Source is at ${TRICK_HOME}/trick_source/trick_utils/comm/src/trick_byteswap.c. Would the routines in there help?

double trick_byteswap_double(double input);
float trick_byteswap_float(float input);
long trick_byteswap_long(long input);
int trick_byteswap_int(int input);
short trick_byteswap_short(short input);
excaliburtb commented 6 years ago

I really meant as a TrickView displays option. Byteswapping in code is not terribly difficult but sometimes you want to look at data in a model you can't change easily. Or certain messages are required to be in a certain endianness, so it would be helpful to have the external tools byteswap the variable rather than internally in the software or model. For instance, in TrickCFS, when we look at message IDs, all are in the CCSDS format in big-endian. I can display them in hex and byteswap in my head, but I just thought it would be useful to have an option to have TrickView itself byteswap it for me.

lordmundi commented 6 years ago

yeah, that would be super useful. maybe you click to bring up a separate window the lets you byteswap, or just mask off certain bits that you want to display if it is packed.

FG

On Fri, Sep 29, 2017 at 1:49 PM, Thomas Brain notifications@github.com wrote:

I really meant as a TrickView displays option. Byteswapping in code is not terribly difficult but sometimes you want to look at data in a model you can't change easily. Or certain messages are required to be in a certain endianness, so it would be helpful to have the external tools byteswap the variable rather than internally in the software or model. For instance, in TrickCFS, when we look at message IDs, all are in the CCSDS format in big-endian. I can display them in hex and byteswap in my head, but I just thought it would be useful to have an option to have TrickView itself byteswap it for me.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nasa/trick/issues/482#issuecomment-333207949, or mute the thread https://github.com/notifications/unsubscribe-auth/AAWKCtU7e_GLBGrbN8_zh6mWSUGT6-VFks5snTuggaJpZM4Poz0O .

alexlin0 commented 6 years ago

The variable server has a var var_byteswap(bool) routine that can byteswap binary data as it is sent out. 2 problems. TV only uses ASCII data so it can't use this routine. We could extend it to cover ASCII data but the byteswapping applies globally to all data. Everything else would swapped too.

This may be a case where a user created specialized display is better suited to display this data.

excaliburtb commented 6 years ago

Wait, how does the option to display binary, hex and whatever else work? I assumed you were already converting to an integer in java at some point and redisplaying it according to the selection. I guess not if everything is ASCII and never becomes a typed value in memory. But, if you are dealing with an integer value in memory after receiving in ASCII, then that implies you can byteswap it before displaying....

alexlin0 commented 6 years ago

We'll have to get @dbankieris to weigh in. I'm not sure what happens in TV. I do think the ascii is reconverted to an integer, but I don't know if TV reads or cares about the size of the field it is displaying. The size doesn't matter when converting to hex or binary, but would in byteswapping.