Programming a GSM device

Probably not everything is an unsigned char, but many things should be.

It has to do with the C programming language.

If you want a value to ALWAYS be in the range 0 to 255 (which is the range of an 8-bit value. 2-to-the-power-of-8(minus 1) = 255) the proper variable type is "unsigned char"

lots of microprocessors have 8-bit registers, so you see lots of unsigned char data types in embedded-systems programs.

Again, it's so that the data has values only in the range 0 to 0xFF (0xff is the C language syntax for a hexadecimal value of FF which is a decimal value of 255. People use 0xFF instead of 255 so that the reader is aware that it's most likely an 8-bit field.)

The checksum routine could have been written to accept only unsigned char data types, and the "& 0xFF" would be unnecessary since the data would always be in the correct range.

Did that help a little?

Thanks heaps Alan :) I have one problem though, for which you might have an answer:

My problem is that I need to send hex values to an embedded device to get a response back. The manual says that sending '0x00' should return

I send 0x99 to the device to switch it to "listening mode". This works.. I simple do:

char msg[2];

msg[0] = 0x99; SendToDevice(uart, msg, 1);

where uart is a pointer to the device, msg is the char array that it takes in and 1 is the number of characters to read from the array. This works fine, that is, it activates the device.

This returns the correct result. I then send it two values, say:

msg[0] = 0x45; msg[1] = 0x32; SendToDevice(uart, msg, 2);

This works as well, I get the correct checksum in return. But then I need to "initiliaze" the device by sending it 0x00 and it's supposed to return 0x66 which isn't working.. I'm doing:

msg[0] = 0x00; SendToDevice(uart, msg, 1);

And I get -91 in return. Maybe it's something that I'm doing wrong with my conversion but it seems to work fine for the first two cases but fails with 0x00, or maybe the manual is wrong.. I don't know. Here's what I do to receive the returned value and conver it:

char *buf = malloc(sizeof(char)*64);

GetValueFromDevice(uart, buf);

int val = (int) buf[0]; // buf[0] holds the character we need char *temp = malloc(sizeof(char)*64);

temp = itoa(val, temp, 1); // convert the integer into a string

PrintReturnedValue(temp);

This works for the first two cases but fails (i.e. I keep getting -91 in decimal, which should in fact be 0x65 or whatever 0x65 is in decimal)

Thanks for taking time out for this Alan,

Cheers

S> >

Someone is taking the returned value of 0x65 and sign-extending it when it gets converted to an integer which results in a -91.

So, it looks like your hardware is really return>char *buf = malloc(sizeof(char)*64);

Make this unsigned chr *buf...

How about unsigned int val = (unsigned int) buf[0];

I've done some testing on Sun/sparc Solaris, and your original code works for me so I think it's something in your compiler.

Try the suggested sprinkling of "unsigned" in the above code and get back to us.

The good thing is that it looks like your hardware is returning 0x65.

sizeof(char) is always guaranteed to be 1

This should be: itoa(val, temp, 10); or itoa(val, temp, 16) if you want the result in hexadecimal. The third argument is the radix for the ASCII representation.

If your platform has printf(), this would be better: printf("Returned value = 0x%2.2x\n", *buf); You wouldn't need 'val' or 'temp' at all. It could go immediately after the GetValueFromDevice() call.

That's true, but be careful....

I used a Texas Insturments TMS320C32 where of course sizeof(char) was 1, but a char was 4 bytes long!!!

sizeof(int) was also 1

It's because sizeof() returns the size of the object in multiples of the size of a char, and if a char is 4-bytes, then an int can also be

Nothing to do with this example, but interesting nonetheless.