View previous topic :: View next topic |
Author |
Message |
achtung_m
Joined: 31 Jan 2011 Posts: 4
|
RS232 receive |
Posted: Mon Jan 31, 2011 6:09 pm |
|
|
Hi, I have a pair of temperature sensors which read through adc, now I like to send the data for rs232, but, how differentiate the reads in the rx ?
Here is the Tx code.
Greetings & tks...
Code: |
#include <16f876A.h>
#device ADC=10
#FUSES NOWDT, XT, NOPUT, NOLVP
#use delay (clock=4000000)
#use rs232 (baud=9600, xmit=PIN_C6, rcv=PIN_C7)
void main(){
int16 sen_01;
int16 sen_02;
setup_adc_ports(AN0_AN1_AN3);
setup_adc(ADC_CLOCK_INTERNAL);
while(true){
set_adc_channel(0);
delay_us(50);
sen_01=read_adc();
delay_us(50);
set_adc_channel(1);
delay_us(50);
sen_02=read_adc();
putc(sen_01);
putc(sen_02);
}
} |
|
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Mon Jan 31, 2011 10:13 pm |
|
|
You are reading a 10 bit A/D, but your putc only sends 8 bits. To send 10 bits you need to send 2 bytes. If you are going to send 2 bytes (16 bits) you can use the high bit to signal if the reading is sensor #1 or sensor #2. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
achtung_m
Joined: 31 Jan 2011 Posts: 4
|
|
Posted: Tue Feb 01, 2011 10:28 am |
|
|
ok , but if i sending with printf would take the division?
could you give an example?
Thanks & greetings. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9241 Location: Greensville,Ontario
|
|
Posted: Tue Feb 01, 2011 10:40 am |
|
|
Try it and learn while doing, it's the best teacher !
Since we do not have any idea what is receiving the data it is near impossible to create your code. Could be a simple PC with a canned terminal program or a propriatory 68k system that needs inverted, slewed 16 bit checksum!
You should develop your own protocol for your application, you'll get a lot of education!
Be aware that ANYTIME you use the RS232(....) fucntion, you MUST include the ERRORS option. |
|
|
achtung_m
Joined: 31 Jan 2011 Posts: 4
|
|
Posted: Tue Feb 01, 2011 12:46 pm |
|
|
Quote: |
Try it and learn while doing, it's the best teacher !
Since we do not have any idea what is receiving the data it is near impossible to create your code. Could be a simple PC with a canned terminal program or a propriatory 68k system that needs inverted, slewed 16 bit checksum!
You should develop your own protocol for your application, you'll get a lot of education!
|
I agree, but the end of this post is to get a guide on how to do, not everything done.
I receive the data with other pic, but I don't know how to read.
greetings. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9241 Location: Greensville,Ontario
|
|
Posted: Tue Feb 01, 2011 2:14 pm |
|
|
There are lots of examples in the examples folder of PCM, including PIC to PIC communications...
I suggest you look at them and try them. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Feb 01, 2011 3:37 pm |
|
|
Quote: | Now I like to send the data for rs232, but, how differentiate the reads in the rx ?
|
You can design an ASCII packet protocol to do this. For example,
here's the NMEA-0183 protocol:
http://www.tronico.fi/OH6NT/docs/NMEA0183.pdf
Look at this section:
Quote: |
3. General Sentence Format
|
Notice how a packet starts with a unique "packet start" character that is
not ever used as a data byte byte. Also, it has unique "packet end"
characters. You can use other ASCII characters as the delimiters, such
as STX (0x02) and ETX (0x03). The data length can be fixed, or variable.
You can include a byte that tells the packet length. You can include a
checksum byte. These are optional.
To differentiate the data from the two ADC channels, you could create a
packet that has the data for both channels. Then have the bytes for the
1st channel be first in the packet. The 2nd channel bytes would be last
in the packet.
Once you have created your packet protocol, you can design the code
in the receiver PIC. Have it look for the unique "start of packet" byte.
Then sequentially read in the packet data bytes. Put them in an array.
Stop reading them when you receive the "end of packet" byte.
Then process the data in the array.
Convert the ASCII to a binary integer so you can use it in the receiver
PIC's program. It takes four ASCII Hex data bytes to represent a 16-bit
integer value. To convert this to an 'int16', you need to make those 4
bytes into a Hex string. To do this, put the two characters "0x" in the first
two bytes of the data array. Next you have the 4 ASCII Hex data bytes.
Then put a 0x00 byte at the end. This makes it into a string.
You can now use string handling routines in string.h or stdlib.h routines
to process it. The atol() routine in stdlib.h will convert a Hex string into
an 'int16' value. This is described in the CCS compiler manual. |
|
|
achtung_m
Joined: 31 Jan 2011 Posts: 4
|
|
Posted: Tue Feb 01, 2011 5:58 pm |
|
|
Hi PCM programmer, thoroughly read about this protocol, thank you very much for give me this data.
Greetings. |
|
|
|