View previous topic :: View next topic |
Author |
Message |
erhane
Joined: 01 Jul 2014 Posts: 41
|
Sending and Receiving greater values via rs232[SOLVED] |
Posted: Tue Oct 14, 2014 8:21 am |
|
|
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: 19497
|
|
Posted: Tue Oct 14, 2014 8:54 am |
|
|
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
|
|
Posted: Tue Oct 14, 2014 11:24 am |
|
|
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
|
|
Posted: Tue Oct 14, 2014 3:53 pm |
|
|
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
|
|
Posted: Tue Oct 14, 2014 3:57 pm |
|
|
Actually there will be crc check. I will try this tomorrow and tell the results.
Thank you |
|
|
erhane
Joined: 01 Jul 2014 Posts: 41
|
|
Posted: Fri Oct 17, 2014 4:53 am |
|
|
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: 19497
|
|
Posted: Fri Oct 17, 2014 7:22 am |
|
|
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
|
|
Posted: Fri Oct 17, 2014 7:25 am |
|
|
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 =). |
|
|
|