But i'm unsure if this is going as it should be. There is correctly functioning serial listening part for starting symbol and ending symbol. It works for simple cases where i just send one char but not for numbers.

Is this correct way to receive 2 BYTE integer for arduino? seems like it's not... any help would be greatly appreciated!

Corrected that typo, but it didn't fix the problem. Isn't pos1 and pos2 receiving parts of original int from PC by (char) message[2] and [3] ?What you mean by defining my variables as bytes? I'm not very experienced with arduino. You mean it's a problem if i define pos1 and pos2 as ints?

//======================================================================////======================================================================////======================================================================////======================================================================////======================================================================//////// MAIN LOOP////////======================================================================//

Your servo is sent to some position using the Servo::write() method. What physical limits exist for your servo? Typically, a servo is limited to 0 to 180 degrees (or less).

The values that a servo can physically move to, when expressed as integer values can fit in a byte, which can hold a range of values from 0 to 255. Since that is greater than the servo can actually move to, a byte is generally sufficient. And, much easier to send to the Arduino.

I could probably handle servo with one byte, but i also got implementation with stepper motor where i need more values than 255. That case has basically same problem for transferring multiple bytes (4).

Also this exactly same solution works flawlessly with encoder other way around, from arduino to PC, but for some reason not from PC to arduino. Main question is about merging bytes on arduino end. Am I doing it correctly..? If so, then the problem is somewhere else.

This is valid because there is no carry operation performed by the addition, and there should not be a carry operation. It is arguable that the bitwise operation is preferred, because it keeps the entire thing in bit-by-bit logic, instead of allowing for carry operations, which may change surrounding bits.

is 0x3232 or the same as '22' in ASCII - are you missing a conversion stage somewhere?Like subtracting '0'.

Hmm, used hterm to capture this output. But if that's correct, then everything should work? Arduino is getting my short int from PC by two bytes and merging those back to one short int variable called pos? If on arduino I pass this pos value to servo.write(pos) function, servo should move accordingly?Of course in servo case by using values between 0-180.

If on arduino I pass this pos value to servo.write(pos) function, servo should move accordingly?

But if you're pass the servo write a value of 12850, that isn't going to work.

Are you saying you expect the servo to go to position 22 decimal?

Nope, that most recent post was just an test to see does arduino receive correctly what i'm sending and replying it back to me from serial monitor program. If i'm dividing short int = 100 to two bytes, send to arduino. Merge it on arduino to short int pos variable and pass that to servo function everything should work, but it doesn't.. well, i guess got to keep debugging..

EDIT: OK seems like arduino is receiving correctly what is sent to it through Hterm. Problem is most likely on Linux sending function..

I hope you realize that if you send the data in one direction with ASCII and read it as if it were sent in binary, you'll never get the conversions correct. You are sending, in decimal form, two bytes, both of value '50'. 50 << 8 + 50 = 12850, so your code is working as expected. What you NEED to do is figure out how to send in binary instead of ASCII notation - What language is your 'sender' code in? I just realized it's not Processing, and is some variant of C/C++.