Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 6 of 6

Thread: Serial binary write byte order scrambled?

  1. #1
    Junior Member bodger's Avatar
    Join Date
    Jan 2017
    Location
    Baltimore/Washington area
    Posts
    2

    Serial binary write byte order scrambled?

    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:

    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:

    Code:
    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:

    Code:
    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.

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    13,324
    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?

  3. #3
    Junior Member bodger's Avatar
    Join Date
    Jan 2017
    Location
    Baltimore/Washington area
    Posts
    2
    I'm just running "od -x" from the serial port (on MacOS X):

    Code:
    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.

  4. #4
    Senior Member KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    1,977
    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...

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    13,324
    Quote Originally Posted by bodger View Post
    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:

    Code:
    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".

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

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    13,324
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •