serial comm help

[kutkm_ti]

now i'm working on rs232, the main board and the sensor board.

the sensor board will send a 8bit hex (not ascii) to the main board continouly.

but as i know, the getchar function will convert the hex to ascii, can i get the 8 bit hex without ascii format, what i want is int8 format

the format is [8bit hex] [invert of the 8bit hex] [\r]

can somebody help?

[PCM programmer]

[kutkm_ti]

[PCM programmer]

getc() only gets 1 byte. It doesn't get 3 bytes.

Also, there is no 'int24' data type in CCS. You're thinking of CC5X.

However, if you did use a data type larger than a byte (int16 or int32)
to receive a byte from getc(), then it would be placed in the LSB of
the variable.

[kutkm_ti]

oic,

my method is like below, no tested yet


#INT_RDA
void serial_isr()
{
inbuff[i] = getc();

if (inbuff[i])==("\r"){i=0;}// if seem "\r" (last byte) then begin build the array
i++;
if(i==2)
{
i = 0;

int8 first = inbuff[0];
int8 second = inbuff[1];

}
}



the check the checksum:
if (~first == second);//then the value is correct

hence my int8 will be "first" right?

sorry for stupid quation

[PCM programmer]

Tell us your overall purpose. What device is sending characters to the PIC ?

[kutkm_ti]

the sensor is ultrasonic sencor, to detect distance
the sensor will output [8bit hex][invert of the8 bit hex][\r]

8 bit hex is from 0-255 based on distance (from x cm to x meter).


we dont use ascii is to save total word that need to sent.

[8bit hex] and [invert of the8 bit hex] will be used to calculate checksum.

then the main board will get the sensor data via rs232 link,


tq very much

[Douglas Kennedy]

8 bit hex will represent 2 digits of base 16. Assuming the Most significant digit is first then the 8 bits has MS*16+LS as its binary value 0..255. This is exactly the distance value you want. However the Least significant hex digit could be sent first so the binary value would be LS*16+MS not the value you want so if this is the case use swap(x) to exchange the LS and the MS nibbles.
Now a further winkle could be that the hex digits are themselves sent least significant bit first Ex the hex digit "3" could be received as 1100. To fix this you can use a 4 bit LIFO shift register to reverse the order.

[kutkm_ti]

[Ttelmah]

[Guest]

actually what the sensor sent is 8 bit binary, not ascii

0b11111111 ,8bit

sorry for bad english,

[Douglas Kennedy]

You are confused as to the differences between the terms binary and hex.
First a number has its own intrinsic value. For us to manipulate numbers we have invented notation...ways to express a numbers value in writing or inside a PIC. The symbols 0..9 are used to notate numbers in base ten the symbols 0,1 in binary and 0...F in hexadecimal. So the number ten exists in our universe and we may choose to write "10" to represent it or "A" or "1010". Now inside a PIC arithmetic is efficient in binary so it becomes the preferred notation. However in sending values for display to humans another code ASCII is used since it covers the numbers and letters on a typical keyboard.
In that case binary notation within the PIC may be further encoded in ASCII
so we might encode ten as "10" two ASCII chars or "A" one char depending if we want a base ten display or a base16(hex) display. Now numbers that are not to be human readable can be sent in any consistent format. Take Binary Coded Decimal BCD it stores a decimal digit in one nibble and the other in the next nibble so ten would be 00010000 or binary coded hex could store the number twenty-six or 1A hex as 00011010 the last number could be inverted and sent as 11100101..any format known to the sender and the receiver can represent a numbers value. Again since the PIC can manipulate binary notation within its hardware ( in this case the zeroes and ones of our notion are represented by electronic on/off states) it is preferred but the binary notation has limitations. For example the number one tenth that occurs exactly in our universe can't be represented without approximation in binary notation due to finite storage.