câble, blindage et vitesse

Attention en général les câbles sont très bons, ce sont les connecteurs qui font chuter la vitesse si jamais ils sont mal conçus ou mal câblés. Surtout sur 10 cm !

Les câbles plats sont en moins bons (surface de captation des parasites plus importante) surtout s'ils ne sont pas blindés.

Reply to
Philippe RAI
Loading thread data ...

Le 26/07/2013 14:04, Albert ARIBAUD a écrit :

Oui typiquement un PC en veille coupe en principe je pense le 5V. Mais ce n' est pas un soucis. Ce serait juste un secours pour prendre en relais une pile morte.

Reply to
pes

Le 26/07/2013 14:54, Jean-Christophe a écrit :

Oui en veille le PC peut couper le 5V. Pas de soucis en conditions "normales" il me semble aussi que le PC ne devrait pas couper VBUS, une fois la connection établie si on est pas en veille.

La carte est alimentée par une pile, on vient communiquer avec l' USB et le 5V prend le relais sur la pile seulement si présent. En outre on peut agir sur un actionneur : les 30OmA.

Reply to
pes

Oui, c'est la config par défaut, mais ca se paramètre quelque part dans le système du côté de la gestion des périphériques

Exemple :

formatting link

Accessoirement, note qu'un périphérique peut aussi sortir le PC du mode veille. ( suivant l'application, ca peut servir ... )

Reply to
Jean-Christophe

Salut,

pes a écrit :

Pour info, dans mon vieux PC assemblé en 2002 la liaison entre les ports USB 1.1 de la carte mère et les connecteurs de façade du boîtier est faite avec des câbles en nappe plats (non blindés ni torsadés) de longueur largement supérieure à 10 cm, et je n'ai jamais eu de problème avec mes périphériques en full speed (clés de stockage, lecteur GPS).

Reply to
Pascal Hambourg

Albert ARIBAUD a écrit :

"Où le périphérique (device) indique à l'hôte", en fait. Je ne crois pas avoir lu de mention du terme "slave" dans la spécification USB.

C'est la théorie. En pratique, j'ai démonté deux hubs auto-alimentés, et surprise (pas tant que ça), les sorties d'alimentation des ports étaient directement câblées à l'entrée d'alimentation du hub, sans aucune possibilité de contrôle ni commutation, à part peut-être un fusible.

Reply to
Pascal Hambourg

Le 27/07/2013 10:11, Pascal Hambourg a écrit :

Exact.

Comme dit le fil auquel j'ai renvoyé, ce n'est pas parce qu'on est tombé sur un matériel qui s'essuie les pieds sur la théorie que tous les matériels vont le faire. Le mieux est d'appliquer Postel, et quand on conçoit un périphérique non-hôte :) de se conformer au standard et négocier la conso, ce qui permet de fonctionner avec un hôte strict comme avec un hôte laxiste.

Amicalement,

--
Albert.
Reply to
Albert ARIBAUD

Imaginons une carte à uC reliée (et alimentée) sur un port USB d'un PC; et qu'aprés un start-up réussi la carte et le soft qui tourne sur le PC soient en communication continuelle via le port USB. On se situe en-dehors des situations suivantes :

- Une commande issue du soft ferme la connection USB

- On ferme le soft PC qui discute avec la carte

- Le PC passe en mode veille et coupe le port USB

- La carte créée une surconsommation de courant sur VUSB

- Le PC est hors secteur et sa batterie tombe en rade

- Coupure secteur sur le PC sans batterie

- On éteint le PC

Si le PC cesse d'alimenter VUSB, qui chute alors à zéro: la carte est subitement HS, son activité cesse, on perd des données, et en dehors de la com carte/PC, si la carte gère en autonôme des E/S physiques, celles-ci ne sont plus rafraîchies.

