Read and send unsigned long data to Arduino. This is a bug?

[josemanbcn]

I need to read and send unsigned long data to arduino, then I use the example for send a audio tone to arduino and with this modification:

    /*********************************************************************************

    ** New function

    *********************************************************************************/

       case 0x2E:  //

        duration=(command[5] + (command[4] << 😎 + (command[3] << 16) + (command[2] << 24)); /* this is original from LIFA firmware*/

        /* Only for test I send the same data to LabView to check*/

        Serial.write( (duration >> 24) );

        Serial.write( (duration >> 16) );

        Serial.write( (duration >> 😎 );

        Serial.write( (duration & 0xFF) );

        break;

(duration is unsigned long;)

If I send the data 1005396 from LabView to Arduino, command[5], command[4], command[3] and command[2] are the correct bytes, in this case 84, 87, 15 and 0. But when I send the same data to LabView I recive only the data 84 and 87, the others 2 bytes are equal to 0, and this is not correct (obviously I modified too the code in LabView to read 4 bytes).

But if in the function I send whit this changes:

        Serial.write( command[5] );

        Serial.write( command[4] );

        Serial.write( command[3 );

        Serial.write( command[2] );

Then, I receive the correct 4 bytes in LabView.

In the next probe I performed this changes in the funcion:

    /*********************************************************************************

    ** New function

    *********************************************************************************/

       case 0x2E:  // Stepper steps to go

        duration=(command[5] + (command[4] << 😎 + (command[3] << 16) + (command[2] << 24));

         /* Only for test I send the same data to LabView to check*/

        byte1 = command[2];

        byte1 = byte1 << 24;

        byte2 = command[3];

        byte2 = byte2 << 16;

        byte3 = command[4];

        byte3 = byte3 << 8;

        byte4 = command[5];

        duration = byte1 + byte2 + byte3 + byte4;

        Serial.write( (duration >> 24) );

        Serial.write( (duration >> 16) );

        Serial.write( (duration >> 😎 );

        Serial.write( (duration & 0xFF) );

        break;

byte1, byte2, byte3 and byte4 are unsigned long.

With this modification the program works OK, but if this modification works, then the original code for tone doesen't read correctly the long dat in the variable duration....

What do you think about this?

Sorry for my English...

Jose

[Nathan_B.]

I don't see anything wrong with what you posted.  Post your VIs and your full LabVIEWInterface.pde/.ino

[josemanbcn]

Nathan_B. escribió:

I don't see anything wrong with what you posted.  Post your VIs and your full LabVIEWInterface.pde/.ino

Hi Nathan,

I attach in this reply the LabVIEWInterface.ino, ande the LabView code is:

Thanks a lot.

Jose

[Nathan_B.]

Mmmm . . . The first thing that I would try is to make the "command" array an unsigned long instead of an unsigned char to see if shifting the bits on a char is shifting bits out of memory.  I say this because in the version that you say works, you are never shifting bits of a char but instead you are always shifting bits of a long.

[josemanbcn]

But Nathan,

In the original code for LabVIEWInterface, for the commando Tone is the same:

    case 0x05:    //Tone         

      freq = ( (command[3]<<8) + command[4]);

      duration=(command[8]+  (command[7]<<8)+ (command[6]<<16)+(command[5]<<24));

If don't work for my command don't work for the command Tone too, not?

Jose

[Nathan_B.]

josemanbcn wrote:

But Nathan,

In the original code for LabVIEWInterface, for the commando Tone is the same:

    case 0x05:    //Tone         

      freq = ( (command[3]<<8) + command[4]);

      duration=(command[8]+  (command[7]<<8)+ (command[6]<<16)+(command[5]<<24));

If don't work for my command don't work for the command Tone too, not?

Jose

You are correct,  I'm just trying to debug it.  I never said my first step was the solution, I just said that is one thing that I would try to rule it out.

[josemanbcn]

Thanks Nathan.

[Nathan_B.]

So, what happened when you tried my suggestion?