Talk:Serial Programming/RS-485
Add topicYou're an Idiot - Of course RS-485 Includes ...
[edit source]I'm adding this section to try to keep the main page free of discussion. I recently made a significant edit to the book, and am expecting a lot of disagreement. I freely admit that I make mistakes, but I also admit that I have all three of the standards. If you think I made a mistake, please tell me what section of which standard contradicts the information I added. When I re-read the standard and find that you are correct, I will be happy to apologize to you and correct my mistake. Signing your posts will be helpful for later readers of this page (sign by adding four tildes)EE JRW (discuss • contribs) 23:57, 19 October 2013 (UTC)
This Book Is A Mess
[edit source]Some of the information in this book is good, but a lot of it is common application and folklore. There are places where people added information and then asked if it was correct (usually it wasn't). There is also a lot of flat out wrong information. I think that having the common application information is good, but this information needs to be clear that it is common application, not part of the standard. The folklore and flat out wrong information needs to be corrected and/or deleted.
Examples of flat out wrong information:
- SCSI 2 is not 485. Differential SCSI (1, 2, and 3) can be 485, but my (weak) understanding is that LVDS is more common.
- The part about 485 requiring 3-pair of wires
- Anything about a "standard" connector
- Ethernet
Another question I have is; what is this book supposed to be? the header has "Serial Programming/RS-485", but the link (is that the right term?) shows "All bookshelves > Science bookshelf > Computer Science bookshelf > Serial communications bookshelf > RS-485 Technical Manual". Is this supposed to be a RS-485 technical manual or a appendix to the serial programming section? If the latter then this book should only have programming information and I am wasting my time adding the RS-485 hardware information.
My plan is to start at the top and work my way down through this book to try to correct it. Assistance would be appreciated. I have added a framework for the physical layer and plan on fleshing that out next.EE JRW (discuss • contribs) 23:57, 19 October 2013 (UTC)
Framework is now complete. I am reading my original edits am less than satisfied with my older edits. I plan on adding a couple of sections and rewriting a number of parts.EE JRW (discuss • contribs) 02:48, 14 February 2014 (UTC)
Information missing that should be added
[edit source]"The graph, often shown in these app-notes, ..." needs to be replaced with the actual graph from RS-422 The graph can be created from the following in Excel [log, log graph from the 6 values] (I haven't yet uploaded pictures to Wiki, anyone want to show me how?)
- Cable Length in Meters Data Signaling Rate in kBits/Sec
- 10000 1200
- 90000 1200
- 10000000 14
Done. No one offered to help so I eventually figured it out. A number of figures have been added.EE JRW (discuss • contribs) 02:48, 14 February 2014 (UTC)
EE JRW (discuss • contribs) 02:07, 2 November 2013 (UTC)
Legacy Discussion
[edit source]what is difference between rs432 and rs485
Does the information I recently added to the Serial Programming/RS-485#Differences between RS-232 and full-duplex RS-485 section and following sections answer your question? --DavidCary (discuss • contribs) 18:11, 7 May 2011 (UTC)
CAN discussion moved from main page
[edit source]CAN bus Cables and Connectors shows standard (?) pinouts for connecting w:CANbus to RJ11 and DE9 connectors.
(CANbus uses RS-485 signal levels and hardware, but not ASCII UARTs, right?)
CANbus can use RS485 but can also use open collector, optical or its own drivers. In any discussion of these bus systems you need to make a distinction between the physical layer and software and protocol layers. An ASCII UART can use 485 with suitable driver chips...--AndrewJWilson 18:50, 22 June 2006 (UTC)
- This is a complex topic, but the simple answer is no. CAN and RS-485 both use differential signalling, but CAN drives the twisted pair for a binary 0 to a voltage, and does not drive them (a resistor passively returns the differential twisted pair voltage to 0V) for a 1. This allows for collision detection on a CAN network. The CAN specification also defines a protocol with many more bits than are commonly used with UART based RS-485 communications. That being said, the CAN bit protocol could be used while transmitting using RS-485 drivers and receivers. The result would be communications on a twisted pair that did not meet either the CAN specification or be compatible with a UART protocol based RS-485 network.EE JRW (discuss • contribs) 22:48, 23 September 2013 (UTC)
- Update: The CiA (CAN in Automation) recently updated their website and added a history section. The CiA history page [1] states that "Today, the manufacturer-specific EIA-485 transceivers, which were quite commonly used in CAN networks at that time and were not always compatible, should have completely vanished." "That time" is the early 1990's. So it looks like I was both right and wrong, many old CAN implementations did use [RS/EIA]-485, but they were not always compatible with each other and are not compatible with today's ISO 11898-2 or ISO 11898-3 CAN physical layer specifications. EE JRW (discuss • contribs) 01:04, 23 January 2016 (UTC) (change reference to use wayback machine)EE JRW (discuss • contribs)