I am working with the CAN API library and I need to send negative data but the negative data converts them to positive. How can I send negative bytes?.
For example I send a byte -1 and the program converts it to 255
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sign is just an interpretation of the binary data. Usually, the sign is the most significant bit in your data.
in your case, using a byte, means 8 bits of data. Max unsigned range is 0~255. But if you interpret it as signed then range is -128~127.
so it is just a different method in evaluating the value that causes your problem.
so your solution may be in correcting how you evaluate it.
Why do you need to send some negative values ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
dFx hat geschrieben:
sign is just an interpretation of the binary data. Usually, the sign is the most significant bit in your data.
in your case, using a byte, means 8 bits of data. Max unsigned range is 0~255. But if you interpret it as signed then range is -128~127.
so it is just a different method in evaluating the value that causes your problem.
so your solution may be in correcting how you evaluate it.
Why do you need to send some negative values ?
I need to send messages that contain joint angle values, therefore it is necessary to send some negative angles. I have tried changing the variable to SINT, but it does not recognize the sign.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sending byte value 255 is correct if you want to send -1.
What is your receiving device? Your receiving device needs to interpret 0xFF as -1.
Is it even expecting an 8 bit value? If it's expecting more, you might need 0xFF.
The best we to display the same bits as different interpretations is with a DUT UNION.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I-Campbell hat geschrieben:
Sending byte value 255 is correct if you want to send -1.
What is your receiving device? Your receiving device needs to interpret 0xFF as -1.
Is it even expecting an 8 bit value? If it's expecting more, you might need 0xFF.
The best we to display the same bits as different interpretations is with a DUT UNION.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is not clear to me. that the value 255 in byte is interpreted as -1 (negative value) in my controller? Use a raspberry as a controlling device
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2019-10-31
Originally created by: scott_cunningham
computers represent numbers as bits. As such, negative numbers do not really exist. Instead, both the sender and the receiver agree to use a bit to signal that the number should be treated as a negative value. It is possible to send a negative value even with the data type as byte. For example, in modbus, dats is sent as WORDS (0..65535). But if both sides agree that WORD 2 should be a negative, then you can send a number from -32768 to 32767. It is even possible to have both sides agree that two WORDS in a row can be a REAL number.
So in your problem, it seems to me that your receiver does not expect a negative value. Or as mentioned before, maybe the receiver is expecting 16 bits as a negative. If that is the case, then -1 has to be sent as 0xFFFF (not 0xFF - because 0xFF is actually 0x00FF, a positive number). Check your documentation on the receiver of your data.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am working with the CAN API library and I need to send negative data but the negative data converts them to positive. How can I send negative bytes?.
For example I send a byte -1 and the program converts it to 255
sign is just an interpretation of the binary data. Usually, the sign is the most significant bit in your data.
in your case, using a byte, means 8 bits of data. Max unsigned range is 0~255. But if you interpret it as signed then range is -128~127.
so it is just a different method in evaluating the value that causes your problem.
so your solution may be in correcting how you evaluate it.
Why do you need to send some negative values ?
I need to send messages that contain joint angle values, therefore it is necessary to send some negative angles. I have tried changing the variable to SINT, but it does not recognize the sign.
Sending byte value 255 is correct if you want to send -1.
What is your receiving device? Your receiving device needs to interpret 0xFF as -1.
Is it even expecting an 8 bit value? If it's expecting more, you might need 0xFF.
The best we to display the same bits as different interpretations is with a DUT UNION.
It is not clear to me. that the value 255 in byte is interpreted as -1 (negative value) in my controller? Use a raspberry as a controlling device
Originally created by: scott_cunningham
computers represent numbers as bits. As such, negative numbers do not really exist. Instead, both the sender and the receiver agree to use a bit to signal that the number should be treated as a negative value. It is possible to send a negative value even with the data type as byte. For example, in modbus, dats is sent as WORDS (0..65535). But if both sides agree that WORD 2 should be a negative, then you can send a number from -32768 to 32767. It is even possible to have both sides agree that two WORDS in a row can be a REAL number.
So in your problem, it seems to me that your receiver does not expect a negative value. Or as mentioned before, maybe the receiver is expecting 16 bits as a negative. If that is the case, then -1 has to be sent as 0xFFFF (not 0xFF - because 0xFF is actually 0x00FF, a positive number). Check your documentation on the receiver of your data.
btw, sending a joint angle value coded on a byte seems very low resolution …
Check your doc about wrong type (byte int or dint) as noted by scott