Serial binary write byte order scrambled?

[bodger]

I was writing some code to transfer binary numbers over a serial port and it kept getting out of synch. I kept simplifying the code until it was about as trivial as it can be (sends 0x11, 0x22, 0x33 repeatedly, with a delay). The output is still out of order. Here's the code:

#define SERIALPORT  Serial

void
setup()
{
  SERIALPORT.begin(9600);
}

void
loop()
{
    SERIALPORT.write((byte) 0x11);
    SERIALPORT.write((byte) 0x22);
    SERIALPORT.write((byte) 0x33);
    //SERIALPORT.write((byte) 0x44);
    delay(100);
}

Here's a hex dump of what I receive:

0000000      2211    1133    3322    2211    1133    3322    2211    1133
0000020      3322    2211    1133    3322    2211    1133    3322    2211
0000040      1133    3322    2211    1133    3322    2211    1133    3322

This is with a Teensy 3.2 using the USB serial port. I don't think I'm overflowing any buffers, I'm not overclocking, and I don't think the compiler is reordering the code (I've tried it with both 72MHz optimize speed and 72MHz reduce code size). If I uncomment the line to send 0x44, I get this:

0000000      2211    4433    2211    4433    2211    4433    2211    4433

My original application sent 0xff synch bytes, along with 4-byte floating point values. I'd get the synch bytes scattered throughout my data, not every 5th byte as expected.

 

[PaulStoffregen]

What program are you using on your computer to create the hex dump?

Maybe the data is actually correct, but this hex dump is swapping the bytes?

 

[bodger]

I'm just running "od -x" from the serial port (on MacOS X):

Yes, master? ls /dev/cu*
/dev/cu.Bluetooth-Incoming-Port		/dev/cu.usbmodem1944121
Yes, master? od -x /dev/cu.usbmodem1944121
0000000      2211    1133    3322    2211    1133    3322    2211    1133
0000020      3322    2211    1133    3322    2211    1133    3322    2211
0000040      1133    3322    2211    1133    3322    2211    1133    3322
0000060      2211    1133    3322    2211    1133    3322    2211    1133
0000100      3322    2211    1133    3322    2211    1133    3322    2211
0000120      1133    3322    2211    1133    3322    2211    1133    3322
0000140      2211    1133    3322    2211    1133    3322    2211    1133
0000160      3322    2211    1133    3322    2211    1133    3322    2211
0000200      1133    3322    2211    1133    3322    2211    1133    3322
0000220      2211    1133    3322    2211    1133    3322    2211    1133
0000240      3322    2211    1133    3322    2211    1133    3322    2211

I wouldn't expect it to change the byte order at all, let alone cause bytes to be doubled.

 

[KurtE]

It is doing what I would expect. I believe the command: of -x
is assuming 16 bit values are coming in and it is assuming it is coming in LSB, MSB order.
So you output: 0x11 0x22 0x33 0x11 0x22 0x33 0x11 ox22, 0x33...
So it gets the 11 as the lsb, and 0x22 for msb: and outputs 2211
it then gets the 33 as lsb ox11 as msb: 1133
then: 22 lsb 33 as msb: 3322
...
Yes you have a delay of a 10th of a second after you output each of these 3 bytes, but the system both on Teensy and MAC just buffer these up and or wait for the next byte...

 

[PaulStoffregen]

I wouldn't expect it to change the byte order at all,

Well you're in for an unpleasant surprise, because that's exactly what "od -x" does.

For example:

paul@mac:/tmp > echo -n "Test" > test.txt
paul@mac:/tmp > od -x test.txt 
0000000      6554    7473                                                
0000004

Notice the first shown is 65 which is "e", then comes 54 which is "T", and of course "t" and "s" follow.

Instead, use "od -t x1".

paul@mac:/tmp > od -t x1 test.txt 
0000000    54  65  73  74                                                
0000004

 

[PaulStoffregen]

Of course, the bytes aren't actually getting doubled. It just looks that way when you have a pattern length of 3 and you swap every pair.