câble, blindage et vitesse - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From French to

Threaded View
Re: câble, blindage et vitesse
Quoted text here. Click to load it

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 :
http://cjoint.com/data/0GArUgeNyie_0h.jpg

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

  


Re: câble, blindage et vitesse
Quoted text here. Click to load it

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 ?
  


Re: câble, blindage et vitesse
Le 27/07/2013 12:14, Jean-Christophe a écrit :
Quoted text here. Click to load it

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.

Re: câble, blindage et vitesse
|  "Albert ARIBAUD"
|  on n'est pas 100% à l'abri d'une chute du VUSB à zéro.

Quoted text here. Click to load it


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)




Quoted text here. Click to load it
  


Re: câble, blindage et vitesse
Le 27/07/2013 18:46, Jean-Christophe a écrit :
Quoted text here. Click to load it

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 :

 > |  "Albert ARIBAUD"
 > |  Ainsi, un bidule esclave auto-alimenté sait par VBUS si son port
 > |  maître est actif ou en veille ; et en OTG, [...]
...
 > |  "Jean-Christophe"
 > |  [l'USB que je considère] n'est donc pas de l'OTG.
...
 > |  "Albert ARIBAUD"
 > |  *Même sans OTG, on n'est pas 100% à l'abri d'une chute du VUSB
 > |  à zéro.

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Je n'avais pas cité ce cas-là :) mais les cas prévus dans la norme qui  
-- pour moi -- n'ont rien de trivial.

Quoted text here. Click to load it

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.

Re: câble, blindage et vitesse
"Albert ARIBAUD" :
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

Ok, nous sommes donc d'accord  :o)


Quoted text here. Click to load it

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,


Quoted text here. Click to load it

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


Quoted text here. Click to load it

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 )


Quoted text here. Click to load it

D'où ma question.


Quoted text here. Click to load it

Amicalement aussi.

  


Re: câble, blindage et vitesse
Le 27/07/2013 19:56, Jean-Christophe a écrit :

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Amicalement,
--  
Albert.

Re: câble, blindage et vitesse
Quoted text here. Click to load it


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 ?


Quoted text here. Click to load it

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


Quoted text here. Click to load it

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


Quoted text here. Click to load it

Cordialement.
  


Re: câble, blindage et vitesse
Le 27/07/2013 22:18, Jean-Christophe a écrit :

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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 ?

Quoted text here. Click to load it

Amicalement,
--  
Albert.

Re: câble, blindage et vitesse
Le 27/07/2013 22:18, Jean-Christophe a écrit :

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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 ?

Quoted text here. Click to load it

Amicalement,
--  
Albert.

Re: câble, blindage et vitesse
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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é.


Quoted text here. Click to load it

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' ?
  


Re: câble, blindage et vitesse
Le 28/07/2013 12:39, Jean-Christophe a écrit :

Quoted text here. Click to load it

Je comprends mieux.

Quoted text here. Click to load it

C'est une tautologie en effet, mais seulement si le lecteur connaît  
parfaitement tous les cas où VBUS est maintenu ou pas. Sinon, c'est une  
incitation au lecteur à vérifier dans quels cas exactement VBUS est  
maintenu. Mon objectif était d'ailleurs que "pes" s'assure de ne pas  
être dans le cas où son système dépendrait de la permanence VBUS sans  
dans le même temps assurer celle-ci.

Quoted text here. Click to load it

Pas sûr de bien suivre cette phrase :) mais mon intention n'était pas de  
"laisser entendre" mais de rappeler. En l'occurrence, ta liste  
d'hypothèses n'évoquait pas l'OTG, qui est -- si je ne me trompe -- le  
seul cas que j'ai évoqué comme n'y étant pas cité.

Quoted text here. Click to load it

Ben, j'en ai avancé deux, les deux que j'ai toujours cités, et les deux  
seuls que je connaisse dans la norme où VBUS puisse tomber.

Quoted text here. Click to load it

Soit.


Pas de souci pour moi. :)

Quoted text here. Click to load it

Oui -- mais pour le coup, *ça*, c'est sacrément... HS... :)

Amicalement,
--  
Albert.

Re: câble, blindage et vitesse
Quoted text here. Click to load it

Ok.



Mea maxima culpa, elle aurait dû
commencer par : "Tu dis que ..."


Quoted text here. Click to load it

Oui, cette liste se référait au cas que j'ai proposé
(carte/PC) qui par définition n'est pas OTG   :o)


Quoted text here. Click to load it

Des cas que, rigoureusement, on est censé prendre en
compte quand on conçoit une carte alimentée via port USB ;
par suite - et à mon sens - c'est inclus dans les cas 'triviaux'.
( toujours dans une config carte/PC )


Quoted text here. Click to load it

Je m'attendais à ce que tu annonces une condition du style :
"Toutes les X secondes le PC envoie au périphérique la trame Y"
"et déconnecte VUSB si le périphérique ne répond pas, ou pas bien."
ou quoi que ce soit d'autre du même genre ... d'où mon insistance.