Même pour des applications non-critiques ceci est loin d'être trivial et nécéssite d'expliciter dans le détail les conditions ( autres que celles citées ci-dessus ) qui, sans qu'on l'ait explicitement demandé, amèneraient un PC à cesser arbitrairement d'alimenter VUSB.

Quelles sont ces conditions ?

Reply to
Jean-Christophe

Le 27/07/2013 12:14, Jean-Christophe a écrit :

J'avoue que je ne comprends pas pourquoi tu demandes comment VBUS tomberait dans un un exemple qui pose en hypothèses de départ qu'il est dans les conditions où VBUS ne peut pas tomber.

Mais surtout, je n'ai *jamais* écrit que VBUS disparaîtrait

*arbitrairement*. Ce que j'ai écrit (et c'est dommage que tu ne l'aies pas gardé en citation), c'est précisément que si on n'est *pas* dans les conditions qui garantissent le maintien de VBUS, on n'a pas l'assurance que VBUS demeure actif ; et que le demandeur devrait donc s'assurer soit de rester dans les conditions du maintien de VBUS, soit utiliser un 5V autre que VBUS.

Quant au détail de ces conditions, il se trouve dans la norme ; mais en résumé, il faut que le périphérique alimenté par VBUS :

- respecte la norme USB de façon générale ;

- négocie en particulier de ne pas être mis en veille s'il le peut ;

- s'il compte consommer plus de 100 mA, le négocie avec l'hôte.

Je ne sais pas dire si un périphérique peut imposer à l'hôte de ne pas être mis en veille ; mais si effectivement le maintien hors veille peut lui être refusé, alors il n'y a pas de garantie absolue que VBUS reste actif et ce, quoi qu'on fasse, et on doit assurer ce maintien par des moyens extérieurs au périphérique.

Amicalement,

--
Albert.
Reply to
Albert ARIBAUD

| "Albert ARIBAUD" | on n'est pas 100% à l'abri d'une chute du VUSB à zéro.

J'ai cru que tu citerais des exemples de cas *non triviaux* où VBUS peut tomber; là tu précises qu'en dehors des cas cités VBUS ne peut pas tomber, c'est rassurant. Tu as souligné que VBUS peut tomber à zéro mais sans en préciser la raison : personnellement je n'ai jamais constaté cela, d'où mon insistance à demander pourquoi VBUS tomberait - en dehors des cas *triviaux* cités. (ex : PC non alimenté, on sait bien que VBUS=0)

D'aprés ta présente réponse, c'est en dehors des cas où VBUS est maintenu que l'on a plus l'assurance que VBUS demeure actif :o)

Reply to
Jean-Christophe

Le 27/07/2013 18:46, Jean-Christophe a écrit :

Je suppose que cette citation répond au fait que j'ai nié avoir écrit que que VBUS disparaîtrait arbitrairement. Elle est cependant tronquée et privée de son contexte, ce qui en altère la lecture. Je le reproduis au complet et en contexte :

Ainsi complétée et remise en contexte, on comprend que ma phrase ne signifie pas que VBUS disparaîtrait arbitrairement, mais que dans la norme USB, les conditions où il peut disparaître ne sont pas limitées au seul cas de l'OTG.

Je n'ai jamais dit autre chose -- mais je voudrais tempérer le caractère "trivial" des cas où VBUS tombe ; à moins de nager comme un poisson dans la norme USB, savoir exactement par quels processus VBUS peut tomber ne me paraît pas trivial.

Je n'avais pas cité ce cas-là :) mais les cas prévus dans la norme qui

-- pour moi -- n'ont rien de trivial.

Oui, la question étant : à quel point a-t-on le contrôle de l'hôte USB pour s'assurer qu'il maintiendra VBUS. Si on a ce contrôle, très bien. Si on ne l'a pas, ou si on n'a pas même connaissance du fait qu'il pourrait couper VBUS, c'est moins bien.

Amicalement,

--
Albert.
Reply to
Albert ARIBAUD

"Albert ARIBAUD" :

