Jump to content

Template talk:Computer bus: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
 
(31 intermediate revisions by 13 users not shown)
Line 1: Line 1:
{{Talk header}}
{{WikiProjectBannerShell|
{{WikiProject Computing}}
{{WikiProject Computing}}
{{Engineering}}
{{WikiProject Engineering}}
}}


== "Bus" terminology too restrictive ==
== "Bus" terminology too restrictive ==
Line 10: Line 13:
:I updated the title of the template to match you suggestion. Good idea! But one note, the PCIe actually is a bus standard , which is point-to-point link of two devices, its a bus with addressing resources like PCI, all these resources refer to it as a bus: [http://www.accesio.com/go.cgi?p=../cat/pcie.html] [[Pci_express#Overview]] [http://arstechnica.com/old/content/2004/07/pcie.ars] [[User:Nasa-verve|Nasa-verve]] ([[User talk:Nasa-verve|talk]]) 17:11, 11 August 2009 (UTC)
:I updated the title of the template to match you suggestion. Good idea! But one note, the PCIe actually is a bus standard , which is point-to-point link of two devices, its a bus with addressing resources like PCI, all these resources refer to it as a bus: [http://www.accesio.com/go.cgi?p=../cat/pcie.html] [[Pci_express#Overview]] [http://arstechnica.com/old/content/2004/07/pcie.ars] [[User:Nasa-verve|Nasa-verve]] ([[User talk:Nasa-verve|talk]]) 17:11, 11 August 2009 (UTC)


:Perhaps some of the types that use a network or point-to-point links (PCI Express, Serial RapidIO, etc) is *not* does not match the typical understanding of a multi-point shared bus type of bus, but 'but' *is* definitely a commonly used and understood term, commonly including those types of bus or network architectures. Perhaps "fabric" is a better term for those types of network architecture, but it seems against common sense to rule them out of here due to that. There are a lot of different ways to connect boards, computers, chips, peripherals, and a lot of different architectures, but I'd recommend not being too restrictive on how you define 'computer bus' or it'll rule out many busses for what most people will consider trivial semantic points. Just my opinion... [[User:Jwilkinson|jwilkinson]] ([[User talk:Jwilkinson|talk]]) 00:36, 13 December 2011 (UTC)
:Perhaps some of the types that use a network or point-to-point links (PCI Express, Serial RapidIO, etc) is *not* does not match the typical understanding of a multi-point shared bus type of bus, but 'bus' *is* definitely a commonly used and understood term, commonly including those types of bus or network architectures. Perhaps "fabric" is a better term for those types of network architecture, but it seems against common sense to rule them out of here due to that. There are a lot of different ways to connect boards, computers, chips, peripherals, and a lot of different architectures, but I'd recommend not being too restrictive on how you define 'computer bus' or it'll rule out many busses for what most people will consider trivial semantic points. Just my opinion... [[User:Jwilkinson|jwilkinson]] ([[User talk:Jwilkinson|talk]]) 00:36, 13 December 2011 (UTC)

:: I admire [[User:Jeh|Jeh]] for attempting to draw a clear distinction between terms so as to make them technically useful and unambiguous. However, I agree with [[User:Jwilkinson|jwilkinson]] that the so-called "universal serial bus" and PCI Express and many other things described as a "bus" actually involve point-to-point links between exactly two devices. Is there some *other* line we could draw that includes things commonly called busses (including USB and PCI Express) but excludes things like Wi-Fi and analog telephone lines? Or does blurring the line between multi-point shared buses, external [[computer port (hardware)]], and point-to-point links, give a slippery slope that leads only to ambiguity and confusion? --[[User:DavidCary|DavidCary]] ([[User talk:DavidCary|talk]]) 14:09, 8 October 2013 (UTC)

::: If we're going to include non-bus-like things like point-to-point interconnects, then I think we should change the name of the template. "Computer interconnect", perhaps. And (or, failing the rename, at the very least) the template should be reorganized with a top level category of "point to point" vs. "multi-point shared access". [[User:Jeh|Jeh]] ([[User talk:Jeh|talk]]) 21:41, 6 February 2016 (UTC)

:::: As already discussed [[#Template title|below]], "Computer buses and point-to-point interconnects" would fit much better. — [[User:Dsimic|Dsimic]] ([[User talk:Dsimic#nobold|talk]] | [[Special:Contributions/Dsimic|contribs]]) 15:43, 7 February 2016 (UTC)
:::::{{u|Dsimic}}, I think point-to-point interconnects should not be included. These are already covered by other networking and communications nav templates. With so many nav templates in existence, we should err on the side of smaller, not larger scope. ~[[User:Kvng|Kvng]] ([[User talk:Kvng|talk]]) 13:23, 25 March 2021 (UTC)


== Hyphenation ==
== Hyphenation ==
Line 78: Line 88:


[[Special:Contributions/213.131.238.28|213.131.238.28]] ([[User talk:213.131.238.28|talk]]) 10:15, 5 September 2012 (UTC)
[[Special:Contributions/213.131.238.28|213.131.238.28]] ([[User talk:213.131.238.28|talk]]) 10:15, 5 September 2012 (UTC)

== Fibre Channel ==

Fibre Channel doesn't belong to this template: ''it is not a bus, but a network.'' Removed.

[[Special:Contributions/213.131.238.28|213.131.238.28]] ([[User talk:213.131.238.28|talk]]) 10:18, 5 September 2012 (UTC)


== How about...? ==

Would these fit here?
* [[RapidIO]]
* [[Serial FPDP]]
* [[Front Panel Data Port]] (parallel FPDP)

The [[:Category:Computer buses]] lists quite a few that aren't on this template... What decides what busses make the list on the template?
--[[User:Jwilkinson|jwilkinson]] ([[User talk:Jwilkinson|talk]]) 05:14, 29 March 2013 (UTC)

== About AC '97 and Intel HD Audio define hardware point-to-point links or buses ==

AC '97 and Intel HD Audio are not only software specs. They are specifications that define the electrical connection between the chipset for a software audio solution (or audio acceleration engine for a hardware accelerated sound card) and even define the pinouts for compliant codecs. AC'97 defines a point-to-point link called the AC-Link between the chipset or audio acceleration engine and the AC'97 codec, and Intel HD Audio specification defines a bus named the High Definition Audio Link that links together one HD Audio controller and one or more HD Audio codecs. [[User:Jesse Viviano|Jesse Viviano]] ([[User talk:Jesse Viviano|talk]]) 14:40, 17 June 2014 (UTC)

: Then the template should mention AC-Link and High Definition Audio Link, not AC'97 and Intel HD Audio. I stand by my assertion that AC'97 and Intel HD Audio are not buses and don't belong in the table. (HDAL is not even mentioned in the Intel HD Audio article!) One might as well list "Personal computer" because PCs include a PCIbus. [[User:Jeh|Jeh]] ([[User talk:Jeh|talk]]) 17:08, 17 June 2014 (UTC)

: Yeah, I'm also for including [[AC-Link]] and [[High Definition Audio Link]] instead of [[AC'97]] and [[Intel HD Audio]]. — [[User:Dsimic|Dsimic]] ([[User talk:Dsimic#nobold|talk]] | [[Special:Contributions/Dsimic|contribs]]) 07:45, 21 June 2014 (UTC)

== Template title ==

Currently, the title of this template (on the bar) is:
:: [[Bus (computing)|Computer bus]] — [[technical standard|technical]] and [[de facto standard|''de facto'']] standards ([[wired communication|wired]])

I feel this is pretty confusing and archaic. So I proposed this new title. I believe it also may make sense to leave off the text in parenthesis, so please let me know your thoughts on that as well. Please provide feedback. If no one objects, I'll make the change over the weekend (3 days):
:: [[wired communication|Wired]] [[Bus (computing)|computer bus]] standards ([[technical standard|technical]] and [[de facto standard|de facto]])

[[User:Nasa-verve|Nasa-verve]] ([[User talk:Nasa-verve|talk]]) 20:10, 30 July 2014 (UTC)

: There is no such thing as a non-wired bus, so I see no reason for or benefit in this change. [[User:Jeh|Jeh]] ([[User talk:Jeh|talk]]) 04:05, 31 July 2014 (UTC)

:: Yeah, using "wired" as a prefix might be in fact more confusing than useful. If we want to go with the title change anyway, my vote would go to something like this:
::: [[Bus (computing)|Computer bus]] — [[technical standard|technical]] and [[de facto standard|''de facto'']] standards
:: As there are no wireless busses, "([[wired communication|wired]])" is pretty much redundant in the title and should be omitted, following the principle of disambiguating article titles. — [[User:Dsimic|Dsimic]] ([[User talk:Dsimic#nobold|talk]] | [[Special:Contributions/Dsimic|contribs]]) 04:40, 31 July 2014 (UTC)

:::: I still think that either the template should not include things like "parallel port", which are not buses but point-to-point links, or else should be renamed to something that doesn't include the word "bus". [[User:Jeh|Jeh]] ([[User talk:Jeh|talk]]) 08:58, 18 August 2014 (UTC)

::::: I propose to call the "input-output standards". [[User:Foo-bar|Foo-bar]] 03:18, 19 August 2014 (UTC+0900)

:::::: {{Reply to|Jeh}} If we'd go that far, SATA also technically wouldn't be a computer bus but a P-t-P link. Sure thing, you can connect multiple SATA devices to a single SATA port with port multipliers, but you can also connect multiple printers to a single parallel port by using those "printer switches" or however they're called.
:::::: {{Reply to|Foo-bar}} Hm, renaming to "input-output standards" would invite even more stuff in. For example, AHCI could be taken as some kind of an I/O standard for SATA{{snd}} it stretches the whole thing quite far, but AHCI is some kind of an I/O standard. — [[User:Dsimic|Dsimic]] ([[User talk:Dsimic#nobold|talk]] | [[Special:Contributions/Dsimic|contribs]]) 20:28, 18 August 2014 (UTC)

::::::: Keep it simple and obvious: "Computer buses and point-to-point interconnects"? Sometimes the search for concision is a mistake. [[User:Jeh|Jeh]] ([[User talk:Jeh|talk]]) 22:26, 18 August 2014 (UTC)

::::::: Agree with Dsimic re. "input-output standards". (Just FYI, AHCI is a specification of a host-controller interface. It even says so in the initialism expansion :) But it is arguably an "input-output standards" - driver writers code to it.) [[User:Jeh|Jeh]] ([[User talk:Jeh|talk]]) 22:26, 18 August 2014 (UTC)

:::::::: "Computer buses and point-to-point interconnects" sounds good as a title! — [[User:Dsimic|Dsimic]] ([[User talk:Dsimic#nobold|talk]] | [[Special:Contributions/Dsimic|contribs]]) 22:45, 18 August 2014 (UTC)

:::::::: The short and simple '''"and interconnects"''' is fine too. • [[User:Sbmeirow|<span style="color:#8D38C9;">Sbmeirow</span>]] • [[User talk:Sbmeirow|<span style="color:#8D38C9;White;">Talk</span>]] • 16:06, 7 February 2016 (UTC)

::::::::: A bus is a type of interconnect. Why not just "Computer interconnects"? Then "multipoint-access buses" and "point to point links" can perhaps be subheads. [[User:Jeh|Jeh]] ([[User talk:Jeh|talk]]) 18:24, 7 February 2016 (UTC)

:::::::::: That would also be a viable option. &mdash;&nbsp;[[User:Dsimic|Dsimic]]&nbsp;([[User talk:Dsimic#nobold|talk]]&nbsp;&#124;&nbsp;[[Special:Contributions/Dsimic|contribs]]) 16:16, 8 February 2016 (UTC)

{{outdent}}

{{ping|Dsimic}} {{ping|Nasa-verve}} {{ping|Sbmeirow}} It's been almost a year. Can we settle on a title that either doesn't mention buses, or explicitly includes p-t-p connections? [[User:Jeh|Jeh]] ([[User talk:Jeh|talk]]) 05:52, 26 November 2016 (UTC)

:"'''Computer buses and interconnects'''" • [[User:Sbmeirow|<span style="color:#8D38C9;">Sbmeirow</span>]] • [[User talk:Sbmeirow|<span style="color:#8D38C9;White;">Talk</span>]] • 08:39, 27 November 2016 (UTC)

== Stop including protocols, device interface classes, etc. ==

USB mass storage class is not a bus, it is a USB device class. It uses the USB bus.

iSCSI is not a bus. It is a spec for sending SCSI commands and receiving the responses over IP.

If we're going to include iSCSI then we would also have to include TCP. Which would be absurd. [[User:Jeh|Jeh]] ([[User talk:Jeh|talk]]) 08:55, 18 August 2014 (UTC)

== Profibus, Multibus ==
Profibus and Multibus are not a peripheral buses. they are a communication protocol, and use the EIA-485/RS-485 as physical bus. Same goes for Cameralink.
Suggest to remove these from the Peripheral list. [[User:Lionblue|Lionblue]] ([[User talk:Lionblue|talk]]) 14:59, 25 February 2017 (UTC)

Latest revision as of 13:23, 25 March 2021

"Bus" terminology too restrictive

[edit]

RS-232 isn't a "bus." Nor is Serial ATA, nor PCI-Express, anything else that involves point-to-point links between exactly two devices.

I suggest the term "interconnect standard" instead, or something simliar. Jeh (talk) 22:39, 27 July 2009 (UTC)[reply]

I updated the title of the template to match you suggestion. Good idea! But one note, the PCIe actually is a bus standard , which is point-to-point link of two devices, its a bus with addressing resources like PCI, all these resources refer to it as a bus: [1] Pci_express#Overview [2] Nasa-verve (talk) 17:11, 11 August 2009 (UTC)[reply]
Perhaps some of the types that use a network or point-to-point links (PCI Express, Serial RapidIO, etc) is *not* does not match the typical understanding of a multi-point shared bus type of bus, but 'bus' *is* definitely a commonly used and understood term, commonly including those types of bus or network architectures. Perhaps "fabric" is a better term for those types of network architecture, but it seems against common sense to rule them out of here due to that. There are a lot of different ways to connect boards, computers, chips, peripherals, and a lot of different architectures, but I'd recommend not being too restrictive on how you define 'computer bus' or it'll rule out many busses for what most people will consider trivial semantic points. Just my opinion... jwilkinson (talk) 00:36, 13 December 2011 (UTC)[reply]
I admire Jeh for attempting to draw a clear distinction between terms so as to make them technically useful and unambiguous. However, I agree with jwilkinson that the so-called "universal serial bus" and PCI Express and many other things described as a "bus" actually involve point-to-point links between exactly two devices. Is there some *other* line we could draw that includes things commonly called busses (including USB and PCI Express) but excludes things like Wi-Fi and analog telephone lines? Or does blurring the line between multi-point shared buses, external computer port (hardware), and point-to-point links, give a slippery slope that leads only to ambiguity and confusion? --DavidCary (talk) 14:09, 8 October 2013 (UTC)[reply]
If we're going to include non-bus-like things like point-to-point interconnects, then I think we should change the name of the template. "Computer interconnect", perhaps. And (or, failing the rename, at the very least) the template should be reorganized with a top level category of "point to point" vs. "multi-point shared access". Jeh (talk) 21:41, 6 February 2016 (UTC)[reply]
As already discussed below, "Computer buses and point-to-point interconnects" would fit much better. — Dsimic (talk | contribs) 15:43, 7 February 2016 (UTC)[reply]
Dsimic, I think point-to-point interconnects should not be included. These are already covered by other networking and communications nav templates. With so many nav templates in existence, we should err on the side of smaller, not larger scope. ~Kvng (talk) 13:23, 25 March 2021 (UTC)[reply]

Hyphenation

[edit]

There is no reason in normal English nor in WP:STYLE to hyphenate the two words of this or any similar title. Jeh (talk) 22:39, 27 July 2009 (UTC)[reply]

Moved to the title without the dash.  Done Nasa-verve (talk) 03:20, 17 August 2009 (UTC)[reply]

What makes a UART, or particular UART types, a bus?

[edit]

Why are 16550 UART, and UART in general, listed as buses? Aren't they covered by RS-232 or MIDI or other buses that the 16550, or UARTs in general, support? Guy Harris (talk) 05:06, 30 September 2009 (UTC)[reply]

Nothing, as far as I can tell. Removed. Guy Harris (talk) 05:28, 30 September 2009 (UTC)[reply]

Unfortunately I have no idea exactly how fast it is so don't want to put it in here and ruin something... 76.117.247.55 (talk) 19:30, 18 July 2010 (UTC)[reply]

InfiniBand a desktop bus?

[edit]

Does InfiniBand really belong in "Computer bus standards (desktop)"? Is there any desktop or even deskside system that uses InfiniBand as an internal bus? It's not a bus topology (although, strictly speaking, neither is PCIe, as I recall) and I generally see it referred to as an alternative to networks like Fibre Channel or Ethernet, not buses like PCIe, QPI, or HyperTransport. If it belongs in this template, I think it would be more appropriate under storage buses instead of desktop buses. (This same issue is true on List_of_device_bit_rates.) Thoughts? Vykk (talk) 15:13, 1 December 2010 (UTC)[reply]

Seems to be totally missing the entire ctegory of server / data center bus? There are computers larger than dekstops! Perhaps should re-org, although these of course overlap. Also "standards" is lower case, so should lower-case "s" standards (e.g. company-wide, vs. IEEE or other official org) be added? W Nowicki (talk) 22:45, 29 May 2011 (UTC)[reply]

DMA

[edit]

Direct memory access (DMA) is not a bus as such, so I suggest it is removed from this template. Sigmundg (talk) 13:54, 5 June 2011 (UTC)[reply]

Revamp

[edit]

It looks like User:Nasa-verve changed the group name from Desktop to "Standards"? Perhaps it was in response to the discussion about Infiniband, but there was no edit summary. Not sure this makes sense, since many other groups also describe standards too, just for more specific kinds of buses. I would suggest maybe "General pupose" might be a better name for them, or "Desktop and data center" (although some laptops have Hypertransport or QPI, etc). Any thoughts?

Also the links in the title are dubious. Interconnection example talks about telephone companies! Nothing at all to do with computer buses. Since some are de facto standards I will add that link and delete the misleading one. Also Multidrop bus is a specific vending machine technology, which sounds to me like it should be in the embedded category. W Nowicki (talk) 19:20, 8 June 2011 (UTC)[reply]

I support the change from "Desktop" [3] to just about anything else and I had considered doing this myself. Many of these busses are not limited to desktop computers and were used in desktops, servers, and even minicomputers. There are even embedded SBCs with PCI or ISA slots. --Tothwolf (talk) 20:22, 8 June 2011 (UTC)[reply]

MIDI

[edit]

What makes MIDI a computer bus? It's a communications protocol that can be carried over buses such as RS232 or USB, but it's no more a bus than is Ethernet. Besides, it's not even a computing technology: it's a musical instrument technology that was adapted for use in computers. Dementia13 (talk) 15:00, 27 August 2012 (UTC)[reply]

If you'll look at the MIDI article you'll learn that MIDI defines not only a protocol but also a physical layer involving 5-pin DIN connectors, current loop signaling with a single-ended +5V supply, and a 31.25 kbit/s data rate. None of this is compatible with common RS232 interfaces, so where you are getting "RS232", I do not know. It permits a number of devices to be chained together with those 5-pin connectors, each has an address, and the address is used in the protocol to indicate which device in the chain is the intended recipient. That sounds very much like a bus to me. As for computer vs. musical instrument, practically speaking it's impossible to build a MIDI-speaking or -listening device that doesn't have at least a decent microcontroller in it. As for USB, yes, there are USB to MIDI interfaces (also called "adapters") but all the ones I've seen provide the usual 5-pin DIN connectors at the non-computer end. Jeh (talk) 17:11, 27 August 2012 (UTC)[reply]
RS232 (edit: excuse me, I meant RS-422) is one of the buses that have historically been used to bring MIDI into a computer. Few computers have been built with standard MIDI ports installed, and to my knowledge, none in the last 20 years. Getting MIDI into and out of a computer always requires some type of interface, which will connect via RS422, USB, FireWire, or one of various other methods. Please don't condescend with "If you'll look at the MIDI article", I wrote it. I see your point about the description, but the funny thing about it is that the part which fits that description is the part that's away from the "computer" end, it's the part that's on the musical instrument side. The computer has no 31.25 kbaud ports, so the thing you're defining as a computer bus never actually enters the computer. Dementia13 (talk) 01:16, 28 August 2012 (UTC)[reply]
Sorry, but you are mistaken. A computer with a MIDI port does have a 31.25 kbps port - the MIDI port. The MIDI port was never an RS232 port nor an RS422 port. Well, I probably shouldn't say "never", but...
There was a period when just about any computer with a sound card had a MIDI port, because they were practically a standard feature of every sound card. The DA-15 connector was both the joystick connector and the MIDI connector, and the 31.25 kbps current loop MIDI signals did enter and leave the computer via that connector, with no RS232 or RS422 connections or signals involved. The "31.25 kbps port" (that is, a UART with a clock generator that will let it run at that speed) that you say does not exist is part of the MIDI interface on the card. There's no RS232 or RS422 interface or signals behind the DA15 connector.
Here is a wiring diagram for the standard MIDI cable used with such cards. It shows nothing that can possibly do bit rate conversion, nor conversion between current loop and RS232 or RS422's bipolar voltage-based signaling, so your conclusion that the 31.25 kbps MIDI-format current loop signals "never" entered or left the computer is necessarily incorrect.
Finally, I'll note that from the PC side, you don't talk to the MPU401 emulator port in anything like the same way you talk to a 16550-style serial port; I've dealt with both at the IN/OUT instruction level and written drivers for both. You don't have to take my word for that; you can just note that they consume very different numbers of I/O port locations and are handled by different drivers. Jeh (talk) 02:22, 28 August 2012 (UTC)[reply]
OK, but I still have the sense that it's a stretchy definition, because this is not really a port that is native to the computer: it still depends on another intermediary bus (the ISA or PCI bus of the soundcard, the MIDI to USB interface you mentioned, or the RS422 port in early Macs) for transport. There haven't been PCs with a native MIDI bus since the Atari Falcon. Once MIDI hits that second bus, it's just a data stream carried by that other bus, and doesn't have the physical layer characteristics that you noted. As in your own example, that MIDI to USB interface doesn't just passively let through the MIDI signal, it wraps the MIDI data in USB packets. At that point, the MIDI stream is changed into something other than what it originally was, and the characteristics you use to define it as a bus no longer exist. In other words, once MIDI hits the computer, it loses its identity as an independent bus. It's listed as a "computer bus", but it's only a bus when it's outside of the computer. I'll accept that, but if the definition's that loose, I think that pretty soon the door opens that you have to define something like Ethernet or a wireless technology as a "bus". Wireless devices have an electrical connection through the antenna, and they have addresses by which each individual device can be addressed, so the distinction gets thin. Dementia13 (talk) 13:54, 28 August 2012 (UTC)[reply]
"Native to the computer" is an overly restrictive criterion for "computer bus" and not one that you will find much support for. Such a criterion would also exclude USB, 1394, SCSI, FC, many others. Just because it comes standard with the computer, or exists within the computer enclosure, or is even soldered to the motherboard, doesn't mean it's "native". All of the above have always been implemented by host controllers that are either plugged into or soldered to e.g. PCI or PCIe. Whether or not the HC is built onto the motherboard or installed in a plug-in slot is immaterial.
For that matter, not even PCI or PCIe come directly out of the CPU chip. They are implemented by bridge chips in the chipset. In older chipsets these bridge chips were attached to the "front side bus", in newer ones, they are attached to the CPU via a "QPI" (Intel) or "HyperTransport" (AMD) bus. Well, technically those are point-to-point interconnects, not buses, but the point is still that PCI or PCIe are in no way "native" to the CPU.
Do you have a slightly-older mobo with an ISA slot or two in addition to the PCI? The ISA slots are implemented by a bridge chip which in turn is a PCI device. In modern chipsets and motherboards a bunch of legacy stuff that used to be on an on-the-motherboard ISA bus (not necessary with any actual slots) have now been moved to LPC, the "low pin-count bus," which is a serial bus that programmatically emulates ISA (so all the drivers, BIOS code, etc., didn't have to change). The LPC bus is, again, implemented by a bridge chip which in turn is a PCI device. It's still considered a bus. What is it, if it isn't a bus?
Just because there are other buses between the MPU401-compatible controller and the IN and OUT instructions, and the CPU registers that those instructions use to receive or send the data, doesn't make MIDI any less of a "computer bus." Jeh (talk) 22:15, 28 August 2012 (UTC)[reply]

Serial Interfaces Under the “RS” Umbrella

[edit]

Hello. There are many serial interfaces in existence: RS-485, RS-422, USB, SPI, Ethernet, Fibre Channel, and many others. Some of them are covered by the “RS” umbrella mentioned in the title and called “serial” by their respective standards or by common convention, some are not (Ethernet, Fibre Channel), but the term “serial” pertains to every single interface which employs the serial transmission principle—to all of them regardless of any informal conventions. This is exactly why I see no reason for writing “RS-232 (serial port)” instead of the proper “RS-232”—it is not the one and only serial ports, all other EIA/TIA standards of the “RS” umbrella and lots of ITU-T ones like V.35 are serial ports too at the very least. By the way, my home servers IBM eServer xSeries 345 have RS-485 serial ports along with RS-232 ones, so RS-232 is not the sole serial port standard found on computers.

As a generalization from here, we really should write names as they are in article titles: RS-232, RS-485, etc., without adding anything extra. I see contraction as the only possible form of alternation, e.g. abbreviation of “Universal Serial Bus” to “USB.” Remember: these are technical articles, hence we must keep it all technically correct and strict; if it is called “RS-232”, the we must not call it anything else like “COM1” or “serial port”—that is both impudent and disgraceful to the mathematically strict art of technology. I will go for it after a while and rename all items to their proper technical names (as per corresponding standards and specifications, mostly.)

213.131.238.28 (talk) 10:15, 5 September 2012 (UTC)[reply]

Fibre Channel

[edit]

Fibre Channel doesn't belong to this template: it is not a bus, but a network. Removed.

213.131.238.28 (talk) 10:18, 5 September 2012 (UTC)[reply]


How about...?

[edit]

Would these fit here?

The Category:Computer buses lists quite a few that aren't on this template... What decides what busses make the list on the template? --jwilkinson (talk) 05:14, 29 March 2013 (UTC)[reply]

[edit]

AC '97 and Intel HD Audio are not only software specs. They are specifications that define the electrical connection between the chipset for a software audio solution (or audio acceleration engine for a hardware accelerated sound card) and even define the pinouts for compliant codecs. AC'97 defines a point-to-point link called the AC-Link between the chipset or audio acceleration engine and the AC'97 codec, and Intel HD Audio specification defines a bus named the High Definition Audio Link that links together one HD Audio controller and one or more HD Audio codecs. Jesse Viviano (talk) 14:40, 17 June 2014 (UTC)[reply]

Then the template should mention AC-Link and High Definition Audio Link, not AC'97 and Intel HD Audio. I stand by my assertion that AC'97 and Intel HD Audio are not buses and don't belong in the table. (HDAL is not even mentioned in the Intel HD Audio article!) One might as well list "Personal computer" because PCs include a PCIbus. Jeh (talk) 17:08, 17 June 2014 (UTC)[reply]
Yeah, I'm also for including AC-Link and High Definition Audio Link instead of AC'97 and Intel HD Audio. — Dsimic (talk | contribs) 07:45, 21 June 2014 (UTC)[reply]

Template title

[edit]

Currently, the title of this template (on the bar) is:

Computer bustechnical and de facto standards (wired)

I feel this is pretty confusing and archaic. So I proposed this new title. I believe it also may make sense to leave off the text in parenthesis, so please let me know your thoughts on that as well. Please provide feedback. If no one objects, I'll make the change over the weekend (3 days):

Wired computer bus standards (technical and de facto)

Nasa-verve (talk) 20:10, 30 July 2014 (UTC)[reply]

There is no such thing as a non-wired bus, so I see no reason for or benefit in this change. Jeh (talk) 04:05, 31 July 2014 (UTC)[reply]
Yeah, using "wired" as a prefix might be in fact more confusing than useful. If we want to go with the title change anyway, my vote would go to something like this:
Computer bustechnical and de facto standards
As there are no wireless busses, "(wired)" is pretty much redundant in the title and should be omitted, following the principle of disambiguating article titles. — Dsimic (talk | contribs) 04:40, 31 July 2014 (UTC)[reply]
I still think that either the template should not include things like "parallel port", which are not buses but point-to-point links, or else should be renamed to something that doesn't include the word "bus". Jeh (talk) 08:58, 18 August 2014 (UTC)[reply]
I propose to call the "input-output standards". Foo-bar 03:18, 19 August 2014 (UTC+0900)
@Jeh: If we'd go that far, SATA also technically wouldn't be a computer bus but a P-t-P link. Sure thing, you can connect multiple SATA devices to a single SATA port with port multipliers, but you can also connect multiple printers to a single parallel port by using those "printer switches" or however they're called.
@Foo-bar: Hm, renaming to "input-output standards" would invite even more stuff in. For example, AHCI could be taken as some kind of an I/O standard for SATA – it stretches the whole thing quite far, but AHCI is some kind of an I/O standard. — Dsimic (talk | contribs) 20:28, 18 August 2014 (UTC)[reply]
Keep it simple and obvious: "Computer buses and point-to-point interconnects"? Sometimes the search for concision is a mistake. Jeh (talk) 22:26, 18 August 2014 (UTC)[reply]
Agree with Dsimic re. "input-output standards". (Just FYI, AHCI is a specification of a host-controller interface. It even says so in the initialism expansion :) But it is arguably an "input-output standards" - driver writers code to it.) Jeh (talk) 22:26, 18 August 2014 (UTC)[reply]
"Computer buses and point-to-point interconnects" sounds good as a title! — Dsimic (talk | contribs) 22:45, 18 August 2014 (UTC)[reply]
The short and simple "and interconnects" is fine too. • SbmeirowTalk16:06, 7 February 2016 (UTC)[reply]
A bus is a type of interconnect. Why not just "Computer interconnects"? Then "multipoint-access buses" and "point to point links" can perhaps be subheads. Jeh (talk) 18:24, 7 February 2016 (UTC)[reply]
That would also be a viable option. — Dsimic (talk | contribs) 16:16, 8 February 2016 (UTC)[reply]

@Dsimic: @Nasa-verve: @Sbmeirow: It's been almost a year. Can we settle on a title that either doesn't mention buses, or explicitly includes p-t-p connections? Jeh (talk) 05:52, 26 November 2016 (UTC)[reply]

"Computer buses and interconnects" • SbmeirowTalk08:39, 27 November 2016 (UTC)[reply]

Stop including protocols, device interface classes, etc.

[edit]

USB mass storage class is not a bus, it is a USB device class. It uses the USB bus.

iSCSI is not a bus. It is a spec for sending SCSI commands and receiving the responses over IP.

If we're going to include iSCSI then we would also have to include TCP. Which would be absurd. Jeh (talk) 08:55, 18 August 2014 (UTC)[reply]

Profibus, Multibus

[edit]

Profibus and Multibus are not a peripheral buses. they are a communication protocol, and use the EIA-485/RS-485 as physical bus. Same goes for Cameralink. Suggest to remove these from the Peripheral list. Lionblue (talk) 14:59, 25 February 2017 (UTC)[reply]