![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
Willson
Joined: 22 Jul 2014 Posts: 7 Location: Singapore
|
Question on RS485 driver |
Posted: Wed Jul 23, 2014 1:41 am |
|
|
Dear Sir/Madam
I would like as about this RS485.c driver created by ccs.
Is this driver able to support those RS485 Full duplex chip i.e MAX491 transceiver chip set?
I am not having any issue on half duplex, i am able to transmit and receive but only one at a time
Meet my project requirement is to transmit and receive at the same then hence i have to using full duplex transceiver chip. _________________ Willson Toh |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
Re: Question on RS485 driver |
Posted: Wed Jul 23, 2014 4:11 am |
|
|
Willson wrote: | Is this driver able to support those RS485 Full duplex chip i.e MAX491 transceiver chip set?
|
Yes. Remember all the driver, rs485.c, is doing is managing transmit enable.
In a multi-drop RS485 network, the problem is making sure only one device tries to transmit at the same time. That's a system-wide soft/firmware problem. You need to work out some sort of protocol so that transmissions don't clash.
In point-to-point (NOT multidrop) RS485, there's no need for a driver at all, you can simply treat it as a simple serial link and send whenever you like. |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
Re: Question on RS485 driver |
Posted: Wed Jul 23, 2014 9:50 am |
|
|
Willson wrote: | Dear Sir/Madam
.. my project requirement is to transmit and receive at the same then hence i have to using full duplex transceiver chip. |
RS485 is only ever half duplex. RS422 is the full duplex version. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
Willson
Joined: 22 Jul 2014 Posts: 7 Location: Singapore
|
Re: Question on RS485 driver |
Posted: Wed Jul 23, 2014 6:31 pm |
|
|
Quote: | RS485 is only ever half duplex. RS422 is the full duplex version. |
Dear asmallri,
Please correct me if i am wrong, please refer the document MAX491 of pg 8 and pg 14
of the URL from below
http://datasheets.maximintegrated.com/en/ds/MAX1487-MAX491.pdf _________________ Willson Toh |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
Re: Question on RS485 driver |
Posted: Thu Jul 24, 2014 12:16 am |
|
|
You are not wrong - the caption on the data sheet on page 18 is wrong. The device is suitable for half duplex (RS485) and full duplex (RS422) operation. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
Willson
Joined: 22 Jul 2014 Posts: 7 Location: Singapore
|
Re: Question on RS485 driver |
Posted: Thu Jul 24, 2014 2:04 am |
|
|
asmallri wrote: |
You are not wrong - the caption on the data sheet on page 18 is wrong. The device is suitable for half duplex (RS485) and full duplex (RS422) operation. |
Dear asmallri
Sorry to ask you this. Do you mean page 8 instead of 18 as there isnt any page 18. _________________ Willson Toh |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
![](templates/subSilver/images/spacer.gif) |
Willson
Joined: 22 Jul 2014 Posts: 7 Location: Singapore
|
|
Posted: Thu Jul 24, 2014 7:27 pm |
|
|
asmallri wrote: | Sorry - I meant 14 |
Dear Asmallri
So can i say i order to use RS422 full duplex operation, i have to rewrite or write the driver for this device from the beginning?
Thank alot this full and half from the datasheet it making confuse and i am very thankful from advise given. _________________ Willson Toh |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19366
|
|
Posted: Fri Jul 25, 2014 1:54 am |
|
|
I have to fractionally disagree with asmallri here....
RS422, is a subset or RS485, allowing only one driver and ten receivers. as against 32 drivers and 32 receivers.
The key point was that it was originally used by Apple, as a four wire, full duplex bus, while the commonest RS485 connections are half duplex.
On RS485, any device being able to be at different times the master, or slave, makes it better suited to half duplex operation.
However full duplex RS485, is legitimate. The key is that given that the 'reason' to go full duplex, would be to increase communication speed, the multi-master abilities would also have to disappear for maximum performance, so you effectively operate the bus with a single master, which is the RS422 'mode' (except that you can potentially still drive 32 'receivers', versus the 10 or RS422).
But, if you had (for instance) a bus with 32 devices, and two pairs of wires in each direction, with pairs of devices able to establish a 'temporary' point to point full duplex link, this is full duplex RS485.
The big question then is what you actually want to do?.
If you want the noise immunity of RS485 signalling, over 'point to point' link between two devices, then you don't need any 'drivers' at all. Each device just has it's driver permanently enabled, and it's receiver the same, and talks to the second device, as if they were next to each other on the bench, with a wire between them.
If however it is a multi-master bus with full duplex operation, then the standard 'way to work', would be to establish the initial connection, using the same code as half duplex RS485, using just one of the line pairs. Once the two devices have the link established, the 'slave' device, switches it's return path to the second pair of wires, and both devices stop using the 'turnround' code in the driver (that reverses the transceiver). All further communication, is then done at high speed, as if directly between the two devices 'on the bench'. After the data 'packet(s)' between them have been transferred, the bus is switched back, and further pairs can establish their connections if required.
This is an approach used in some existing kit. |
|
![](templates/subSilver/images/spacer.gif) |
drh
Joined: 12 Jul 2004 Posts: 192 Location: Hemet, California USA
|
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Fri Jul 25, 2014 8:23 am |
|
|
Ttelmah wrote: | I have to fractionally disagree with asmallri here....
RS422, is a subset or RS485, allowing only one driver and ten receivers. as against 32 drivers and 32 receivers.
The key point was that it was originally used by Apple, as a four wire, full duplex bus, while the commonest RS485 connections are half duplex.
On RS485, any device being able to be at different times the master, or slave, makes it better suited to half duplex operation.
However full duplex RS485, is legitimate. The key is that given that the 'reason' to go full duplex, would be to increase communication speed, the multi-master abilities would also have to disappear for maximum performance, so you effectively operate the bus with a single master, which is the RS422 'mode' (except that you can potentially still drive 32 'receivers', versus the 10 or RS422).
But, if you had (for instance) a bus with 32 devices, and two pairs of wires in each direction, with pairs of devices able to establish a 'temporary' point to point full duplex link, this is full duplex RS485.
The big question then is what you actually want to do?.
If you want the noise immunity of RS485 signalling, over 'point to point' link between two devices, then you don't need any 'drivers' at all. Each device just has it's driver permanently enabled, and it's receiver the same, and talks to the second device, as if they were next to each other on the bench, with a wire between them.
If however it is a multi-master bus with full duplex operation, then the standard 'way to work', would be to establish the initial connection, using the same code as half duplex RS485, using just one of the line pairs. Once the two devices have the link established, the 'slave' device, switches it's return path to the second pair of wires, and both devices stop using the 'turnround' code in the driver (that reverses the transceiver). All further communication, is then done at high speed, as if directly between the two devices 'on the bench'. After the data 'packet(s)' between them have been transferred, the bus is switched back, and further pairs can establish their connections if required.
This is an approach used in some existing kit. |
Your right - thanks for correcting my mistake. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
Willson
Joined: 22 Jul 2014 Posts: 7 Location: Singapore
|
|
Posted: Wed Jul 30, 2014 12:32 am |
|
|
Ttelmah wrote: | I have to fractionally disagree with asmallri here....
RS422, is a subset or RS485, allowing only one driver and ten receivers. as against 32 drivers and 32 receivers.
The key point was that it was originally used by Apple, as a four wire, full duplex bus, while the commonest RS485 connections are half duplex.
On RS485, any device being able to be at different times the master, or slave, makes it better suited to half duplex operation.
However full duplex RS485, is legitimate. The key is that given that the 'reason' to go full duplex, would be to increase communication speed, the multi-master abilities would also have to disappear for maximum performance, so you effectively operate the bus with a single master, which is the RS422 'mode' (except that you can potentially still drive 32 'receivers', versus the 10 or RS422).
But, if you had (for instance) a bus with 32 devices, and two pairs of wires in each direction, with pairs of devices able to establish a 'temporary' point to point full duplex link, this is full duplex RS485.
The big question then is what you actually want to do?.
If you want the noise immunity of RS485 signalling, over 'point to point' link between two devices, then you don't need any 'drivers' at all. Each device just has it's driver permanently enabled, and it's receiver the same, and talks to the second device, as if they were next to each other on the bench, with a wire between them.
If however it is a multi-master bus with full duplex operation, then the standard 'way to work', would be to establish the initial connection, using the same code as half duplex RS485, using just one of the line pairs. Once the two devices have the link established, the 'slave' device, switches it's return path to the second pair of wires, and both devices stop using the 'turnround' code in the driver (that reverses the transceiver). All further communication, is then done at high speed, as if directly between the two devices 'on the bench'. After the data 'packet(s)' between them have been transferred, the bus is switched back, and further pairs can establish their connections if required.
This is an approach used in some existing kit. |
Dear Ttelmah,
Actually i am try to transmit Number of packet stream over the data bus line(Two wires RS485).
Example
i have 25 devices from A to Z
A Upon power on, there are 2 devices example A and B are transmitting to data bus which is a 50 packets data stream to each other. This device carry protocol i.e
sync, dest name, dest id, source name , source, len of data, datas and crc.
Device A wants to send Data to B
Device B wants to send Data to A
That means A will have to transmit and receive at the same time and same goes to B.
i had include the rs485_wait_for_bus function with create by CCS before Transmitting. I notice when it enter the rs485_wait_for_bus the uart is being turn off(RCV_OFF). I had comment off the command it work with no problem found.
Then i try to increase the baud rate from 9600 and then 19200 the below are the finding
9600 and below baud rate
-> both devices receive with no problem
19200 baud rate
-> sometime device A receive all data correctly
-> sometime device B receive all data correctly
-> sometime both devices receive all data
-> sometime both devices did not receive all the data
i have not goes to further test on 38400 and above as i find this it is getting worst every-time the baud rate increase.
The task given to me is not to make any change in the main and to have a faster baud rate rather than 9600. Hence that was one of the reason why i ask about the full and half duplex of rs485. _________________ Willson Toh |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Wed Jul 30, 2014 4:17 am |
|
|
The rs485_wait_for_bus function is a basic function disables the UART receive logic and monitors the level on the UART RX pin to determine if the idle. If the input remains idle (high) though the testing window, the function returns FALSE signifying no traffic has been seen on the RS485 bus for the duration of the test window. If during the test period the rx input is NOT idle then the function returns TRUE indicating the RS485 bus is busy.
This approach does not take into account baud rate - it waits exactly the same amount of time at 300 baud as it does a 115200 baud. A typical RS485 packetized parsing mechanism, determines a 485 bus is idle after 3 or more character times pass since the last character was received. This time naturally varies with baud rate.
In a full duplex system the RS485_wait_for_bus will not work without modification because the RX pin is not on the same BUS as the Tx pin. There is no point in monitoring the RX side of the bus when you are trying to determine if the transmit side of the bus is busy.
Ignoring the protocol related issue above, have you check to ensure you have terminated the RS485 bus correctly? _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9173 Location: Greensville,Ontario
|
|
Posted: Wed Jul 30, 2014 5:09 am |
|
|
I have to second Andrew's last statement about proper termination of the Rs485 network !
You MUST have the correct value pullup-termination-pulldown resistors installed AND great cabling as well.
As a general comment the faster you try to go, the shorter the distance you can go.It's one of those 'Physics' things you have to obey. I can go miles at 24 Baud( that's 24 bits per second) yet trying to go 500' at 230KB is NOT reliably possible.
Be sure to read the datasheet for the RS485 transceiver chips you're using !
hth
jay |
|
![](templates/subSilver/images/spacer.gif) |
Willson
Joined: 22 Jul 2014 Posts: 7 Location: Singapore
|
|
Posted: Wed Jul 30, 2014 7:56 pm |
|
|
asmallri wrote: |
have you check to ensure you have terminated the RS485 bus correctly? |
Dear Asmallri
i had check the transceiver chip set which is SP491E which has a fail safe feature. Hence only a 120ohm termination is require
Datasheet link
www.exar.com/common/content/document.ashx?id=1337&languageid=1033
Quote: | The rs485_wait_for_bus function is a basic function disables the UART receive logic and monitors the level on the UART RX pin to determine if the idle. If the input remains idle (high) though the testing window, the function returns FALSE signifying no traffic has been seen on the RS485 bus for the duration of the test window. If during the test period the rx input is NOT idle then the function returns TRUE indicating the RS485 bus is busy. |
i had also see the function for RS485_wait_for_bus please correct me if i am wrong, this function does not return any False or True value back to main but it only pass true and false to the function parameter for watchdog timer. hence is true and false is to determine by the programmer. _________________ Willson Toh |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|