I need to check the docs/code to see if there's any mandatory formatting/marshalling involved or if you have full control by just setting a property string with bytes/words or bits.
I don't have any hardware to test this, and I would need to set up a RS232 simulator of some form, or maybe send stuff back to FG via some kind of loopback setup, so you are probably in a better position to actually test this.
the generic protocol docs are actually fairly simple - you can also check $FG_ROOT/Docs for more compact examples.
The sprintf-style formatting stuff isn't required, and I don't think that those line/field (chunk) separators are required. So most things should be optional.
Once you omit stuff, you should just see the plain value (even if you're not using properties/Nasal)
To send a hex value from a property, you would just use setprop(property, 0xFF) and then reference the property in your XML file
I don't know if you have 100% flexibility for each message/byte here, but it is possible that there's some implied restriction here due to the way the generic protocol internally works.
But even if that should be the case, that should require fairly minor changes to the code.
And first of all, I would try to send some simple messages and analyse those according to the wiki article, to see if the format makes sense or if there's any "padding" or other stuff added that breaks the whole thing for you. Forget about properties and Nasal for now - just come up with a static protocol that keeps sending the same 6-byte message and see what it looks like.
For starters, you could post some simple examples - i.e. messages that you'd like to send, and how they're supposed to look (formatting-wise).
We can then check if it's possible to express those with existing generic protocol means, maybe in combination with Nasal.
EDIT: It is true that there's various comments saying that binary mode would not be supported for serial I/O, and that strings would not be supported - I have no way to test this, except for looking at the code.
But as previously mentioned, for fixed-size I/O, you would then simply set up 5-6 "fields" (chunks) each being a single byte/word (depending on your requirements) and then access each part separately by setting its property. Maybe I am missing something here, but that's how I would try to approach this for starters. And then dump the output to some file to see if it makes sense or looks corrupted.
messages with a fixed size of 6 bytes would then be expressed as having 6 chunks (bytes/char, or the equivalent size of ints ), or simply 6x8 boolean properties that you can control (set/clear) individually.
you could probably also use printf-style format strings to extract certain bits/bytes:
https://en.wikipedia.org/wiki/Printf_format_stringSo unless the generic I/O system will internally touch each message and break it for you, most required things should be there AFAIU