Wolfgang Denk wrote:
In message 472F1393.7040306@inaccessnetworks.com you wrote:
Wolfgang Denk wrote:
In message 472752F9.9000307@inaccessnetworks.com you wrote:
The following patch fixes a bug in the slave serial programming mode for the xilinx spartan2 FPGA. A "char val" is declared, but it is used as a signed char. The check for negative value (<0) is always true on arm, or any other platform in which the char is not signed by default. As a result the FPGA cannot be programmed.
I have to admit that I hate to see "signed char" in the code. Is there any special reaso why "val" has to be a "char" type? Why not making it an "int" ?
Another way to do this safely is to declare it as an "unsigned char" and instead of doing "val < 0", do "val & 0x80". I don't like the current code either. Shifting a signed char and testing for negativity is definitely not the best way to test that the MSB is set.
So let me repeat my question: is there any special reason why "val" has to be a "char" type? Why not making it an "int" ?
Because you will run into endianness problems. You want to treat an "unsigned char" buffer as a bitstream, reading the MSB every time. How are you going to do this portably (in both big and little endian architectures) with an "int" type, which is at least 2 bytes wide?
-- Angelos Manousaridis