int32 in string?

[lucasromeiro]

Hello,
I need for a INT32 in a string to send via GPRS.
but I do not know how best to do this.
for example:
I have the string: char command [400];
I want by: 4294967290
I tried these commands, but take up much space in the string:
flo = 4294967290;
-sprintf (command, "\ f% Lu" flo);
-strcpy (command, flo);
each digit of the string ends up occupying a space, in case the length of the string will be above 10.
then I have 4 bytes occupying the space of 10 bytes.
I need to improve it.
Any tips?
I tried hard but I could not.

[temtronic]

If I read this right , you have an INT32 value that you want to send to a 'device' that only accepts 'strings'.

If that's true, then your number (as shown), as a string will be 10 bytes +1 ( end of string delimiter).

It's not a limit or function of the PIC rather the GPRS device's requirement for accepting data. You should post a link to the device , perhaps ther's a 'mode' for it to accept data other than as a 'string'?

Jay

[lucasromeiro]

[Ttelmah]

That is the limitation of strings.

A ten digit number is ten digits long....

Only suggestion if this is for your own target at the other end, consider sending in hex, rather than decimal. Your 4294967290, takes 8 hex characters, versus ten decimal.

Two hex digits per byte.

It is also quicker to convert from binary to hex, and from hex to binary than to between binary and decimal. Typically about 50% of the code execution time...

This is why hex is so commonly used for things like instrumentation data.

[lucasromeiro]

[Ttelmah]

%Lx

Going the other way, strtoul using base 16 (use twice on each group of four hex character), or atoi32 (you have to catenate "0x" to the front).

[lucasromeiro]

[drolleman]

It may be sent as a string but a int32 is 4 bytes send the 4 bytes in the string then reverse it back to a int32 at the other end. Unless the data triggers control character problems. For example, a null. If the string is fixed length there should be no problems.

[lucasromeiro]

[Ttelmah]

There are some basic bits of understanding missing here.

You start your thread with the title 'int32 in string'.

Now in C, a 'string', is an array of text characters terminated with a NULL ('\0').

If you ignore the 'string' bit, then and int32, is just four bytes of data, and can be sent as four bytes of data. However strings at this point _cannot_ be involved. Any of the four bytes could (and at times _will_) be zeros. As such no string operations can be involved. As soon as you involve 'strings', you have to accept that you can no longer send the 'raw' data.

Now there are lots of ways you can send an int32 as a string. An int32, is just 32bits of data. You can play with them any way you want. The most 'compressed' - simple - way you can send the int32, on an 8bit link and still work with 'strings', is to send the data 7bits at a time. So, something like:

[drolleman]

I agree with you. But I like to cheat sometimes. Since I have control of both sides of the conversation, I like to pack as much as I can into the data stream. Many devices that carry data don't care what the data is. this is perfect for data verses a correctly formatted string. Some only check for a null. In this case I use 5 bytes maximum, so I have 0x01 to 0xff to work with. The first will indicate how many bytes are valid or null in the next 4 bytes, so no nulls appear.
For example, if it's 01 05 xx xx xx, it will only take the 1 following byte for the data, 00 00 00 05. Or 05 67 89 xx xx will take 2 following bytes, 00 67 00 89, it knows the middle byte is a null. 0xff xx xx will take no following bytes data, 00 00 00 00. These "strings" can be stored on a server for later processing if you want. If there are lots of nulls it can really shorten your data stream.

Data transmission is sometimes expensive, so finding ways to make it work is where it's at.