CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

float data RS232 transfer between two PICs

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
vortexe90



Joined: 26 Feb 2013
Posts: 30
Location: Algeria

View user's profile Send private message

float data RS232 transfer between two PICs
PostPosted: Fri Jan 03, 2014 4:28 pm     Reply with quote

hi guys, I managed to make a RS232 serial communication between two PICs. I sent my data by the command "printf" ended with the directive "\ r", and the reception is done with the instruction "gets(string)". It worked fine except that I found a problem.

It's that I can not seem to differentiate between the received data. ie I received successive data given in the form of string but how do I differentiate them to assign them to the variable in order to be displayed in a display ?
Mike Walne



Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK

View user's profile Send private message

PostPosted: Sat Jan 04, 2014 2:52 am     Reply with quote

We need to know more.

Show some examples of what you're trying to do.

What you have given us so far is too vague.

Mike
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sat Jan 04, 2014 3:55 am     Reply with quote

Agree with mike here.

However some comments.

Text based FP numbers, are probably the most 'computer hostile' way to send numbers it is possible to use....

Problem is that the range of sizes and formats that could appear is almost unlimited. You could start with a number like 1.0, and just make a tiny change, and have a form like 1.000001, then make another small change, and have a form like 1.001414E-10.
I'd really avoid sending them this way unless you must have numbers that are human readable, and even then use some control to limit the range of values that the output could produce.

Then the other problem is that the reading code, is going to be performing fp multiplications and divisions to convert the values back to 'computer understandable' form. Bulky/slow. Ugh.....

Much better to 'cheat', and send the number in another form. Like:
Code:

union
{
    int32 rawdata;
    float val;
} converter;

Then 'converter.val', is a standard fp value that can be used in the code as normal, but 'converter.rawdata', is an int32 value representing the same bytes.
Then print the value as an int32, with preferably a fixed number of digits, and/or in hex, so:
Code:

   printf("0x%08x\r",converter.rawdata);
   //or
   printf("%010lu\r",converter.rawdata);

and use atoi32 in the receiving code to convert the string back to an int32 (in an identical converter union), to have your original number.
The conversion then only used integer maths (much faster/smaller).

I've included the '0x' in the transmitted string, so the receiver code so atol32 will directly handle the value as hex, but of course this can be added at the receive end, or the conversion can be directly done. Look at teh hex conversions in input.c.

The point is you end up with fixed length strings, with known formats, which are many times easier for the receive code to handle....

Best Wishes
vortexe90



Joined: 26 Feb 2013
Posts: 30
Location: Algeria

View user's profile Send private message

PostPosted: Sat Jan 04, 2014 12:42 pm     Reply with quote

Thank you for your answers, for conversion, Thank you told me how to convert a given string to an integer, but I can not identify a data reception, I'll explain:

Infact I measure the voltage and current in a pic and I sent to another
PIC but how can I know which data is the voltage or current in the PIC that receives the data, ie each data should be followed by a character to be identified in the PIC that receives data.

I sent my data like that in the first pic:

Code:
     printf ("%2.2f\r", Voltage);
     delay_ms (100);
     printf ("%2.2f\r", Current);
     delay_ms (100);

and this data is received by the interruption by:

Code:
# INT_RDA
RDA_isr void (void)
{
  gets (value);

printf ("Voltage =%s\r", value);
}
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sat Jan 04, 2014 12:57 pm     Reply with quote

You are off to a 'wrong' start by using gets, in INT_RDA. Do a search here about this.
INT_RDA, implies _one_ character has arrived. Just one.

You need to receive the characters and decode the string yourself. Don't use gets. Use the code from ex_sisr, and you have a 'string' when you see the line feed.

Then you are off to another common error. The value in front of the decimal C print formats, is the total field width. So you are saying print in a field two characters wide _in total_, a value with a decimal point, and two digits after the decimal. Immediate overflow.....

Seriously if you are only printing two decimals, just scale the temperature *100, and send an integer.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jan 04, 2014 3:30 pm     Reply with quote

also...
you should add a 'tag' like 'V' in front of the voltage reading, and 'C' for current when you send the data stream. That way the receiving PIC can 'parse' the incoming data and correctly acquire the readings.
It's just an easy way to confirm the data is really voltage when you expect voltage, etc.

hth
jay
vortexe90



Joined: 26 Feb 2013
Posts: 30
Location: Algeria

View user's profile Send private message

PostPosted: Sun Jan 05, 2014 12:42 pm     Reply with quote

temtronic wrote:
also...
you should add a 'tag' like 'V' in front of the voltage reading, and 'C' for current when you send the data stream. That way the receiving PIC can 'parse' the incoming data and correctly acquire the readings.
It's just an easy way to confirm the data is really voltage when you expect voltage, etc.

hth
jay


Thank you "temtronic" exactly what I want to do, I'll try to encode my data in this way, unless there are other methods to make these encoded data transmitted
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group