Discussion:Bus de données

Bus informatique et Bus de données

Informations sur les historiques

↳ Bus informatique (h · j · ↵) : 270 révisions sur 11 ans
↳ Bus de données (h · j · ↵) : 26 révisions sur 10 ans
La fusion des 2 historiques entraînera 42 changements d'articles (14%) sur 296 révisions (2 ignorées).
Méthode suggérée pour respecter la licence (en cas de transfert de contenu) : utiliser {{Crédit d'auteurs|interne|titre de la source}} sur l'article et optionnellement {{auteurs crédités après fusion}} sur la page de discussion.

Un bus de données est un cas particulier d'un bus informatique. Considérant l'état de faible avancement de l'article Bus de données, quasiment pas modifié depuis 2008, je pense qu'il serait plus judicieux d'intégrer celui-ci en tant que section de l'article Bus informatique.

Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 9 juillet 2014 à 15:36 (CEST)

Ça ne me semble pas une bonne idée de réorganiser les articles avant d'avoir défini avec sources ce qu'est un bus informatique ; pour la raison qu'il y a des bus informatiques qui sont des bus au sens électrotechnique (sans logiciel) et d'autres qui n'en sont pas, voir Discussion:Bus (électricité). Et si Bus de données est fusionné, pourquoi pas Bus d'adresse et Bus de contrôle ? PolBr (discuter) 9 juillet 2014 à 16:45 (CEST)

Tout simplement parce que je ne les avais pas vus... Mais bon, du coup, j'attends de voir où va cette procédure de fusion avant de les proposer à la fusion. D'ailleurs, l'article sur les bus de contrôle ne dit rien sur le côté contrôle, mais ne fait que reprendre la notion de bus générale, et part même dans la définition d'un système à µP... Cet article ne devrait donc tout simplement pas exister sous cette forme. En fait, la plupart des bus contiennent en pratique à la fois un chemin de données, d'adresse et de contrôle. Ces notions séparées sont en général plus utilisées pour la théorie que dans la pratique. Ce qui n'empêche pas leur existence, mais sous cette forme, je trouve qu'ils n'apportent rien à l'article général.

Sinon, la notion de bus informatique me semble tout de même bien définie dans l'article, même si il y a des lacunes.

Après, je ne fais que proposer, il faut voir ce qu'en pensent les contributeurs. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 9 juillet 2014 à 22:10 (CEST)

La fusion permettra d'inclure les bus d'horloge et Bus d'interruptions, qui curieusement n'ont pas d'article. Je vais essayer de résumer la Discussion:Bus (électricité) : certains des bus informatiques (principalement, ceux de la carte mère), sont des bus au sens électrotechnique, c'est-à-dire des conducteurs pouvant relier plus de deux dispositifs (comme dans la distribution de courant électrique domestique). Ces bus ont une définition normative et des limites et contraintes de longueur et de forme. Mais les informaticiens ont tendance à appeler bus n'importe quel équipement reliant deux pièces d'équipement : témoin l'Universal Serial Bus, qui est, du point de vue électrotechnique, un système comprenant (1) une ligne de transmission (de point à point) (2) des transmetteurs et récepteurs de ligne (3) des commutateurs (4) une couche logicielle. Inclure tous les dispositifs informatiques qu'on appelle bus se justifie pleinement. Je crains pourtant que les lecteurs avec un point de vue informaticien ne s'intéressent pas aux questions électrotechniques qui n'interviennent que dans la conception des cartes mères. Ces question devraient former une bonne partie d'un article spécial consacré aux bus d'adresse, de données, de contrôle, d'horloge et éventuellement ATA (parallèle) et SCSI. Il faudrait trouver un autre titre pour cet article (Bus de carte-mère?), Bus informatique traitant du sujet le moins étonnant pour le lecteur qui aborde le sujet d'un point de vue d'utilisateur. PolBr (discuter) 10 juillet 2014 à 13:37 (CEST)

P.S. voir Catégorie:bus informatique. ——— PolBr (discuter) 10 juillet 2014 à 13:48 (CEST)

En fait, je pense que la définition du mot "bus" varie selon le domaine. Au point de vue informatique (enfin je dirai plutôt électronique numérique, mais bon), l'USB est bien un bus. Le fait que ce ne soit pas un bus du point de vue électrotechnique (terme que je ne conaissais pas avant de me pencher sur ce cas) n'est pas à mon sens une contradiction : chaque domaine a sa terminologie. Il faudrait peut-être alors, comme tu le dis, clarifier la notion dans les articles, et éventuellement mettre en avant ces différences pour cela.

Du coup, l'article bus informatique n'est peut-être pas le bon pour une fusion. Je pense à un article du style bus électronique ou même plutôt bus logique. Je vais me pencher sur la question un peu plus en détail quand j'en aurai le temps. En attendant, il vaut peut-être mieux abandonner cette procédure de fusion.

En tout cas, c'est vrai que la notion est complexe à définir car elle varie énormément selon le point de vue et le domaine du lecteur et du contributeur.

Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 10 juillet 2014 à 15:06 (CEST)

Bus d'adresse et Bus de contrôle et Bus de données et Bus informatique

Au vu du contenu de ces trois articles je pense qu'il devraient être regroupés en un seul article sous le titre « Bus (microprocesseur) » ou quelque chose de similaire ... Pano38 (discuter) 3 décembre 2015 à 10:37 (CET)

1. Pour et ne devraient-ils pas être fusionnés dans l'article Bus informatique ? --Krosian2B (discuter) 3 décembre 2015 à 13:36 (CET)

    Krosian2B : C'est une bonne idée mais j'ai l'impression Bus informatique est déjà bien chargé et manque de précision dans un certain nombre de domaines; je ne suis pas sûr qu'il faille le charger plus actuellement.Pano38 (discuter) 3 décembre 2015 à 16:25 (CET)

   Hum, pour moi, le bus d'adresse et le bus de données sont privilégiés par rapport à des bus comme le bus PCI, car ils sont intimement liés au fonctionnement du processeur, donc pas sûr que ce soit le bon endroit - je les vois d'une nature assez différente. --Catarella (discuter) 24 décembre 2015 à 11:53 (CET)

2. Pour je ne comprends pas l'intérêt de garder les 4 articles distincts... --Cbyd (discuter) 3 décembre 2015 à 14:50 (CET)
3. Pour Si ces trois bus sont distincts au sens électrotechnique, ils n'en constituent qu'un seul au sens logique (IEC 60050), comme il apparaît dans la PDD de Bus informatique. Même au sens électrotechnique, ils ne sont guère différents. Bus (microprocesseur) me semble adéquat. PolBr (discuter) 3 décembre 2015 à 19:31 (CET)
4. Bonjour, je vous invite à consulter la discussion indiquée par PolBr à cette adresse. Je ne crois pas qu'il faille fusionner avec Bus informatique, car la notion est plus générale que celle présentée dans cet article. En revanche la fusion des trois articles dont il est question ici, je suis Pour, mais pas sous le nom Bus (microprocesseur). En effet, je ne vois pas en quoi la notion de µP ait quoi que ce soit à voir avec la notion de bus. Il existe des bus sans µP et des µP sans bus. Je propose le nom bus de communication, qui permettra d'expliquer la notion logique de bus, indépendamment de ses implémentations (qu'elles soient matérielles, logicielles voir même routées dans un FPGA). Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 5 décembre 2015 à 13:21 (CET)

•  Epok : Désolé mais je ne connais pas de microprocesseur sans bus; avez vous des exemples? Comme je l'indiquait je ne suis pas bloqué sur le terme bus (microprocesseur) mais je trouve que l'expression bus de communication est peu précise et je pense que « bus de données » serait probablement adéquate sachant que seul le microprocesseur pilote le bus (de données), les adresses et le contrôle n’étant que des voies à sens unique pilotées par le µP qui est le « chef d'orchestre » les autres n'étant que des exécutants ... Pano38 (discuter) 6 décembre 2015 à 07:46 (CET)

• Je me suis peut-être avancé sur le coté µP sans bus (il me semblait en avoir vu dans des designs embarqués, où ils dialoguaient avec un seul périphérique en liaison directe, mais il devait surement y avoir une mémoire et donc un bus, même dédié). Par contre, je peux donner des 10aines d'exemples de bus sans µP : j'en utilise tous les jours... Du coup, vouloir introduire le proc dans le titre même d'un article dans lequel on va évidemment traiter de ce cas de figure, ça risque de faire bizarre. Bus de données, ça me dérange un peu car il s'agit uniquement d'un des 3 constituants des bus dont on va parler, m'enfin ça me choque quand même moins que de vouloir absolument coller un processeur dans l'histoire. Je pense que pour ce type de constituant de base d'un système électronique complexe, il faut s'extraire de la vision centrée sur les ordinateurs... Il sont tellement présents partout...

• l'adresse et le contrôle (instruction) n’étant, à mon sens, que les commandes pour sélectionner les données je suis d’avis de regrouper les trois articles sous le terme « bus de données » ... Pano38 (discuter) 18 décembre 2015 à 13:58 (CET)

• Raisonnement personnel et travail inédit : surtout pas. Le bus d'adresses sert à sélectionner une donnée, le bus de données à la transférer. C'est la base des microprocesseurs. --Catarella (discuter) 24 décembre 2015 à 11:55 (CET)

• @Catarella la question de base est qu'est-ce qu'un bus? Si la réponse est « tous groupe de fil allant au mème endroit » vous avez raison mais si ce groupe de fils est a mème d'autoriser la communication entre chaque entité du bus individuellement ce mème groupe de fils n'est pas un bus ... Pano38 (discuter) 28 décembre 2015 à 07:17 (CET)

• Je reviens encore une fois sur la notion de "groupe de fil" : un bus, à l'heure actuelle, admet (dans l'usage courant : comme dit précédemment je n'ai pas de source à présenter) un usage bien plus large, par exemple dans un FPGA où il n'y a pas de "fils", mais des portes logiques routées... C'est bien pour cela que je souhaiterais que cet article fusionné présente la notion de bus d'un point de vue plus haut niveau (c'est ce que j'entendais par "logique", càd abstrait, indépendamment de l'implémentation), contrairement à l'article Bus informatique, qui lui traite d'un aspect particulier que sont les bus matériels, statiques (en "dur").

Ou alors on fusionne vraiment le tout (y compris ce dernier article), mais on se sépare de l'aspect "ordinateur" et "processeur" qui lui colle un peu trop à la peau, et on admet la définition plus large qui en est faite afin de vraiment rendre compte de ce qu'est un bus dans les domaines à la fois de l'informatique et de l'électronique numérique, dans les systèmes embarqués, les SoC, les FPGA, les ASIC, etc. Cette définition admet également les bus logiciels qui ont bien pour tâche de faire circuler de l'information entre composants. Il s'agit de composants logiciels et non matériels, mais en ingénierie système, dans une représentation "schéma bloc" d'un systèmes d'information (p.-e. un système embarqué dédié), on s'affranchit des considérations d'implémentation. Et même si cette vue est raffinée au cours du processus de développement (on choisit quel bloc est implémenté en logiciel, quel bloc en matériel), la représentation logique du système n'est pas changée. C'est pour cela qu'il faut bien faire attention de quel niveau de représentation on parle, et que je pense que les deux articles sont nécessaires car traitant de considérations de niveau différent.

Après, ma définition est peut-être erronée d'un point de vue purement "définition normalisée", mais c'est l'usage que je constate tous les jours dans le domaine, et il me semble qu'un article d'encyclopédie doit rendre compte de l'état de l'art d'un sujet. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 28 décembre 2015 à 14:09 (CET)

• @Epok__ : comme nous avons déjà du mal a faire une synthèse des « bus informatiques physiques », je pense qu'il est encore risqué de vouloir y introduire des notions de bus virtuel ou logiciel, à moins que vous n'ayez déja une idée clair sur le sujet, mais dans ce cas pourquoi ne pas créer cet article et voir comment l’intégrer ensuite ... Pano38 (discuter) 28 décembre 2015 à 15:19 (CET)

 Epok, Agatino Catarella, PolBr et Krosian2B Il semble y avoir un consensus sur le fait de regrouper ces trois articles mais dans une situation de blocage sur le titre;
je propose de parler de « bus mémoire » ce qui permettrait de regrouper les 3 articles cités sans parler ni de processeur ni d'informatique (dans un premier temps). Qu'en pensez vous? ... Pano38 (discuter) 11 janvier 2016 à 15:43 (CET)

 Pano38, bus mémoire, cela suppose qu'il y ait une mémoire connectée au bus... C'est certes le cas l'immense majorité des cas, mais dans un design embarqué par exemple, on peut très bien avoir des bus dédiés entre quelques IP sur lesquels aucune mémoire n'est présente... Le terme Bus de communication, tout simplement, n'est-il pas pertinent ? Vouloir absolument lier ce bus à un des composants qui y est (potentiellement) connecté, que ce soit le µP ou la mémoire, me semble un peu trop réducteur quant au fonctionnement du bus lui-même. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 11 janvier 2016 à 16:20 (CET)

 Epok Nous avons cette mème conversation depuis des semaines sans que RIEN de concret n'en sorte; personnellement je ne connais AUCUN bus qui n'est pas lié à quelque-chose de physique. Que proposez vous pour faire avancer le schmilblick? ... Pano38 (discuter) 11 janvier 2016 à 16:27 (CET)

 Pano38 J'ai répondu à toutes vos propositions de nom... Vous n'avez toujours pas répondu, il me semble, à celle que je fais, depuis le début : Bus de communication. Voilà mon coup de pouce au Shmilblick...

Par ailleurs qu'entendez-vous par "physique" ? Les IP instanciés dans un FPGA sont-ils des éléments physiques ? Logiques ? Un soft-core est bien un processeur, mais il n'a rien de "physique".

Je prends certes des exemples extrêmes (par de proc, ou pas de mémoire), mais il m'est arrivé de rencontrer de telles situations. Associer le titre de l'article à un composant qui n'existe pas forcément dans le design me semble juste une mauvaise manière de faire, car cela va associer, dans l'esprit du lecteur, le bus avec ce composant. Imaginons un design, contenant un proc, une mémoire, et différents IP customs. Rien n'empêche par exemple d'avoir un bus central, reliant le proc, la mémoire et quelques IP, et un ou plusieurs bus secondaires, reliant directement 3 IP entre eux (je ne dis pas 2, car sinon, de par votre définition, on s'exclut de la notion de bus, même s’il existe des cas particuliers pour l'implémentation de bus génériques qui peuvent être convertis en liaison point à point).

Après, cela dépends si vous parlez de mémoire au sens "composant", ou au sens "plage mémoire", qui peut être présente dans n'importe quel composant, par opposition à "registre". Mais si tous les IP du second bus de mon exemple fonctionnent sur une base registre, on n'a bien aucune mémoire sur le bus.

Je cherche juste le meilleur pour l'encyclopédie, et vos proposition ne me conviennent pas pour l'instant. Mais je ne suis pas le seul décideur ici, si une majorité émerge pour l'un des titres que vous proposez, je m'y rangerais, bien entendu. Je donne juste mon avis. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 11 janvier 2016 à 16:40 (CET)

 Epok Comme je vous l'ai deja dit : « bus de communication » ne me semble pas correspondre aux trois articles à réunir et comme je vous l'ai déjà dis aussi je ne vois vraiment pas a quoi peut ressembler un bus logiciel, c'est pour cela que je vous ai demandé de rédiger un article sur le sujet, cela permettrait de voir ou/comment on peut les réunir ... Pano38 (discuter) 11 janvier 2016 à 17:42 (CET)

 Pano38 Je ne comprends pas pourquoi cela fait plusieurs fois que vous remettez l'histoire du bus logiciel sur le tapis à chacune de mes réponses, alors qu'il s'agit d'un sujet secondaire et potentiellement distinct de ce qui nous concerne ici, à savoir les bus de connexion entre composants matériels. J'ai certes, à un moment, évoqué l'hypothèse de les intégrer dans le même sac (d'un point de vue structure logique uniquement) mais je ne pousserai pas dans cette direction, et ce n'était pas le sujet ici. Mais si vous y tenez, je vous invite à consulter l'article D-Bus qui est un exemple de bus logiciel simple, ou encore ROS, qui est un middleware. Mais ce n'est pas mon domaine, donc je ne peux pas rentrer plus dans les détails, contrairement au matériel et à la discussion qui nous anime... Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 11 janvier 2016 à 18:46 (CET)

 Epok Désolé si j'ai mal compris, mais je n'y connais rien dans les domaines que vous abordez. Comme vous le disiez précédemment laissons d'autre s'exprimer sur ma proposition, je n'en vois pas de meilleur pour synthétiser les 3 articles cités ... Pano38 (discuter) 12 janvier 2016 à 08:05 (CET)

Vote pour le titre

 Epok, Agatino Catarella, PolBr et Krosian2B : Afin de clore ce vote j'ai l'impression qu'il ne reste plus qu'à statuer sur le titre entre mes propositions « bus mémoire » et « bus microprocessseur » et celle de Epok__ bus de communication ... Pano38 (discuter) 18 janvier 2016 à 14:13 (CET)

intégrer les 3 articles à bus (informatique)

1.  Cbyd et Krosian2B Plutôt pour il est clair que ces 3 articles pourraient intégrer l'article « bus (informatique) » au risque de le surcharger ... Pano38 (discuter) 19 janvier 2016 à 08:32 (CET)
2. Pour J'aurais préféré que les trois articles "Bus d'adresse" et "Bus de contrôle" et "Bus de données" intègrent "Bus (informatique)" (éventuellement amélioré), mais "Bus microprocesseur" me paraît le moins mauvais choix. --Cbyd (discuter) 18 janvier 2016 à 14:44 (CET)
3. Pour Je pense aussi qu'il faudrait les intégrer dans Bus (informatique). --Krosian2B (discuter) 18 janvier 2016 à 18:16 (CET)
4.  Neutre J'étais originellement contre, mais au vu des discussions et de l'orientation que semble prendre l'article, je ne suis plus hostile à l'idée. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 25 janvier 2016 à 16:47 (CET)

    Epok : Depuis que vous avez exprimé cette opinion, l'article Bus (informatique) a nettement évolué dans le sens que vous avez suggéré (à moins que je n'ai rien compris). PolBr (discuter) 6 février 2016 à 14:46 (CET)

   • comme tu semble d'accord pour faire un article général (hardware + software) sur « bus de données » autant intégrer les 3 articles à « bus (informatique) » ... Pano38 (discuter) 25 janvier 2016 à 17:17 (CET)

    Cbyd, Pano38, Epok, Agatino Catarella et PolBr Du coup, j'ai ajouté Bus informatique dans la boucle. Peut-être encore un ou deux avis pour cette proposition et une fusion en intégrant les 3 articles à Bus informatique ? --Krosian2B (discuter) 6 février 2016 à 13:51 (CET)

   J'avoue avoir un peu perdu le fil de la discussion et je peine à m'y retrouver dans les ajouts et renommages divers. Si un consensus semble s'être dégagé sur une fusion à l'intérieur de "Bus informatique" (dont j'ai déjà dit qu'elle avait ma préférence), il me semble judicieux d'ouvrir une nouvelle section à la fin de la discussion (au lieu de renommer celle en cours) afin de compiler les avis, certains ayant modifié leur opinion durant ce long (mais intéressant) échange.--Cbyd (discuter) 6 février 2016 à 14:28 (CET)

5. Contre fort. Un article devrait traiter de la notion générale de bus en informatique, malgré la difficulté de définir ce que c'est et la répugnance ou l'incapacité des opinants à donner des sources. Dans cette catégorie, on trouve toutes sortes de dispositifs, de ceux inclus dans les FPGA aux bus de terrain, et aussi les USB et autres. Il y a un certain nombre de généralités en commun. L'article Bus (informatique) devrait s'efforcer de réunir ces informations communes à tous les cas d'emploi du terme bus en informatique. Les articles que nous envisageons de fusionner concernent, dans l'état où ils sont, les bus qui se trouvent dans un ordinateur. C'est une petite partie du sujet qui, comme les autres, devrait être développé séparément. PolBr (discuter) 6 février 2016 à 14:46 (CET)

bus microprocesseur

1. Pour comme je l'ai proposé initialement ... Pano38 (discuter) 18 janvier 2016 à 14:34 (CET)
2. Contre fort : Comme déjà expliqué, de nombreux bus ne comportent aucun processeur... Imposer ce titre va totalement à l’encontre du concept même d'article général sur le sujet, ce qui était le but inital. Contrairement à la proposition ci-dessous, avec la mémoire, où l'absence de mémoire est tout de même rare, l'introduction du terme µp dans le titre est pire que tout à mon sens : on veut faire un article général (contrairement à Bus (informatique), justement), et on le restreint à un usage particulier ??? Faudrait qu'on m'explique. Je pense qu'il y a une grosse confusion ici, et je vous invite à relire la discussion ci-dessus... Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 18 janvier 2016 à 14:57 (CET)

   •  Epok comme signalé précédemment je ne vois pas de quoi vous parlez; je vous avais demandé d'écrire un ébauche sur le sujet, où est il? Je me prononcerais quand je l'aurais vu ... Pano38 (discuter) 19 janvier 2016 à 08:32 (CET)

   •  Pano38, je suis désolé d'en venir à dire cela, mais vous n'avez pas à "me demander d'écrire" quoi que ce soit... Vous supposez que j'ai le temps (et la volonté) de mettre en forme tout cela, seulement pour vos beaux yeux... J'ai certes bien l'intention de contribuer à l'article, mais je n'ai tout simplement pas le temps actuellement de faire cela. Je vous invite seulement à vous renseigner par exemple, sur le design sur FPGA, ou la création de design full-custom : avec quelques IP dédiés architecturés autour d'un bus, il est par exemple tout à fait possible de créer un design spécialisé, et qui fonctionne... Sans aucun processeur. Par exemple pour de la détection de mouvement, imaginez une webcam avec un capteur d'image, une ou deux unités hardware spécialisées (par exemple au pif : détection de contours, FFT ou que sais-je), une mémoire, ajoutez un DMA pour les transferts, branchez le tout sur un bus, et on a un design parfaitement fonctionnel, sans aucun processeur. C'est assez courant dans l'embarqué. Et même si ce type de design est souvent plongé dans un design plus complexe qui comporte, lui, un processeur (l'unité de détection de mouvement de mon exemple sera alors vue comme un périphérique) il n'empêche que l'on a bien un bus, sans aucun processeur branché dessus... Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 21 janvier 2016 à 18:34 (CET)

   •  Epok : désolé si je vous ai blessé mais si vous n'avez pas le temps, n'essayez pas de nous convaincre que votre point de vu est le bon. Vous ferez cela une fois qu'un article sérieux sera écrit sur le sujet que vous souhaitez? ... Pano38 (discuter) 22 janvier 2016 à 15:37 (CET)

   •  Pano38 : non, ce n'est pas une question d'être blessé, c'est juste que votre phrase "Je vous ai demandé ... où est-il" est un peu trop impérative à mon gout dans un projet collaboratif. En revanche, je vous ai présenté un exemple concret juste après, qu'en pensez-vous ? Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 22 janvier 2016 à 15:56 (CET)

   •  Epok J'avoue que cette discussion qui semble sans fin m'agace; c'est surement pour cela que je suis trop directif, désolé. S'il te plait pourrais tu dire si le titre « bus de données » pourrait te convenir ou y es tu farouchement opposé, indépendamment de l'article général que tu semble souhaiter et qui n'existe pas actuellement ... Pano38 (discuter) 22 janvier 2016 à 16:18 (CET)

    Pano38 Ah, tiens, on repasse au tutoiement. Non pas que cela m'agace, au contraire, je préfère . Concernant le titre bus de donnée, je n'y suis pas "farouchement" opposé, mais j'ai peur que cela (? n')entraîne la confusion avec le composant du bus que l'on appelle bus de données, au même titre que les autres composants que sont le bus d'adresse et le bus de contrôle, lors de la description des abstractions logiques que l'on introduira dans cet article. Par contre, je ne m'y opposerai pas : il me semble moins "mauvais" (sans coté péjoratif) que bus processeur ou bus mémoire.

   En revanche, j'aimerai beaucoup que tu me réponde sur la clarté (ou non) de mon exemple, et sur la compréhension de pourquoi je me suis opposé au titre bus processeur. C'est un point important pour moi, et je pense que sa compréhension pourra potentiellement ("pourra potentiellement" : est-ce une lapalissade ?) t'amener à contribuer plus efficacement à ce futur article. Au besoin, consulte les clarifications que j'ai apportées à PolBr dans le § ci-dessous. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 23 janvier 2016 à 00:45 (CET)

3. Contre Je demande une référence à Epok (d · c · b) pour « de nombreux bus ne comportent aucun processeur », les données servent bien à un processus effectué par un dispositif ; mais bien d'accord pour dire que le contrôleur n'est pas nécessairement un microprocesseur ; avec l'exemple évident des bus internes au chip microprocesseur. PolBr (discuter) 19 janvier 2016 à 12:38 (CET)

   • Bonjour  PolBr. Je n'ai toujours pas de référence à fournir pour la bonne et simple raison que les designs de ce type que je connais sont des designs "customs", pas forcément des designs répandus comme un PC (où, oui, on a toujours un processeur), et que je n'ai absolument pas le temps en ce moment de faire une étude bibliographique dédiée. Je sais bien que cela ne fera pas avancer le schmilblick en disant cela, mais j'en crée tous les jours (oui, j'exagère à peine ) dans le cadre de mes recherches par exemple. Sinon, je viens par exemple de détailler cas d'étude concret dans le § juste au dessus. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 21 janvier 2016 à 18:41 (CET)

   • Je crois que je comprends ce que vous voulez dire mais je crois que vous avez tort de confondre « processeur » et « microprocesseur ». Dans une carte graphique, le DSP est un processeur qui n'est pas un microprocesseur, j'espère que tout le monde est conscient qu'il y a des bus dans les cartes graphiques. PolBr (discuter) 21 janvier 2016 à 19:40 (CET)

   • Non, je ne fais pas la confusion, ou alors elle importe peu dans ce que je veux dire. Pour moi, à l'heure actuelle, il n'y a plus trop de différence entre un processeur et un µP, un GPU étant un µP (enfin, il me semble, mais là dessus, je peux me tromper, c'est peut-être simplement un processeur). Les dispositifs que j'oppose à un processeur sont les accélérateurs matériels dédiés, càd un circuit électronique (ou un routage logique dans le cas d'un FPGA) dédié à une seule tâche, et donc non programmable, contrairement à la définition même d'un processeur. Un DSP est bien un processeur, dans le sens où il est programmable logiciellement, càd qu'on lui fait exécuter une série d'instructions. Un accélérateur matériel est un IP qui fait une seule (ou un ensemble réduit de) tâche(s), mais n'exécute pas de programme. Un décodeur MPEG2 dans une carte graphique est un circuit électronique dédié à cette tâche. Il serait bien incapable de décoder autre chose que du MPEG2 (mon exemple date peut-être un peu...). Un processeur peut faire tout et n'importe quoi pour peu qu'on le programme correctement pour la tâche. Un IP dédié ne fait qu'une seule tâche, mais le fait bien plus rapidement qu'un processeur n'est capable de le faire (à fréquence équivalente). C'est toute l'opposition entre logiciel et matériel. D'où mon opposition à l'introduction du terme processeur : un circuit logique qui calcule un résultat n'est pas forcément un processeur. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 21 janvier 2016 à 20:25 (CET)

bus de données

1.  PolBr Plutôt pour ce titre pourrait effectivement assez bien décrire les 3 articles, les adresses et le contrôle n’étant pas, a mon avis des bus mais des faisceaux de fils à sens unique (donc pas des bus à mon humble avis) ... Pano38 (discuter) 19 janvier 2016 à 10:17 (CET)

   • le fait que les adresses et contrôle soient à sens unique ne change rien au fait que ce soit des bus au sens électronique/électrotechnique, et seul l'ensemble des trois en est un au sens informatique, puisque seul l'ensemble permet un transfert. PolBr (discuter) 19 janvier 2016 à 10:32 (CET)

   • comme vous le savez nos avis divergent, mais le principal est de déterminer quel sera le titre de cet article ...Pano38 (discuter) 19 janvier 2016 à 22:09 (CET)

   • Des faisceaux de fils... Pas forcément ! On l'a déjà dit, un bus ne contient pas forcément un fil pour chaque "sous-bus" (données, adresse, contrôle) : certains bus (physiques) n'en contiennent pas. Par contre, la vue logique des ces mêmes bus ne peut s'en passer (du moins je n'en connais pas d'exemple). Tout dépend donc du point de vue adopté. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 25 janvier 2016 à 16:47 (CET)

2. Pour Cette expression est répandue dans les sources qui traitent de ce que décrivent effectivement les articles ; l'ensemble des trois éléments de bus a pour but de transférer des données. Il ne semble pas qu'il existe des bus d'adresse et de contrôle indépendamment d'un bus de données. Le transfert de données est bien l'objectif du dispositif, le reste n'est qu'auxiliaire. Du point de vue informatique, tout est donnée. Une instruction, une commande sont des données (seul le processeur fait la différence). Du point de vue de la définition CEI largement discutée dans Discussion:Bus informatique, ce dispositif comprend les lignes de transfert de données, d'adresse, de contrôle et est un bus au sens informatique. Chacune de ces lignes est un bus au sens électrotechnique, et on peut, ou non, traiter de cet aspect, en ce qu'il limite les transferts. Toute ligne est aussi communication, mais le principe de moindre surprise me fait préférer l'existante. PolBr (discuter) 19 janvier 2016 à 10:32 (CET)
3.  Neutre : Pas de réticence à ce titre, si ce n'est que cela risque d'engendrer une confusion avec la partie "bus de données" au sens logique : il va falloir expliquer que la vue logique d'un bus de données est constituée d'un bus d'adresse, d'un bus de contrôle et... d'un bus de données. Qui ne représente pas la même chose. Par contre, le terme ne me semble pas impropre en soi. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 25 janvier 2016 à 16:47 (CET)

   • comme tu semble d'accord pour faire un article général (hardware + software) sur « bus de données » autant intégrer les 3 articles à « bus (informatique) » ... Pano38 (discuter) 25 janvier 2016 à 17:17 (CET)

bus mémoire

1. Plutôt pour ... Pano38 (discuter) 18 janvier 2016 à 14:34 (CET)
2. Contre cf. discussion ci-dessus, mais pour résumer : pourquoi vouloir introduire le terme "mémoire", alors que certains bus peuvent ne pas comporter de mémoire branchée dessus ? Cela pourrait porter à confusion en présupposant qu'il y a forcément une mémoire. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 18 janvier 2016 à 14:25 (CET)

bus de communication

1.  Neutre ni pour ni contre, mais c'est le terme le moins mauvais que j'ai trouvé, par opposition à ceux proposés précédemment (que ce soit "bus processeur" ou "bus mémoire"). On parle de bus. Ils sont destinés à faire communiquer des composants entre eux. D'où cette proposition. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 18 janvier 2016 à 14:25 (CET)
2.  Plutôt contre trop général ... Pano38 (discuter) 18 janvier 2016 à 14:34 (CET)

   • C'est justement le but même de cette proposition de fusion : créer un article plus général que Bus (informatique)... Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 18 janvier 2016 à 14:57 (CET)

   Ajout: je rappelle qu'on parle d'articles concernant une vision logique des bus... Et pas une implémentation ou un usage particulier. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 18 janvier 2016 à 15:05 (CET)

   • dans les 3 articles on ne parle QUE de « bus physique » et aucunement de « logique »?! ... Pano38 (discuter) 18 janvier 2016 à 16:12 (CET)

   • Ces bus sont tous des bus logiques : dans certains cas, oui, on va avoir des fils correspondant à chacun des bus, mais ces bus sont des abstractions logiques, qui dans de nombreux cas (USB, SPI, I2C, ...), n'ont aucune réalité physique. Et je dis biens logiques et non logiciels, je crois que c'est de là que viens ta confusion. Je l'ai déjà expliqué à de nombreuses reprises sur la pdd où l'on a discuté auparavant : je ne compte plus le nombre d’occurrences du mot "logique" que j'ai écrites. Ce terme, on l'a déjà dit n'est peut-être pas adéquat. Abstraits. De haut niveau. Virtuels. Ou ce que tu veux. Quoi qu'il en soit, c'est pour cela que je ne souhaitais pas que l'on fusionne ces 3 articles avec Bus informatique, qui lui traite des implémentations matérielles des bus. D'où, en partie, mon opposition farouche ici à l’utilisation des termes que tu proposes...

   Mais si c'est pour réduire cette notion à un bus de processeur, je ne vois plus aucune raison de ne pas fusionner avec l'article bus informatique. Et construire, à part, un article sur la notion de bus, et pas ses implémentation, comme présentées dans cet article. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 18 janvier 2016 à 16:30 (CET)

   •  Epok mais serais tu absolument contre la proposition de regrouper les 3 articles sous le titre « bus de données »? ... Pano38 (discuter) 19 janvier 2016 à 17:32 (CET)

Je ne vois pas comment on pourrait avoir une opinion. (1) La question posée ici est celle du titre de l'article fusionnant les trois articles bus de données, bus d'adresse, bus de contrôle. La fusion est légitime au vu de la définition logique d'un bus informatique. Ces trois canaux sont associés pour le transfert des données. Les trois articles traitent d'un cas particulier de bus informatique. Pourtant, je lis ici une redite de la discussion inconclusive de Discussion:Bus informatique ; {{u[Epok}} réclame un article « plus général », un titre qui couvre tous les cas imaginables de bus informatique. Bus informatique devrait être l'article général, et Bus de données est le titre le plus évident pour le type de bus décrit dans les articles dont il est ici question, dont la structure est telle qu'il ne peut servir qu'à transférer des données d'un dispositif central (qui n'est pas forcément un microprocesseur, en effet) à une foultitude de points distants (d'autant moins distants que le transfert est rapide). Tout ce qui est logique peut être considéré comme des données, et l'expression a l'avantage d'exister dans les sources sur la structure des cartes-mères. (2) Personne ne cite de sources à l'appui de ses préférences. PolBr (discuter) 18 janvier 2016 à 20:57 (CET)

•  PolBr si il n'y a pas moyen de trouver comment réussir cette fusion il FAUT l'abandonner, ce serait dommage ... Pano38 (discuter) 19 janvier 2016 à 08:32 (CET)

• Dommage en effet. Epok (d · c · b) avait proposé une fusion en 2014, qui a échoué. À présent, il défend l'amplification de l'article résultant de ces trois en article généraliste alors qu'ils décrivent le type de bus au sens strict qu'on trouve notamment dans les cartes mères, et aucun autre dispositif appelé bus. L'article généraliste est Bus informatique.

La confusion des réponses vient du flou des notions. En informatique, apparemment, seuls les instructions des machines et ce qui en découle sont bien définis ;-). Pour faire avec, je propose donc comme titre l'expression existante la plus proche du sujet bus de données. Il ne semble pas qu'il existe des bus d'adresse et de contrôle indépendemment d'un bus de données. Le transfert de données est bien l'objectif du dispositif, le reste n'est qu'auxiliaire. Du point de vue informatique, tout est donnée. Une instruction, une commande sont des données (seul le processeur fait la différence). Du point de vue de la définition CEI largement discutée dans Discussion:Bus informatique, ce dispositif comprend les lignes de transfert de données, d'adresse, de contrôle et est un bus au sens informatique. Chacune de ces lignes est un bus au sens électrotechnique, et on peut, ou non, traiter de cet aspect, en ce qu'il limite les transferts. Toute ligne est aussi communication, mais le principe de moindre surprise me fait préférer l'existante.

Ces articles ont peu bougé depuis leur création en 2004 et ont sans doute besoin d'une nouvelle écriture. Il n'y a qu'un problème rédactionnel, la section Bus de données au sens logique, que Speculos (d · c · b) a ajoutée le 8 octobre 2010 à 09:10. Il s'agit d'interface logicielle. Nous avons déjà discuté de ça dans Discussion:Bus informatique. Comme, à mon sens l'article Bus informatique a pour étendue (scope) tous les usages de bus en informatique, c'est là qu'il y a lieu de placer cet usage, s'il est avéré par des sources, ce dont je ne doute pas, mais il s'agit d'une métaphore (on désigne la chose par une autre auquel, par un certain aspect, elle ressemble). PolBr (discuter) 19 janvier 2016 à 10:06 (CET)

•  PolBr et Speculos J'ai l'impression que cette partie logique pourrait rejoindre l'article bus logique qui actuellement mérite d’être étoffé ... Pano38 (discuter) 22 janvier 2016 à 16:18 (CET)

Pas d'objection à créer un article Bus logique si ca peut débloquer la situation. Remarque : je n'avais pas "ajouté" le paragraphe en question en 2010, mais simplement structuré en paragraphes pour clarifier, le paragraphe en question date en fait de 2004 [1]. -- Speculos ^(discuter) 22 janvier 2016 à 16:26 (CET)

Conclusion

 PolBr, Pano38, Speculos, Krosian2B, Agatino Catarella et Cbyd :
Bonjour à tous,
Je pense que la discussion est maintenant close car il semble y avoir consensus. Si je résume :

• On fusionne les 4 articles Bus d'adresse, Bus de contrôle, Bus de données et Bus informatique.
• On les fusionne sous l'article Bus informatique.

N'hésitez pas à me corriger si je me trompe.
Si mes remarques sont correctes, il faudrait qu'un admin procède à la fusion des historiques.
Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 26 février 2016 à 11:00 (CET)

Je suis étonné par ta proposition car il y avait un consensus pour « bus de données » mais pas sur « bus informatique » où PolBr avait voté Contre fort; a t'il changé d'avis? ... ~~

Il me semblait bien qu'il avait changé d'avis, oui, mais peut-être que je me trompe. La discussion étant très longue, j'ai un peu la flemme de me replonger dedans, et j'attendrai sa réponse ici, si il le veut bien. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 26 février 2016 à 12:04 (CET)

Contre fort Je n'ai pas changé d'avis. Je pense que l'article Bus informatique doit donner les définitions et les généralités qui s'appliquent à toute la variété de bus informatiques. Les articles initialement proposés à la fusion traitaient, d'une façon très sommaire, du type de bus qu'on pouvait avoir dans les ordinateurs personnels il y a une trentaine d'années. C'est un cas particulier qui mérite un développement. On peut le définir comme un bus parallèle sans circuits dédiés. Je n'ai pas d'idées quant à la répartition des matières entre articles ; je voudrais bien voir la section Dans un ordinateur réduite à un paragraphe dans Bus informatique, et développée en un article détaillé, où serait mieux décrites les fonctions de communication internes. Cet article, qui décrirait aussi ce que font les ponts nord et sud, pourrait commencer avec le bus parallèle, tel qu'esquissé dans les trois articles à fusionner. Cette fusion peut se faire dans l'heure. La synthèse des trois textes de Bus de données, bus d'adresse, bus de contrôle est facile et rapide. Je propose de le faire sous le titre Bus de données. Cette tautologie est populaire. Si le développement des contributions demande, plus tard, des changements, on n'aura pas introduit un terme nouveau. PolBr (discuter) 3 mars 2016 à 09:45 (CET)

Donc si je comprends bien, ce que tu propose, c'est de fusionner uniquement bus de données/adresse/contrôle dans "bus de données", et de conserver "bus informatique" à part ? Je n'ai pas d'objection dans un premier temps, de toutes façons on verra à l'usage si il faut faire évoluer la situation. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 4 mars 2016 à 07:25 (CET)

Je n'y suis pas opposé afin de faire évoluer la situation. --Krosian2B (discuter) 4 mars 2016 à 20:45 (CET)

Conclusion (la suite)

 PolBr, Krosian2B, Speculos, Krosian2B, Agatino Catarella, Cbyd et Epok__ :
Bonjour à tous,
Je pense que la discussion est maintenant close car il semble y avoir consensus. Si je résume :

• On fusionne les 3 articles Bus d'adresse, Bus de contrôle dans Bus de données et on laisse Bus informatique vivre sa vie.
  

N'hésitez pas à me corriger si je me trompe ... Pano38 (discuter) 3 mai 2016 à 08:39 (CEST)

1. Plutôt pour Pas d'opposition de mon côté sur le fond, car ces bus sont indissociables. Sur le titre, j'aurais aimé quelque chose qui couvre les trois, mais je ne vois pas trop. Bus processeur ? --Catarella (discuter) 3 mai 2016 à 08:58 (CEST)
2. Plutôt pour Pour moi, c'est une bonne démarche. On va trouver une série de problèmes dans la délimitation du sujet en regroupant ces trois articles. Il se peut que ce travail change notre conception de Bus informatique, mais on verra plus tard. PolBr (discuter) 3 mai 2016 à 09:14 (CEST)
3. Plutôt pour Ok sur le principe de fusion proposé.--Cbyd (discuter) 3 mai 2016 à 13:37 (CEST)
4. Plutôt pour ok bon compromis --Krosian2B (discuter) 3 mai 2016 à 18:54 (CEST)
5.  OK pour moi. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 6 juin 2016 à 17:37 (CEST)

• Il restera quand même le problème des liens interlangues: actuellement Bus de contrôle est lié à en:Control_bus, Bus d'adresse est lié à en:Address_bus mais Bus de données n'est lié à aucun article anglais. -- Speculos ^(discuter) 3 mai 2016 à 09:15 (CEST)

•  Speculos : J'ai lié en:Databus à Bus de données et en:Bus_(computing) est lié à bus informatique.

 PolBr, Speculos, Krosian2B, Agatino Catarella, Cbyd et Epok__ : Je pense qu'il ne reste plus qu'a faire la fusion des 3 articles. Un volontaire? ... Pano38 (discuter) 6 juin 2016 à 17:25 (CEST)

Prototype du nouvel article

 PolBr, Speculos, Krosian2B, Agatino Catarella, Cbyd et Epok__ : Le nombre de volontaire étant trop important j'ai décidé d'écrire la compilation des 3 article et de la mettre à l'adresse Bus de données/nouveau. Il serait bon que chacun y jette un œil et mette ses commentaires ici plutôt que de modifier directement le nouvelle article. J'ai laissé les articles « bus d'adresse et bus de contrôle » dans leur état d’origine pour l'instant (merci de ne pas les modifier). Cordialement ... Pano38 (discuter) 10 juillet 2016 à 11:42 (CEST)

1. Pour bien sur ... Pano38 (discuter) 10 juillet 2016 à 11:42 (CEST)
2. Plutôt pour rien vu de choquant pour le moment, merci pour ce travail --Catarella (discuter) 10 juillet 2016 à 11:49 (CEST)
3. Pour Salut, et merci pour cette ébauche. Si ça ne te dérange pas, je vais retoucher un peu, je trouve qu'on est encore trop centré sur les ordinateurs et les processeurs... Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 10 juillet 2016 à 17:10 (CEST)

   • J'ai proposé quelques modifications. Je pense qu'il est très important de ne pas se focaliser sur les ordinateurs, surtout à l'heure de l'internet des objets dans lequel les systèmes embarqués sont en train de devenir plus nombreux que les ordis. Il y a encore quelques problèmes de style, mais le gros de l'article me semble correct. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 10 juillet 2016 à 17:47 (CEST)

   • Une réflexion que je me fais : je ne suis pas sûr que l'on devrait parler du bus logiciel dans cet article ; on en parle déjà dans bus informatique, et cet article-ci s'attache plutôt à la structure logique du bus matériel. Remarque, par extension, je suppose que les bus logiciels disposent également d'adresses et de signaux de contrôle... à réfléchir. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 10 juillet 2016 à 18:04 (CEST)

   •  Epok Concernant le « bus logiciel », je me rappelle que cela avait été un « point de blocage » (voir les différentes discussions); personnellement cela ne me générais pas de ne pas le faire apparaitre dans cet article étant donné le peu d'information et l'absence de source; mais évitons une « guerre d'édition » pour 2 lignes ... Pano38 (discuter) 11 juillet 2016 à 07:32 (CEST)

   •  Pano38 Pourquoi parler immédiatement d'une guerre d'édition ? J'ai simplement fait une proposition. Je ne suis pas contre que cela soit mentionné dans l'article, je me questionnait juste sur la pertinence de cette info à cet endroit. Mais si tu penses que c'est adapté, pas de soucis. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 11 juillet 2016 à 15:10 (CEST)

   •  Epok comme dit précédemment, je partage totalement ton interrogation sur la pertinence de ces 2 lignes,, mais je pense que le priorité actuelle est de finaliser le regroupement de ces 3 articles qui dure depuis si longtemps ... Pano38 (discuter) 11 juillet 2016 à 15:17 (CEST)

   • Salut  Pano38. J'ai effectué un dernier ajout. Pour moi, le nouvel article peut venir remplacer les anciens. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 12 juillet 2016 à 12:45 (CEST)

Fin du débat?

 PolBr, Speculos, Krosian2B, Agatino Catarella, Cbyd et Epok__ : Quelqu'un voit il un inconvénient à ce que :

1. l'article bus d'adresse devienne une redirection vers Bus_de_données/nouveau#Bus d'adresse ;
2. l'article bus de contrôle devienne une redirection vers Bus_de_données/nouveau#Bus de contrôle ;
3. l'article bus de données/nouveau remplace l'actuel bus de données.

... Pano38 (discuter) 14 juillet 2016 à 10:06 (CEST)

• Pas d'inconvénient, merci pour tous ces efforts.--Cbyd (discuter) 14 juillet 2016 à 12:12 (CEST)
• D'ac. PolBr (discuter) 14 juillet 2016 à 13:07 (CEST)
•  OK pour moi. Attention aux redirections toutefois : vers Bus de données#Bus d'adresse et Bus de données#Bus de contrôle. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 14 juillet 2016 à 13:17 (CEST)

Salut  Pano38,
Je pense qu'il y a un gros problème avec ta manière de pratiquer la fusion ! Tu as créé une redirection vers Bus de données/nouveau... La procédure n'est pas celle-là. Si je me souviens bien, il faut :

1. Mettre le nouveau texte dans tous les articles Bus de données, bus d'adresse et bus de contrôle,
2. Demander à un admin de procéder à la fusion des historiques,
3. Transformer Bus d'adresse et Bus de contrôle en redirection,
4. Et enfin supprimer Bus de données/nouveau, qui n'était là que de manière temporaire et ne doit pas rester l'article principal.

Si quelqu'un peut confirmer cette procédure ?
Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 16 juillet 2016 à 11:50 (CEST)

 Epok : j'avoue que je n'avais pas faut ce genre de demande avant; J'ai effectivement créé une redirection vers bus de données/nouveau comme « mesure temporaire » en attendant ce que j'ai demandé aux admins, que faut il que je fasse maintenant? l'annuler, la modifier? ... Pano38 (discuter) 16 juillet 2016 à 14:30 (CEST) .

En fait, c'est plutôt une demande de fusion d'historique qu'il aurait fallut faire, je pense. Je vais ajouter un lien dans ta demande vers cette conversation, pour que les admins avisent en fonction de la situation. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 16 juillet 2016 à 15:45 (CEST)

Je propose la chose suivante : retour au nommage précédent (Renommage Bus de données/obsolete => Bus de données), puis remplacement du contenu de cet article par le contenu de Bus de données/nouveau, et mise en œuvre de la fusion, soit par fusion des historiques, soit par crédit des auteurs des autres articles sur la PDD. le problème de ton renommage + changement de la cible est que cela oblige à passer par un admin pour le renommage, car la page source a été modifiée. Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 16 juillet 2016 à 17:41 (CEST)

De toute manière vu que l'historique de Bus de données a 2 lignes, si on veut défaire le renommage fait, il faut les outils admins. --Nouill 19 juillet 2016 à 07:01 (CEST)

 PolBr, Speculos, Krosian2B, Agatino Catarella, Cbyd et Pano38 : la page ayant été renommée, j'ai procédé à la fusion avec un simple crédit d'auteurs. Étant donné que c'est la première fois que je réalise cette opération, j'espère que je n'ai rien oublié dans la procédure... Il reste d'ailleurs la page Discussion:Bus d'adresse dont je ne sais pas quoi faire. Doit-on déplacer les discussion vers cette page ?

Wikipédiennement, Epok__ (_Insultes, ^éloges, simples discussions : ✉), le 19 juillet 2016 à 18:35 (CEST)

Proposition de recentrage du sujet

Tel qu'il est, l'article constitue un doublon de Bus informatique, tandis qu'un sujet sur lequel il y a matière à un article n'est pas traité. À mon avis, et c'est le sens que je donnais à ma préférence pour ne pas fusionner les trois articles bus de données, bus d'adresse, bus de contrôle dans bus informatique, le présent article devrait porter sur une implémentation matérielle d'un bus informatique, celle qui relie des composants mémoire et des composants I/O à un ou plusieurs composant processeur avec un ou plusieurs composant contrôleur.

Ce sujet aura à considérer les signaux (et non les données), leur transfert, la rapidité, etc. Il devra donner les connaissances de base pour comprendre les choix d'architecture de systèmes à plusieurs composants (chips). Il y a de quoi faire, en renvoyant tout ce qui concerne la logique et les transferts de données à Bus informatique. On a peut-être une chance d'arrêter de confondre le diagramme fonctionnel des bus, qui concerne les données, avec l'architecture d'une carte-mère, qui concerne les signaux. PolBr (discuter) 21 juillet 2016 à 22:06 (CEST)

•  Pano38 et Epok : Selon une source ancienne par rapport à l'évolution de l'informatique, Michel Fleutry, Dictionnaire encyclopédique d'électronique, La maison du dictionnaire, 1992 (ISBN 2-85608-043-X), un bus (a1) est une « artère d'interconnexion formée d'un groupe de conducteurs assurant le transfert parallèle des informations entre les organes de l'unité centrale complète d'un ordinateur (cf. aussi data bus, address bus, control bus, parallel transfer et central processing unit) » (texte intégral, p.93). C'est ce dispositif que je souhaiterais qu'on puisse traiter dans cet article. PolBr (discuter) 23 juillet 2016 à 21:09 (CEST)

un bus ne concerne pas que l'unité centrale, ni que la carte mère et n'est pas forcement parallèle comme dit précédemment. Laissons le « bus de données » tranquille pendant quelque temps il a eu déjà beaucoup TROP de mal à devenir ce qu'il est ... Pano38 (discuter) 24 juillet 2016 à 06:04 (CEST)

Je ne propose pas de reprendre le débat de bus informatique, mais de répartir la matière entre les deux articles, avec une source. Je sais que la réflexion théorique a dépassé cette ancienne définition. À défaut supprimer Bus de données ou le rediriger sur l'article généralistes, comme plusieurs l'avaient proposé. PolBr (discuter) 24 juillet 2016 à 09:53 (CEST)

Pour éviter toute confusion il faudrait créer une demande fusion des deux articles; cette fusion ci est close. Pour rappel j'avais proposé la fusion de tous les articles le 16 février et tu t'y était opposé avec un Contre fort péremptoire?! ... Pano38 (discuter) 24 juillet 2016 à 15:35 (CEST)

Tout à fait fort, en effet, pour la raison que j'invoque ici : il y a deux sujets, comme je l'ai remis plus haut, la transmission de l'information entre plusieurs unités fonctionnelles, traitée dans Bus informatique, et la transmission du signal entre plusieurs composants informatiques, à traiter, et pour lequel je pense que Bus de données est un titre approprié, m'appuyant désormais sur Fleutry 1992. PolBr (discuter) 24 juillet 2016 à 18:30 (CEST)

Si la structure actuelle convient, c'est très bien. Nous avons déjà passez suffisamment de temps sur ce sujet ... Pano38 (discuter) 24 juillet 2016 à 19:51 (CEST)

Précisément, elle ne convient pas. Elle traite du même sujet que Bus informatique, et l'autre sujet n'est même pas abordé. PolBr (discuter) 24 juillet 2016 à 20:14 (CEST)

Comme dit précédemment faites une demande officiel de fusion et nous pourrons débattre de votre idée. Cette fusion laborieuse est close! ... Pano38 (discuter) 25 juillet 2016 à 07:56 (CEST)

Il ne s'agit pas de fusion. mais de #Proposition de recentrage du sujet de cet article -- lire juste sous le titre de section. PolBr (discuter) 25 juillet 2016 à 08:19 (CEST)

plutôt que de parler dans le vide faites nous un prototype au moins de la structure et nous pourrons en discuter ... Pano38 (discuter) 25 juillet 2016 à 08:37 (CEST)

La #Proposition de recentrage du sujet constitue un plan de travail ; vous pouvez remarquer que je collecte des sources ; et je sollicite l'avis des contributeurs qui se sont intéressés à Bus informatique. PolBr (discuter) 25 juillet 2016 à 08:50 (CEST)

Désolé mais il est clair que nous n'avons pas la mème définition d'un « plan de travail » qui devrait comporter :

• des taches
• des acteurs
• des objectifs
• des dead-lines
• , etc.

je ne voit rien de tout cela dans votre prose ... Pano38 (discuter) 25 juillet 2016 à 09:26 (CEST)

Appelez ça comme vous voulez. Merci de répondre sur le fond. PolBr (discuter) 25 juillet 2016 à 09:56 (CEST)

 Epok et Pano38 : J'ai recueilli mes notes et sources, de façon moins éparse et mieux organisée que dans les pages de discussion, en attente de conseil des experts, dans Utilisateur:PolBr/Brouillon. PolBr (discuter) 25 juillet 2016 à 10:14 (CEST)

trêve de bla-bla, où peut on voir ces notes et ces sources? ... Pano38 (discuter) 25 juillet 2016 à 10:32 (CEST)

Utilisateur:PolBr/Brouillon. PolBr (discuter) 25 juillet 2016 à 12:07 (CEST)

cet article pourrait, peut être, venir en complément d'un article bus informatique ou bus de données mais certains passage sont plutôt liés à la logique booléenne qu'à l’informatique proprement dit alors que d'autre sont déjà plus ou moins dans l'article bus informatique et d'autre encore n'ont rien à voire avec l’informatique (exemple barre omnibus). Je ne suis pas sur de voir l’intérêt, désolé ... Pano38 (discuter) 25 juillet 2016 à 14:34 (CEST)

Veuillez lire le brouillon que vous dénigrez, et évitez de le confondre avec Bus (électricité).

Je répète ma proposition à l'attention de lecteurs de cette discussion : ma proposition, sur laquelle vous n'avez pas opiné, est de faire dans Bus de données un exposé sur l'implémentation matérielle d'un bus, tandis que Bus informatique continuera à en faire l'analyse fonctionnelle. Le Vocabulaire électrotechnique international CEI fait explicitement cette distinction. Jusqu'à présent, les aspects matériels ne sont abordés que par des allusions dans Bus informatique d'une part, et dans Bus (électricité) d'autre part.

Quels passages « sont plutôt liés à la logique booléenne qu'à l’informatique » ? Quelle est votre opinion sur la proposition ? PolBr (discuter) 25 juillet 2016 à 20:55 (CEST)

Je n'ai JAMAIS vus le rapport entre un bus électrique qui connecte tout ce qui a besoin d'électricité et un bus informatique (sauf le nom); vous me demandé mon opinion, mais quand je vous la donne vous trouvez que je dénigre ... passez vous de mon opinion et soyez heureux! ... Pano38 (discuter) 26 juillet 2016 à 07:42 (CEST)

Il se trouve que le bus informatique fonctionne à l'électricité, ce qui en fait un cas particulier du bus électrique. Mais je ne lis pas votre opinion dans vos réponses. Vos appréciations sont plutôt négatives ; mais, s'agissant de notes au brouillon, elles pourraient aussi bien être de bienveillants conseils, pour l'améliorer. Selon vous, faut-il plutôt reprendre la discussion de fusion pour inclure Bus de données dans Bus informatique ? Ce qui me faisait penser le contraire, est que, au contraire des artères de communication externes (USB et autres), le bus électronique appliqué à l'informatique n'a pas d'article détaillé. PolBr (discuter) 26 juillet 2016 à 08:16 (CEST)

Pour vous tout ce qui utilise de l'électricité est lié à l'électrotechnique, que ce soit un micro-onde, un ordinateur ou l'anneau du CERN ... bon courage ... Pano38 (discuter) 26 juillet 2016 à 10:38 (CEST)

Je constate de votre part une répugnance à employer le mot électronique. En dehors de l'informatique le terme bus sert aussi en traitement du signal (bus de mélange), une spécialité qui ne relève pas à proprement parler de l'électrotechnique. Quant à l'informatique, si pour vous l'ordinateur manipule les données uniquement par l'action des données, sans aucune intervention électrique, je vous souhaite réciproquement bon courage pour comprendre pourquoi un ordinateur de 2016 n'est pas organisé comme un ordinateur de 1980. Je propose de consacrer l'article bus de données au bus informatique quand il prend la forme définie en électronique d'un bus (IEC 60050, gouv.fr, Fleutry 1991). Il me semblait que cette proposition devait recueillir votre approbation, puisque dans les discussions de Bus informatique, vous tendiez à définir celui-ci par les sorties à trois états, une caractéristique proprement électronique, à moins que l'impédance soit devenue une catégorie logique. Je me réjouissais de vous voir annoncer que vous commenciez le travail sur Bus de données ; mais vous avez pris une direction qui en fait un doublon de Bus informatique. Mes remarques semblent vous contrarier, je le regrette. PolBr (discuter) 26 juillet 2016 à 10:59 (CEST)

 Pano38 et Epok : J'ai pu avancer une proposition plus précise dans Utilisateur:PolBr/Brouillon. J'ai pu inclure des références, mais sans doute les spécialistes que vous êtes pourront en apporter plus. PolBr (discuter) 28 juillet 2016 à 15:02 (CEST)

 Pano38 et Epok : ma proposition Utilisateur:PolBr/Brouillona atteint un état provisoirement définitif. Manquent quelques référence, qui seront, j'en ai peur, toutes en anglais, sauf si on peut m'en souffler quelques unes en français. Suivant les observations de Pano38, je me suis efforcé d'éviter les détails techniques et les considérations communes à toutes les transmissions de données, au profit d'un exposé des problèmes qui aboutit à la description des systèmes actuels. PolBr (discuter) 31 juillet 2016 à 10:29 (CEST)

Réponse

Extrait de Discussion utilisateur:PolBr/Brouillon:

• PolBr écrit « je propose de traiter le point de vue fonctionnel, informatique, dans Bus informatique, et le point de vue signal, électronique, dans Bus de données » ; le 29 juillet 2016 à 14:55 (CEST) Pano38 (d · c · b) répond « désolé mais je ne me rappelle pas de cette proposition ou alors j'ai du vous répondre que je n'était pas d'accord du fait des efforts qu'il a fallu déployer pour synthétiser trois articles apres de nombreux compromis ». PolBr (discuter) 29 juillet 2016 à 15:14 (CEST)

comme je vous l'ai dit votre point de vu signal n'est pas ce qui se passe dans la réalité, j'ai n'est donc pas l'intension de continuer à perdre mon temps avec vous .... bon courage ... Pano38 (discuter) 31 juillet 2016 à 15:05 (CEST)

Bus de données logiciel

Sans vouloir vous faire perdre votre temps ni gêner votre contribution : il n'y a pour ainsi dire rien sur « bus de données logiciel ». Je crois que vous pourriez vous en débarrasser. Si vous ne voulez pas le supprimer sèchement, il y a la possibilité de faire un Article court bus de données (logiciel) renvoyant à Bus logiciel, avec le texte existant qui le reliera à bus informatique, CORBA et ORB. De cette façon, la table des matières sera plus claire et aura un niveau de moins, toutes les sous-sections pouvant devenir sections. PolBr (discuter) 3 février 2017 à 10:25 (CET)

• Plutôt pour  PolBr je crois que nous avions gardé cette partie à une époque où nous avions d'autres chats à fouetter; j'ai l'impression que ce temps est révolu ... Pano38 (discuter) 3 février 2017 à 17:49 (CET)

Confusion CS et bus d'adresse?

Le Chip select a été mis dans le bus d'adresse alors qu'il devrait plutôt être dans le bus de contrôle; en effet le signal CS ne sert pas à sélectionner un emplacement mémoire mais à sélectionner une carte mémoire lorsqu'il y en a plusieurs ... Pano38 (discuter) 13 mai 2017 à 16:04 (CEST)

Sauf source qui affirmerait le contraire, le Chip Select est un connecteur d'un circuit qui le rend actif. Il y a des CS sur les circuits de mémoire (qui peuvent être plusieurs sur la même carte mémoire), sur les circuits d'interface, etc. Le CS ne sert à sélectionner une carte que s'il n'y a qu'un circuit dessus (ce qui peut en effet arriver). Sinon, il reçoit le signal indirectement, par l'intermédiaire d'un circuit qui peut être un demux ou une unité de contrôle de pages mémoire, ou autres. AMHA, ce n'est pas un circuit de bus mais une liaison point à point entre le chip et un circuit intermédiaire entre celui-ci et le contrôleur. C'est d'ailleurs ce que l'article indiquait avant votre intervention.

Cette liaison fait évidemment partie de l'adressage, puisqu'elle détermine quels circuits contrôlent ou observent le bus, ce qui est la définition de l'adressage. PolBr (discuter) 13 mai 2017 à 19:07 (CEST)

• Et comment sélectionne on une mémoire en particulier ? Par le bus d'adresse? ... Pano38 (discuter) 13 mai 2017 à 20:04 (CEST)

Prenons une antiquité, elles sont plus simples. Les microprocesseurs Z80, 6800 ou 6502 avaient un bus d'adresses 16 bits. Les circuits mémoire courants avaient une capacité de 4K. Ces mémoires avaient donc 12 lignes d'adresse. En plus, les mémoires (et autres UART) avaient une ligne chip select. Un demux transformait les 4 lignes du bus d'adresse inutilisées, faute d'entrées sur le composant mémoire, en 16 lignes reliées directement à chaque CS de mémoire. Adressage total 64 K. En automatisme, on a encore des circuits qui fonctionnent comme ça. C'était peu (et grignoté par divers circuits adressables nécessaires). On a donc créé les pages mémoire. Les circuits de mémoire peuvent avoir le même nombre de lignes d'adresse que le processeur, sinon on procède comme avant ; le processeur écrit en mémoire de gestionnaire de pages le numéro du circuit qui doit être activé, le gestionnaire affecte la ligne CS d'un circuit à la fois, qui peut être une mémoire, ou un demux si les circuits de mémoire ont moins de lignes d'adresse que le processeur. Deux ou quatre fois plus de circuits peuvent observer ou affecter le bus de données.

— Je le répète en conclusion, déterminer quel circuit communique sur le bus, c'est la définition de l'adressage. Le contrôle détermine le type de communication (lecture ou écriture, unique ou blocs à suivre). PolBr (discuter) 13 mai 2017 à 20:41 (CEST)

Dans le temps on n'avait qu'un seul bus pour tout faire ou presque; aujourd'hui ont a différents bus a différentes vitesses de transfert. Les CS permettent de déterminer qu'elle est la paire (émetteur/récepteur) qui est active sur un bus. Dans le cas de la mémoire il faut choisir le « bank » qui contient l'information au travers du CS. Le bus d’adresse est réservé aux mémoires (vive ou morte) ... Pano38 (discuter) 13 mai 2017 à 23:22 (CEST)

Nous sommes bien d'accord. Les lignes CS font partie de l'adressage. Du point de vue de la rédaction de l'article, je crois que le fait qu'une machine ait plusieurs bus est indifférent ; on traite le bus en général.

L'évolution des machines a rendu leur structure plus complexe. L'adressage implique plus que de simples conducteurs reliant une quantité de composants. Quand on considère que les demux qui déterminent le niveau des broches CS font partie du bus d'adresse, on débouche sur la définition de bus informatique, par opposition à la définition de bus en électricité/électronique. Mais en dehors de cette fonction d'adressage, la ligne CS n'a aucune utilité.

Si la mention de la broche CS (qui fait partie du bus au sens informatique, mais pas au sens électronique, puisqu'il y a une liaison point à point du décodeur à la broche CS) apporte de la confusion, ne vaudrait-il pas mieux le considérer comme hors-sujet ? PolBr (discuter) 14 mai 2017 à 09:26 (CEST)

J'ai du mal m'exprimer; la commande CS n'est pas une adresse mais la selection d'un ou plusieurs chips au mème moment, cela n'a rien à voir avec une adresse, c'est plutot une commande/un controle ... Pano38 (discuter) 14 mai 2017 à 09:34 (CEST)

Un dispositif qui détermine quel(s) composants doivent avoir l'usage du bus de données est un dispositif d'adressage. PolBr (discuter) 14 mai 2017 à 09:43 (CEST)

Pouvez vous sourcer cette assertion? .... Pano38 (discuter) 14 mai 2017 à 11:12 (CEST)

Cette assertion est la définition de l'adressage (Fleutry 1991:14-15) : sélection du composant destinataire ou à l'origine d'une information. Dans le même ouvrage, chip select, p. 116 précise qu'il n'y a que des lignes de chip selection, pas de bus. Michel Fleutry, Dictionnaire encyclopédique d'électronique anglais-français, La maison du dictionnaire, 1991 (ISBN 2-85608-043-X).

Nous n'avons pas la mème définition de l'adressage; il n'y a pas d'adresse de chip select! Le chip select est un fil! Un fil n'est pas une adresse ... Pano38 (discuter) 14 mai 2017 à 18:56 (CEST)

Nous sommes en fait parfaitement d'accord. Soit on considère la définition électronique du bus, et la ligne CS n'est ni un bus d'adresse, ni un bus de contrôle, c'est une ligne de point à point, et est donc ici hors-sujet. Soit on considère la définition informatique du bus, c'est-à-dire la définition fonctionnelle, et les lignes CS font partie du sous-ensemble adressage du bus informatique, et si c'est la définition que vous adopter, c'est dans la section adresses qu'elles doivent figurer. PolBr (discuter) 14 mai 2017 à 19:16 (CEST)

le signal CS est un simple fil et les signaux qui y transitent ne sont pas dignes d'un « bus informatique » (mème si on pourrait dire que c'est un « bus électrique »). Effectivement ce n'est pas non plus un « bus de control », mais j'ai toujours eu des probleme avec cette terminologie ... Pano38 (discuter) 15 mai 2017 à 07:21 (CEST)

En aucun cas le signal CS ne transite sur un bus électrique (ensemble de conducteurs reliant plusieurs composants). Il s'agit d'une liaison électronique point-à-point. Il n'y a aucune notion de « dignité » dans celle de bus informatique. Il s'agit de fonctions. Le transfert d'information par une voie commune suppose (1) la définition des composants concernés (adresse) (2) la nature de la communication (contrôle) (3) la donnée. Les moyens par lesquelles ces fonctions sont réalisées est indifférent du point de vue fonctionnel. Le bus USB est constitué d'un gros paquet de circuits électroniques, de logiciel, et exclusivement des liaisons électrique point-à-point, par lesquelles transitent les trois fonctions du bus. De même, du point de vue fonctionnel, les liaisons point-à-point CS et les composants qui en déterminent le niveau font partie de la fonction adresse d'un bus. PolBr (discuter) 15 mai 2017 à 09:08 (CEST)

aucune notion d'adressage dans la commande CS; c'est un bout de fil commandé par qui en a besoin que ce soit pour accéder à un bus ou pour toute autre fonction ... Pano38 (discuter) 15 mai 2017 à 11:33 (CEST)

Pour qu'une mémoire soit sélectionnée, il faut et il suffit que toutes les broches d'adresse soit au niveau correspondant et le CS actif. C'est comme un MSB d'adresse. Mettons que la mémoire ait 0xFFFF adresses. Chip select à 1, on appelle la mémoire 0x1NNNN. Cette mémoire n'existe pas dans le circuit, elle ne s'active pas. Chip select à 0, la mémoire existe, elle s'active. PolBr (discuter) 15 mai 2017 à 14:42 (CEST)

le bus mémoire est un cas particulier qu'il ne faut pas généraliser! Il permet d'adresser aussi bien la mémoire vide que le BIOS. Les autres bus sont essentiellement dédiés aux périphériques plus au moins rapide... Pano38 (discuter) 15 mai 2017 à 15:03 (CEST)

Si le composant n'est pas une mémoire, ou s'il n'a qu'une adressse, c'est exactement la même chose. La ligne CS est le moyen de signaler quel élément dispose du bus de données. La ou les lignes de contrôle lui signalent quoi en faire. PolBr (discuter) 15 mai 2017 à 15:14 (CEST)

pour faire simple, oui!