I'm getting unexpected results and suspect that there is some sort of typecast issue: I'm sending data to a slave SPI chip that is running my LCD. I'd like to be able to send 16 bit values, so I'm sending high and low bytes. It works just fine when I send an explicit value like -1111 in code below. When I test the scheme with an assigned program variable jx (joystick input that goes from -100 to + 100) it displays like an unsigned 8 bit number, and wraps to 255 vice a negative when less than zero. jx is declared as a signed 16 bit variable. Also, if instead of letting jx be assigned its value by the joystick input, if I explicitly assign it a negative value, this also displays properly as a negative number. Any thoughts as to what may be causing this discrepancy appreciated.

        //jx=-50; when jx explicitly assigned like this, it works OK too
        //when jx left as assigned elsewhere in code as:  
        //jx=(int16_t)spi_data_in[4];// it doesn't work

        small_steer = jx;

        //small_steer = (uint16_t)-1111;// this works too

        small_steer_hb = small_steer>>8;
        small_steer_lb=(small_steer&0xFF);

        //Send data to DISPLAY  
        spi_write(3,0X03,small_steer_hb);//high byte);
        spi_write(3,0X05, small_steer_lb);

Also, when I send jx as a single byte it displays negatives properly and shows that I'm in fact getting a range from -100 to 100 on that variable.

jx=(int16_t)((int8_t)spi_data_in[4]);

might work.

Noter,

It worked!!! Could you explain why adding the int8_t in addition to the int16_t makes a difference?

Eric

Because conversion of uchar (unsigned 8 bit) to char (signed 8 bit) preserves the sign bit but conversion of uchar to int, long, etc. zero fills. So to preserve the sign convert to signed 8 bit first then to whatever. In the example the conversion to int16 will be implicit if you leave out the (int16_t) cast but the (int8_t) must be there.

Noter,

Thank you much for the info - I spent quite a bit of time troubleshooting this one to no avail until getting your help.

Eric

Glad I could help out.

Another way to think about it is that an unsigned integer has no sign bit which implies a positive integer. So when you copy it to a larger format signed integer the compiler simply pads with binary zeros to make it fit and keep it positive. However if the unsigned and signed are the same size there is no padding and the high order bit becomes the sign bit. It's different when a signed integer is copied to a larger signed integer, the sign bit is considered and preserved in the conversion.