Programming a GSM device

Hi,
I've just started learning how to program a GSM device using the etherNUT interface (in C). I was looking at some code examples and I
don't understand why everything needs to be an "unsigned char"? Also, in a certain "checksum" check, the two numbers passed are being '&' with 0xff.. why is that? Can someone explain this to me or guide me to some place where I can learn more about embedded programming? I'm very keen in learning this and I know my questions may sound silly or dumb but please bare with me. Thanks
Sona
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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?
--
- Alan Kilian <alank(at)timelogic.com>
Bioinformatics Applications Director, TimeLogic Corporation
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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 0x88, but that's not working. I know this isn't related to C, but this might help you understand what my problem is:
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
Sona
Alan Kilian wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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 returning a 0x65 and let's take a look and the code and see where the sign-extension is hapenning.

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.
--
- Alan Kilian <alank(at)timelogic.com>
Bioinformatics Applications Director, TimeLogic Corporation
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
<SNIP>

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.

0x65 == 101;
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 4-bytes and you get that kind of nonsense.
Nothing to do with this example, but interesting nonetheless.
--
- Alan Kilian <alank(at)timelogic.com>
Bioinformatics Applications Director, TimeLogic Corporation
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.