Document byte / character-based protocol in byte order using range description

You described a workaround for representing bytes using a wavedrom bitfield in #10.

I would like to document the following byte/character based protocol command structure:

Command structure:
* DT: this specific command uses 0x00

00   01 02 03 04   05 06 07 08   09   10   11   12 13 14 15   16 17   18 19   20 21 22 23   24 25   26   27 28 29 30 31
-----------------------------------------------------------------------------------------------------------------------
                                      |<------------------- CRC16 --------------------->|
15   01 23 45 67   98 76 54 32   80   00   00   65 72 06 B8   00 00   00 00   00 00 00 00   00 00   00   -- -- -- -- --
^^   ^^^^^^^^^^^   ^^^^^^^^^^^   ^^   ^^   ^^   ^^^^^^^^^^^   ^^^^^           ^^^^^^^^^^^   ^^^^^   ^^
ID   TargetAddr#   SourceAddr#   Idx  DT   ?    TimeStamp     Gap             Password      CRC16   CRC8

However the main difficulty here is that the legend of the bytes is ordered ascending, while a common bitfield is ordered from most significant to least significant bits, ie. descending.

Are there options to reverse the order, e.g. bytes 00 .. 31 for a byte based protocol instead of bit 31 .. 00 for bitfields. Side note: for bitfields it also might be interesting to specify big- vs little-endianness for display of a register block ?

I could workaround it by using a wavedrom signal, but I would prefer something like the register view with byte order.

{signal: [
  {name:'Clock',     wave: 'p...........' },
  {name:'Data',      wave: 'x345.6.78.9x', data: '7E 07 00000000 00000000 00 07 7F' },
  {name:'Description', wave: 'x345.6.78.9x', data: 'SOF ID TargetAddr# SourceAddr# 0x00 CRC8 EOF' },
  {name:'Request',   wave: '01.........0' }
],
 head:{
   text:'Messages: DTU to INV: "Init" (0x07)',
   tick:0,
   every:2
 },
 foot:{
   text:'Messages 0x07',
   tock:9
 },
}

Vertical flip vflip changes the order of bits inside the lane.

{reg: [
    {bits: 1,  name: 'MID',    attr: '0x07', type: 2},
    {bits: 4,  name: 'TargetAddr#',        attr: '0x12 34 56 78', type: 4},
    {bits: 4,  name: 'SourceAddr#',     attr: '0x98 76 54 32', type: 6},
    {bits: 1,  name: 'Idx',       attr: '0x80', type: 5},
    {bits: 1,  name: 'DT',       attr: '0x00', type: 2},
    {bits: 1,  name: '??',       attr: '0x00', type: 3},
    {bits: 4,  name: 'TimeStamp',       attr: '0x65 72 06 B8', type: 3},
    {bits: 2,  name: 'Gap',       attr: '0x00 00', type: 3},
    {bits: 2,  name: '',       attr: '0x00 00', type: 3},
    {bits: 4,  name: 'Password',       attr: '0x00 00 00 00', type: 3},
    {bits: 2,  name: 'crc16',       attr: '0xC9 72', type: 1},
    {bits: 1,  name: 'crc8',       attr: '0x07', type: 1},
], config: {vflip: true, hspace: 1400}}

Note: Are the range annotation |<-- CRC16 -->| available in a wavedrom signal: also available in a wavedrom reg: byte / bitfield ?

wavedrom / bitfield

Document byte / character-based protocol in byte order using range description #58