|
|
View previous topic :: View next topic |
Author |
Message |
alicansahin
Joined: 17 Feb 2015 Posts: 2
|
RS_485 Transmitting problem |
Posted: Wed Oct 28, 2015 11:22 am |
|
|
Hi
Firstly i am so sorry for my english
we have a problem about Rs-485 serial communication with using RS-232 function
we have a master and slaves devices. Master device is a computer, slave devices are the board that we have been developing on and there are 32 slaves devices.
developing computer program establish connection every 10 sec. with a slave device. Computer Program send data every slaves device but only receive target slave device for using device ID.
For example
Time 00:00 ---------> slave 1
Time 00:10 ----------> slave 2 etc.
DATA traffic:
Computer------> slave Device
1 byte start byte
2 byte device ID
3 byte some information
2 byte check sum
1 byte stop byte
Slave --------> computer communication
1 byte start byte
10 byte data
2 byte check sum
1 byte stop byte
Firstly, Computer program send datas to slave , then slave device receive computer's dates and send slave's data but slave device not send slave device's datas.
we use interrupt(int_rda) for receiving datas in slave device. Our problem is that we could receive computer's datas from slave device but could not send slave datas from slave device.
Our code
Code: |
#use rs232 (baud=9600, xmit=pin_C6, rcv=pin_C7, parity=E, stop=1,stream=Rs_485) // definition of RS_485
// PORT_C Pin_5 is enable pin of RS_485
#int_rda // RX ucuna veri gelince meydane gelen kesme
void serihaberlesme_kesmesi ()
{
disable_interrupts(int_rda);
// data save in buffer. And we don't have problem this section. Sending data from computer is true detected with slave device
Receive_buffer[0]=getc(Rs_485);// start 0x86
Receive_buffer[1]=getc(Rs_485);// device ID MSB
Receive_buffer[2]=getc(Rs_485);// Device ID LSB
Receive_buffer[3]=getc(Rs_485);//
Receive_buffer[4]=getc(Rs_485);//
Receive_buffer[5]=getc(Rs_485);//
Receive_buffer[6]=getc(Rs_485);// Check_Sum LSB
Receive_buffer[7]=getc(Rs_485);// Check_Sum MSB
Receive_buffer[8]=getc(Rs_485);// Stop 0x70
// We have a problem this section. Message not send and device locked up
send_message( ); // this function is send data (transmit) to computer (data send slave device ------> computer)
}
// Function of send_message
void send_message( )
{
output_high(PIN_C5); // RS_485 enable pin is high so Rs_485 must transmit if "Low" this mean RS_485 must receive
putc(Trasmit_buffer[0],Rs_485);
putc(Trasmit_buffer[1],Rs_485);
putc(Trasmit_buffer[2],Rs_485);
putc(Trasmit_buffer[3],Rs_485);
putc(Trasmit_buffer[4],Rs_485);
putc(Trasmit_buffer[5],Rs_485);
putc(Trasmit_buffer[6],Rs_485);
putc(Trasmit_buffer[7],Rs_485);
putc(Trasmit_buffer[8],Rs_485);
putc(Trasmit_buffer[9],Rs_485);
putc(Trasmit_buffer[10],Rs_485);
putc(Trasmit_buffer[11],Rs_485);
putc(Trasmit_buffer[12],Rs_485);
putc(Trasmit_buffer[13],Rs_485);
output_low(PIN_C5);
} |
Pls let me now if you could help
Thanks for all thing
Last edited by alicansahin on Wed Oct 28, 2015 12:44 pm; edited 1 time in total |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9246 Location: Greensville,Ontario
|
|
Posted: Wed Oct 28, 2015 11:39 am |
|
|
notes...
1) you do not need to disable the Interrupt within the ISR. CCS C code dos that for you !
2) never put delays inside an ISR as it will 'hang' the program and you'll miss data
3) The INT_RDA 'fires' when it sees ONE incoming byte.You should NOT stay in there waiting for the other data. Your 'main' program could have a counter in it and every time the Interrupt occours, you put the new data from the ISR into the buffer[xx].
4) There's probably a few examples either in the 'code library' to look at, maybe under GSM or GPRS.... or 'search' on this forum for 'RS485'.
Jay |
|
|
alicansahin
Joined: 17 Feb 2015 Posts: 2
|
|
Posted: Wed Oct 28, 2015 11:49 am |
|
|
temtronic wrote: | notes...
1) you do not need to disable the Interrupt within the ISR. CCS C code dos that for you !
2) never put delays inside an ISR as it will 'hang' the program and you'll miss data
3) The INT_RDA 'fires' when it sees ONE incoming byte.You should NOT stay in there waiting for the other data. Your 'main' program could have a counter in it and every time the Interrupt occours, you put the new data from the ISR into the buffer[xx].
4) There's probably a few examples either in the 'code library' to look at, maybe under GSM or GPRS.... or 'search' on this forum for 'RS485'.
Jay |
thanks for answer
But
i will apply your advice but your advices relevant receive data.
i receive data not problem
my problem is that i can not transmit data in int_rda.
i want to data receive and immediately transmit . but i can not transmit |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia
|
|
Posted: Wed Oct 28, 2015 12:27 pm |
|
|
alicansahin wrote: | temtronic wrote: | notes...
1) you do not need to disable the Interrupt within the ISR. CCS C code dos that for you !
2) never put delays inside an ISR as it will 'hang' the program and you'll miss data
3) The INT_RDA 'fires' when it sees ONE incoming byte.You should NOT stay in there waiting for the other data. Your 'main' program could have a counter in it and every time the Interrupt occours, you put the new data from the ISR into the buffer[xx].
4) There's probably a few examples either in the 'code library' to look at, maybe under GSM or GPRS.... or 'search' on this forum for 'RS485'.
Jay |
thanks for answer
But
i will apply your advice but your advices relevant receive data.
i receive data not problem
my problem is that i can not transmit data in int_rda.
i want to data receive and immediately transmit . but i can not transmit |
Your application is flawed.
1. As already stated, delays greater than a few microseconds do not belong in an interrupt handler.
2. Your receive interrupt handler is entered on the receipt of the first character and never leaves the handler until it has transmitted the response. The main body of the application does nothing during this entire time.
3. If your PC application and the PIC application get out of sync, the interrupt handler will not return because it will be waiting for the rest of the receive packet which will either not come (if the PC and PIC are communicating in a lock-step mode) or the packet received will actually contain the end of one packet and the start of the next. The code segment you have shown is not enough to see how you solve this problem.
4. You disable the RS485 transmit immediately after sending the last byte of the packet to the UART but the UART has not yet transmitted the last few bytes of the message. These are still sitting in the transmit FIFO of the UART. If your PC application us waiting for a valid packet, as determined by the CRC or the stop byte then it will never see them.
5. Packet transmission does not belong is a receive handler.
The way you are going about this is not sound. If this is for a commercial application I suggest you might want to engage a developer experienced with RS485 comms to do this for you. If this is not for a commercial application then you have some study to do. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19553
|
|
Posted: Wed Oct 28, 2015 1:03 pm |
|
|
There is also the question of how the hardware is actually wired....
You need each buffer connected so that enabling the transmit, also turns off the receive, and the line from the buffer to the RX on the PIC _must_ have a pull up resistor (4K7 works well). This way when the slave starts to transmit, the receiver is disabled (otherwise the device transmitting will receive it's own bytes), and the line will be held high, so it can't float and be seen as a 'spurious' character.
#USE RS232 has options to control the enable line for you, and will then handle setting the enable, and not releasing it till the transmission has finished. |
|
|
|
|
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
|