Non, car c'est bien moi qui ai parlé d'arbitraire, en opposition à ce que je considère trivial et dont j'ai donné une liste non exhaustive (qui a disparue) ( coupure d'alim, surintensité de consommation du périph, veille, fermeture du soft PC, demande explicite de mise hors-circuit, etc ) Je les qualifie de triviaux, car là, on sait bien pourquoi VBUS tombe, et qualifie d'arbitraire les autres cas tant qu'ils n'ont pas été clairement explicités ... mais suis tout à fait prêt à reconsidérer cette terminologie.

Oui, c'était trés clair, et c'est pourquoi j'ai proposé un cas hors-OTG pour avoir des précisions sur les cas de disparition - non triviaux - de VBUS.

Ok, nous sommes donc d'accord :o)

Certes, mais - du moins à mon sens - les cas que j'ai cité le sont : coupure d'alim, surintensité de consommation du périph, veille, fermeture du soft PC, demande explicite de mise hors-circuit, etc,

C'est moi qui l'ai cité. (ce cas-là, entre autres)

D'accord, alors : quels sont ces cas, qui ne sont pas déjà dans la liste que j'ai cité ? ( c'est toujours là ma question initiale )

D'où ma question.

Amicalement aussi.

Reply to
Jean-Christophe

Albert ARIBAUD a écrit :

Ils ne font qu'appliquer Postel eux aussi, en permettant à un périphérique laxiste de fonctionner.

Reply to
Pascal Hambourg

Le 27/07/2013 19:56, Jean-Christophe a écrit :

(je ne laisse que le point demeurant en question au final)

Je les avais indiqué dès le départ, en énumérant :) tous ceux que je connaissais, faute de savoir lesquels seraient (in)applicables au cas de ce fil : modes de veille (low power) prévus par la norme USB elle-même et OTG, qui prévoit, même sans veille, qu'on puisse couper VBUS entre deux sessions.

Tu as évoqué les modes de veille dans ta liste par "Le PC passe en mode veille et coupe le port USB " -- même si on peut ne pas avoir un mode de veille tout-ou-rien, et le port USB peut être coupé sans que le PC ne passe visiblement "en veille".

L'OTG, tu ne l'as pas évoqué, et a priori on n'est pas concerné ici puisque l'hôte est un PC. Mais au moment où j'avais fait cette réponse, pes n'avait pas encore indiqué quel type d'hôte il utiliserait.

Amicalement,

--
Albert.
Reply to
Albert ARIBAUD

Le 27/07/2013 21:17, Pascal Hambourg a écrit :

Oui, l'hôte qui fournit plus que 100 mA avant négo applique Postel, afin de fonctionner même avec un périphérique laxiste ; mais ce n'est pas une invitation aux périphériques à être laxistes ! Postel demande précisément, entres autres, de ne pas supposer qu'en face on applique Postel. Autrement dit, ces hôtes supportent un périphérique laxiste, mais tous les hôtes ne le font pas forcément, donc un périphérique a intérêt à être strict plutôt que laxiste.

Amicalement,

--
Albert.
Reply to
Albert ARIBAUD

Quelles sont les conditions de déclenchement de ce dernier cas que tu évoques là ?

J'ai posé un cas non-OTG dépassant le cadre initial de ce fil pour que tu me dises quels sont ces cas que tu évoques qui pourraient amener un PC à couper le VUSB d'un périphérique - hors des cas que j'ai déjà cité - et tu as confirmé qu'il n'y en avait pas, n'est-ce pas ?

J'ai explicitement proposé un cas non-OTG.

Et au-delà du cadre de la question de 'pes', pour répondre au cas que j'ai proposé ?

Cordialement.

Reply to
Jean-Christophe

Le 27/07/2013 22:18, Jean-Christophe a écrit :

Celles de la norme USB, qui l'impose pas que le système hôte passen en veille en même temps que le port USB.

