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

Sending and Receiving greater values via rs232[SOLVED]

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



Joined: 01 Jul 2014
Posts: 41

View user's profile Send private message Send e-mail

Sending and Receiving greater values via rs232[SOLVED]
PostPosted: Tue Oct 14, 2014 8:21 am     Reply with quote

Hello,

I am trying to send greater values like 2000 for example via serial port.

But the problem is when i send 07D0 via serial port which is 2000 in decimal pic got 7208. it send 8bit 8bit and like sending 7 first then D0.

Is there any way to send values greater than 8bit=255?

Note: I am using 30f6015 and fgetc.

Thank you!


Last edited by erhane on Thu Oct 16, 2014 2:32 am; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19401

View user's profile Send private message

PostPosted: Tue Oct 14, 2014 8:54 am     Reply with quote

If you are sending hex, then you need to decode hex on the receive.
You need to start by deciding how you are going to send. As hex, or as decimal?.
%04LX

is the printf format to send four hex digits

%05LU

is the printf format to send five ASCII text digits.

Then you either need to count the digits received, or have a 'marker' to say that this is the end of the number (typically line-feed).

Then at the receive, you receive all the digits into a text string, and either convert hex to decimal digit by digit yourself (for hex), or add the text '&H' in front of the characters received, and use the command 'atol' which converts a string of text into a 'long' integer.

Currently, you are just receiving the raw bytes. This is also a perfectly usable way of doing things, but has the problem that since all 256 possible values are sent, you can never 'know' if you have missed something. If a character gets missed, the code can never recover....

All you need do with the raw bytes, is use the make16 command.
gpsmikey



Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA

View user's profile Send private message

PostPosted: Tue Oct 14, 2014 11:24 am     Reply with quote

Depending on what you are sending too (like a PC?) be aware that some characters (like 0x0D etc.) have special meaning to the receiver and may not be handled as you expected. '0' and 'D' are fine, but the binary for 0D is a CR to some systems. Sending raw data, (instead of the hex values in ASCII (the number zero and the letter D for example) can cause strange results.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3
VernonAMiller



Joined: 11 Sep 2014
Posts: 25
Location: Contoocook, NH

View user's profile Send private message

PostPosted: Tue Oct 14, 2014 3:53 pm     Reply with quote

I agree with the idea to send the value as ASCII digits with an end marker like a linefeed or return. It's common and easy and also has the benefit of being easier to debug because you can use anything that can receive serial ASCII text to display it.

VAM
erhane



Joined: 01 Jul 2014
Posts: 41

View user's profile Send private message Send e-mail

PostPosted: Tue Oct 14, 2014 3:57 pm     Reply with quote

Actually there will be crc check. I will try this tomorrow and tell the results.

Thank you
erhane



Joined: 01 Jul 2014
Posts: 41

View user's profile Send private message Send e-mail

PostPosted: Fri Oct 17, 2014 4:53 am     Reply with quote

i did it get datas correctly but here is another problem occured.

When i want to transmit data for example send 'u' with putc('u'); command it sends ' ??u'

one blank two question marks than u. when i send putc('u'); repeadly it sends ' ??u ??u ??u'

What can be the reason? i thought about noise but it sends same message at all times thats is why this is not an issue of noise i think.

My RS485 transiever schematic is like this.
[/img]
Ttelmah



Joined: 11 Mar 2010
Posts: 19401

View user's profile Send private message

PostPosted: Fri Oct 17, 2014 7:22 am     Reply with quote

I can see one problem 'leaping out' straight away.

TTL async serial, idles 'high'.

Now, when your driver chip is disconnected from the bus (RX_Control is high), your serial output from the driver chip, feeding the PIC, is pulled low by the LED & R17. The PIC will then see this as garbage data arriving.....

The PIC_RX line needs to be pulled _high_ when the buffer is not enabled.
erhane



Joined: 01 Jul 2014
Posts: 41

View user's profile Send private message Send e-mail

PostPosted: Fri Oct 17, 2014 7:25 am     Reply with quote

Ttelmah wrote:
I can see one problem 'leaping out' straight away.

TTL async serial, idles 'high'.

Now, when your driver chip is disconnected from the bus (RX_Control is high), your serial output from the driver chip, feeding the PIC, is pulled low by the LED & R17. The PIC will then see this as garbage data arriving.....

The PIC_RX line needs to be pulled _high_ when the buffer is not enabled.


i solved my problem with removing R21 and R22. Y should be pulled up and Z should be pulled down. it was vise versa. Now everything perfect =).
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