Quoted text here. Click to load it

Sauf que ca n'a pas l'air d'accrocher grand-monde.
Les vacances d'été, sans doute ...


Quoted text here. Click to load it

Certes, mais bigre, ce doit être sacrément passionnant ...
Alors bonne continuation, Mr Albert !
  


Re: câble, blindage et vitesse
(pour faire court)

Le 28/07/2013 17:11, Jean-Christophe a écrit :

Quoted text here. Click to load it

Tout est dans le "rigoureusement". J'aurais pu considérer que "pes"  
connaissait la norme USB et l'appliquait aussi rigoureusement que tu le  
décris ici ; mais je sais -- d'expérience directe -- qu'on n'est pas  
toujours informé ni rigoureux, et c'est pour un rappel à cette rigueur  
que j'ai fait valoir le risque sur VBUS.

Quoted text here. Click to load it

Le problème est que la norme ne décrit pas ce genre de chose. Ainsi,  
concernant les cas OTG -- je n'en parle que parce que je les ai revus  
récemment, donc en ai un bon souvenir -- la norme dit que le "devace A"  
*peut* couper VBUS entre deux sessions, mais ne met aucune condition  
temporelle sur les durées des sessions ou du temps qui les sépare.

Quoted text here. Click to load it

Ou le fait qu'une discussion sur la norme USB ne soit pas vraiment en  
thème sur fse, ou plus exactement, soit plus à sa place ailleurs ?

Quoted text here. Click to load it

De même !

Amicalement,
--  
Albert.

Re: câble, blindage et vitesse
(pour faire court)

Le 28/07/2013 17:11, Jean-Christophe a écrit :

Quoted text here. Click to load it

Tout est dans le "rigoureusement". J'aurais pu considérer que "pes"  
connaissait la norme USB et l'appliquait aussi rigoureusement que tu le  
décris ici ; mais je sais -- d'expérience directe -- qu'on n'est pas  
toujours informé ni rigoureux, et c'est pour un rappel à cette rigueur  
que j'ai fait valoir le risque sur VBUS.

Quoted text here. Click to load it

Le problème est que la norme ne décrit pas ce genre de chose. Ainsi,  
concernant les cas OTG -- je n'en parle que parce que je les ai revus  
récemment, donc en ai un bon souvenir -- la norme dit que le "device A"  
*peut* couper VBUS entre deux sessions, mais ne met aucune condition  
temporelle sur les durées des sessions ou du temps qui les sépare.

Quoted text here. Click to load it

Ou le fait qu'une discussion sur la norme USB ne soit pas vraiment en  
thème sur fse, ou plus exactement, soit plus à sa place ailleurs ?

Quoted text here. Click to load it

De même !

Amicalement,
--  
Albert.

Re: câble, blindage et vitesse
Quoted text here. Click to load it


300 mA c'est OK avec VUSB, et là ca vaut
le coup de bien séparer les fils de l'USB d'avec
les fils de puissance, avec blindage pour D+/D-

Note que lors de la connection, le protocole USB
prévoit l'échange de données concernant l'hôte,
entre autres un champ où l'hôte indique au maître
combien de mA il a besoin sur sa ligne d'alimentation.

J'ai réalisé quelques cartes à uC avec port USB
( vers un PC, ce n'est donc pas du OTG )
et j'utilise évidemment VUSB pour alimenter cette carte
( courant crête consommé autour de 450 mA )
le VUSB alimentant aussi d'autres chips sur la même carte,
( entre autres un MAX202 pour une sortie RS232 )
et tout ceci marche trés correctement : fiche USB plug in/out
à froid et à chaud et jamais aucun problème avec VUSB.

Par exemple :
http://cjoint.com/data/0GAmOfmkeXe_0.jpg

HTH
  


Re: câble, blindage et vitesse
Le 26/07/2013 12:47, Jean-Christophe a écrit :
Quoted text here. Click to load it

("ou l'esclave indique à l'hôte", en fait)

Juste une remarque complémentaire : tant que cette négo n'a as eu lieu,  
l'esclave doit consommer au plus 100 mA, et ne peut consommer davantage  
qu'une fois autorisé par l'hôte (qui peut refuser, et qui peut couper le  
port si surconsommation) -- voir par exemple :

<http://forums.adafruit.com/viewtopic.php?f25%&t16%108

Amicalement,
--  
Albert.

Re: câble, blindage et vitesse
Albert ARIBAUD a écrit :
Quoted text here. Click to load it

"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.

Quoted text here. Click to load it

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.

Re: câble, blindage et vitesse
Le 27/07/2013 10:11, Pascal Hambourg a écrit :
Quoted text here. Click to load it

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.

Re: câble, blindage et vitesse
Albert ARIBAUD a écrit :
Quoted text here. Click to load it

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

Quoted text here. Click to load it

Site Timeline