Je ne peux pas confirmer qu'il n'y a pas d'autres cas, parce que je n'ai pas la connaissance extensive de toutes les implantations de tous les modes de veille de toutes les configurations de tous les OS susceptibles de fonctionner sur tous les matériels de type PC.

Comme j'ai déjà dit, tu sembles avoir créé un cas où par construction VBUS ne pourrait pas tomber. Même après plusieurs échanges, je ne vois toujours pas l'intérêt de poser la question quand les conditions imposées par l'exemple fournissent la réponse d'avance.

Accessoirement, j'avoue ne pas comprendre ce que tu cherches exactement dans cette discussion. Est-elle bien utile à poursuivre et prolonger ainsi, pour ce qui me semble relever davantage d'une divergence de lecture que d'un point technique réel ? Il vaudrait peut-être mieux la porter en privé et ne revenir ici que pour en donner la conclusion. Non ?

Amicalement,

--
Albert.
Reply to
Albert ARIBAUD

Le 27/07/2013 22:18, Jean-Christophe a écrit :

Celles de la norme USB, qui n'impose pas que le système hôte passen en veille en même temps que le port USB.

Je ne peux pas confirmer qu'il n'y a pas d'autres cas, parce que je n'ai pas la connaissance extensive de toutes les implantations de tous les modes de veille de toutes les configurations de tous les OS susceptibles de fonctionner sur tous les matériels de type PC.

Comme j'ai déjà dit, tu sembles avoir créé un cas où par construction VBUS ne pourrait pas tomber. Même après plusieurs échanges, je ne vois toujours pas l'intérêt de poser la question quand les conditions imposées par l'exemple fournissent la réponse d'avance.

Accessoirement, j'avoue ne pas comprendre ce que tu cherches exactement dans cette discussion. Est-elle bien utile à poursuivre et prolonger ainsi, pour ce qui me semble relever davantage d'une divergence de lecture que d'un point technique réel ? Il vaudrait peut-être mieux la porter en privé et ne revenir ici que pour en donner la conclusion. Non ?

Amicalement,

--
Albert.
Reply to
Albert ARIBAUD

Ayant réalisé des cartes avec port USB alimentées via le port du PC où elles sont connectées, j'apprends que VUSB peut tomber ( pour une raison que j'ignore si ce n'est pas une de celles que j'ai cité ) et bien que n'ayant jamais constaté une telle chose, ca m'intéresse beaucoup de savoir comment, pour ne pas me retrouver dans une situation où une carte devient HS sans que je sache pourquoi. Afin d'éviter une suite d'échanges sur les cas triviaux (sic) j'ai commencé par les énumérer afin de passer directement aux autres cas (pour moi toujours mystérieux) où VUSB tomberait.

Tu dis que c'est en dehors des cas où VUSB est maintenu que l'on a plus l'assurance que VUSB demeure actif ; cela me semble être une tautologie, mais je peux me tromper. D'un côté, qu'en-dehors des cas que j'ai cité VUSB ne tomberait pas, d'un autre côté, laisses entendre que d'autres cas existent ; cela me semble contradictoire, sauf erreur de ma part. Au final il faut s'en réfèrer à la spécif USB ... que j'avoue sans honte ne pas avoir épluché en totalité ( et n'ai pas l'intention de m'y coller ) mais espérais encore que tu cites un exemple de ce que tu avançais.

Au point où nous en sommes, on sait que les seuls cas où un PC peut descendre à zéro le VUSB d'un port USB sont les cas déjà listés précédemment, puisque jusqu'ici aucun autre cas n'a pu être clairement recensé.

Le grand avantage d'un échange ouvert ici sur fse est que d'autres intervenants pourraient apporter de l'eau à un moulin qui semble bien à sec ... ( bien qu'il est - paraît-il - des terres brûlées donnant plus de blé qu'un meilleur avril ... )

Cordialement.

PS : Serais-tu le traducteur du livre 'Hal Spacejock' ?

Reply to
Jean-Christophe

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.