Discussion :

[Iradrille]

Hello,

Je cherche à utiliser une souris PS/2; mais niveau branchement ça me dépasse.

Je suis tombé sur ça :

Figure 1: General open-collector interface. Data and Clock are read on the microcontroller's pins A and B, respectively. Both lines are normally held at +5V, but can be pulled to ground by asserting logic "1" on C and D. As a result, Data equals D, inverted, and Clock equals C, inverted.

source.

Ça me semble à peu près logique, à part les NOT.

J'ai l'impression qu'on a :
A: data_in
B: clk_in
C: NOT clk_out
D: NOT data_out
(Donc éventuellement les NOT seraient à mettre sur les pin C et D, et pas A et B).

Autre problème, les périphériques PS/2 veulent du 5V, mais je suis limité à du 3.3V.

Les diodes "standard" réduisent la tension de 0.7V, si j'en met 3 je suis tranquille ? Je peux mettre une résistance à la place ? Quelle loi me permet de savoir sa valeur ?

(Ne pas faire gaffe aux références de composants).

[Auteur]

Bonsoir,

tes transistors agissent comme des interrupteurs :
- Si tu as C=1 ton transistor est passant et son émetteur se retrouve à la masse. Enfin presque : il y aura quand même une petite ddp entre l'émetteur et le collecteur. Donc si C=1 ce cas clock=0 (niveau logique).
- Même chose pour Data : si D = 1, data = 0 (niveau logique).

Pour les diodes, j'avoue je ne sais pas trop.
J'aurais plutôt été tenté par un pont diviseur avec un potar, le point milieu sur tes entrées et fixer le niveau à 3,3V. Pour sa valeur, une résistance assez faible, en tout cas négligeable devant les 10k pour limiter son impact.

[Vincent PETIT]

Salut,
Pour le premier schéma.... je ne vois aucun intérêt de faire ça a part si on veut un ON/OFF des signaux Clock et Data (je n'y vois aucune utilité)

On dirait que la personne qui a fait ce schéma pense peut être que C et D permettent d'inverser (complémenter à 1) Data et Clock ? Mais la réponse est serait non

Visiblement Data et Clock sont des sorties de types collecteurs ouverts (sous entendu une sortie de type transistor avec son collecteur ouvert, autrement dit en l'air).


Comme tu le sais, il est impossible de saturer un transistor bipolaire si le collecteur est en l'air, donc sans résistance (ou courant) sur le collecteur puisque la formule de saturation est :
Courant Base _minimum >= Courant Collecteur_maximum / Hfe _minimum
Hfe étant une donnée de la datasheet.

Donc pour qu'un composant électronique de type sortie à collecteur ouvert fonctionne bien, il lui faut une résistance de collecteur (la fameuse résistance de pull up).

La résistance de tirage (pull up) est reliée à un potentiel qui peut être tout à fait différent de +5V puisque la formule de saturation d'un transistor bipolaire ne dépend pas du tout de la tension. Dans le schéma que tu donnes, celui tout en haut, la résistance de pull up est à +5V car le micro-contrôleur est probablement alimenté en +5V aussi. C'est pour une question de compatibilité de tension.

Toi, si ton contrôleur (FPGA/Micro-contrôleur/...) est alimenté en +3.3V :
tu alimentes ta souris avec du +5V pour l'électronique interne puisse fonctionner correctement.
tu mets une simple résistance de pull up alimentée en +3.3V sur DATA et une autre sur CLOCK et le tour est joué.
inutile de t'encombrer avec Q1 et Q2 sauf si tu as une raison particulière (si c'est le cas alors je veux bien savoir pourquoi)

ps1 : attention, cette manière de faire (souris alimenté en +5V et ses sorties collecteurs ouverts avec des résistances de pull up vers +3.3V) fonctionne bien car on est en monodirectionnel. Si on avait été en bidirectionnel, comme I2C par exemple, et qu'on aurait eu besoin d'écrire des données dans la souris alors il aurait fallu regarder d'autres caractéristiques et sûrement faire autrement

ps2 : pour les 3 diodes 1N4148 effectivement cela aurait abaissé la tension à 3V environ c'était un bonne idée

A+
Tiens nous au courant (sans jeu de mot)

[Auteur]

je ne vois aucun intérêt de faire ça a part si on veut un ON/OFF des signaux Clock et Data (je n'y vois aucune utilité)

Sans doute un feedback pour ajuster les niveaux ou le cadencement de l'horloge ?

[Iradrille]

Merci pour ces précision.

Toi, si ton contrôleur (FPGA/Micro-contrôleur/...) est alimenté en +3.3V :
tu alimentes ta souris avec du +5V pour l'électronique interne puisse fonctionner correctement.
tu mets une simple résistance de pull up alimentée en +3.3V sur DATA et une autre sur CLOCK et le tour est joué.
inutile de t'encombrer avec Q1 et Q2 sauf si tu as une raison particulière (si c'est le cas alors je veux bien savoir pourquoi)

ps1 : attention, cette manière de faire (souris alimenté en +5V et ses sorties collecteurs ouverts avec des résistances de pull up vers +3.3V) fonctionne bien car on est en monodirectionnel. Si on avait été en bidirectionnel, comme I2C par exemple, et qu'on aurait eu besoin d'écrire des données dans la souris alors il aurait fallu regarder d'autres caractéristiques et sûrement faire autrement

C'est une connexion bidirectionnelle.

Il faut envoyer des données à la souris pour la configurer / activer le reporting après un reset.

The device always generates the clock signal. If the host wants to send data, it must first inhibit communication from the device by pulling Clock low. The host then pulls Data low and releases Clock. This is the "Request-to-Send" state and signals the device to start generating clock pulses.

Summary: Bus States
Data = high, Clock = high: Idle state.
Data = high, Clock = low: Communication Inhibited.
Data = low, Clock = high: Host Request-to-Send

C et D sont là pour mettre clk / data à la masse; puis D permet d'envoyer des données à la souris.

Vu que c'est une connexion bidirectionnelle, je suis obligé d'avoir C et D ?
Avec un uC qui accepte du 5V, j'aurais pu simplement avoir A et B que je règle en input / output au besoin ?

@Auteur, pour un pont diviseur, la résistance de 10k ne gène pas ? Il faudrait la prendre en compte ?

[Vincent PETIT]

@Auteur,
Peut être par contre étant donnée que c'est le micro-contrôleur qui génère l'horloge, elle est cadencée au souhait de la personne faisant le soft ?
Honnêtement je ne sais pas.

Je n'arrive pas à trouver la vraie doc de PS/2, ça m'énerve , par contre il y a quelque site bien fait
http://pcbheaven.com/wikipages/The_PS2_protocol/?p=0


Discussion intéressante (et le gars est bon)
http://electronics.stackexchange.com...to-3-3v-inputs
Si on regarde le schéma, on retrouve la pull up sur +3.3V alors que le périphérique est alimenté en +5V.
Il a mis une résistance de 1k pour limiter le courant au cas où le micro-contrôleur mettrait sa broche en sortie (clavier en sortie et micro en sortie = boom !!!)
Le condensateur est là protéger la broche d'entrée du micro-contrôleur mais attention un condo va arrondir les fronts surtout si on communique rapidement.

Pour les premiers essais, je ne mettrai ni la résistance de 1k ni le condo mais je m'assurerai que la broche du micro soit toujours en entrée.

Autre point, je ne savais pas mais on peut effectivement écrire dans le clavier, donc on est en bidirectionnel (c'est la remarque que je fais dans mon premier message). Il va falloir que tu fasse un essai, rassure toi tu ne vas rien cramer !
Si la souris / clavier est en logique TTL c'est gagné car quand tu enverra un +3.3V de ton contrôleur vers la souris, elle le verra comme un 1 logique.
Si la souris / clavier est en logique CMOS c'est fouti car quand tu enverra un +3.3V de ton contrôleur vers la souris, elle le verra comme un état logique indéterminé.

[julien terrier]

Slt,

j'apprends en mm tps et du coup j'ai trouvé ce resumé du protocole PS / 2:

In the years 1998 through 2003, the majority of personal computers had PS/2 ports for the mouse and keyboard.

The PS/2 port has 4 signals: (1) CLOCK; (2) DATA; (3) +5V; (4) GROUND.

The PS/2 port allows devices to send data to the host, and the host may send data to the devices. All parties on a PS/2 port (typically just a device and the host) must share the signals and must detect if another party is currently using the signals.

How can signals be shared? A signal (such as CLOCK or DATA) is usually "floating" high, meaning that the signal is connected to a positive voltage through a resistor with high resistance (e.g., 4 kilo-Ohms). Thus the signal is interpreted as a logical "high" by all listening parties. Any party can pull the line low (via TTL logic) when the party intends to send data. When a party finishes sending a packet, it lets go of the signals indefinitely, so they float high again.

To send data from a device (e.g., mouse or keyboard) to the personal computer (PC), you must send data in 11-bit packets, consisting of the following bits: (1) start bit ("0"); (2) 8 data bits (LSB first); (3) parity bit ("odd" parity); (4) stop bit ("1"). Note that "odd parity" is when the total number of "1" bits in the data bits and parity bit combined is an odd number.

Ensuite j'ai trouvé un schématic PS / 2:

=

Le tout est alimenté en 5V.

Donc si j'ai bien compris les sorties C et D servent a realiser cette opération ==> Any party can pull the line low (via TTL logic) when the party intends to send data. When a party finishes sending a packet, it lets go of the signals indefinitely, so they float high again.

J'ai trouvé ces infos dans un article ou le gars simule une souris Ps / 2 avec un basic stamp 2 .

[Iradrille]

Donc si j'ai bien compris les sorties C et D servent a realiser cette opération ==> Any party can pull the line low (via TTL logic) when the party intends to send data. When a party finishes sending a packet, it lets go of the signals indefinitely, so they float high again.

C'est ce que j'ai compris aussi.

Maintenant je comprend pas tout à cause des états "haute / basse impédance".

D'après Wikipédia...

Selon le vocabulaire et les notations normalisés par la Commission électrotechnique internationale (CEI), l'impédance d'un dipôle linéaire passif de bornes A et B est définie en régime sinusoïdal de courant et de tension comme le quotient du nombre complexe image du phaseur \underline U_{AB}, représentant la tension entre les bornes, par le nombre complexe image du phaseur \underline I représentant le courant électrique à travers le dipôle.

Façon compliqué de dire que impédance == résistance.

Du coup soit la tension est inférieure au seuil : on a un 0 logique.
Soit elle est supérieure : on a un 1 logique.

Et puis ya ces états haute / basse impédance.

Haute impédance : niveau 1 logique, mais personne n'a "écrit" '1' sur la ligne ? Comme ici, par défaut la tension sera proche de +5V à cause/grâce à la résistance de pull-up ?
Basse impédance : pareil, mais avec un niveau '0' logique ? Exemple premier schéma quand C ou D est à 1 ?

Donc on ne peut pas utiliser C / D pour écrire sur le bus ? Ils servent simplement à signaler que l'hôte veut communiquer. Et il faudra utiliser A / B pour envoyer des données au périphérique ?

@Vincent PETIT, je teste ça dans la semaine : j’attends le facteur qui doit m'apporter un fer à souder. J'ai tenté ma chance au briquet, mais ça chauffe que dalle :/

[Vincent PETIT]

Merci pour cette info Julien,
Moi aussi j'apprends en allant je n'ai jamais utilisé de périphérique PS/2 (mais je crois que ça va pas tarder car j'ai horreur de ne pas comprendre, la semaine prochaine je vais alimenter un souris PS/2 et regarder la tête des signaux à l'oscillo)
... autant je comprends que le fait de saturer les transistors via C et D vont forcer Data et Clock à 0 sans risque d'endommagement, là dessus je suis ok mais c'est l'intérêt de faire ça qui m'échappe ????


D'après le contrôleur que je vois sur ta photo et d'après sa datasheet :
http://pdf.datasheetarchive.com/data...319/428457.pdf

Le composant (donc la souris) peut être alimenté entre 2.5V et 5.5V donc avec du 3.3V ça doit fonctionner.
On a des entrées/sorties TTL et CMOS dans ce composant.

Y a des choses qui ne vont pas dans le premier schéma
- Pour les portes NON, je comprends car qui dit transistor (collecteur ouvert) dit forcément inversion des données (complément à 1) un transistor est un inverseur. Donc la porte NON permet de retrouver les données dans le bon sens.
- Par contre il y a un problème car comme vous l'avez tous remarqué et avant moi c'est bien un liaison bidirectionnelle donc la porte NON que je vois sur le schéma va poser un gros soucis lorsqu'on voudra écrire dans le périphérique puisque sa simple présence ne permet que de lire les DATA, à cause du sens de la porte.
- Pour CLOCK le problème est tout autre ! Et ce que je vais vérifier rapidement. Franchement, de vous à moi, ça m'étonnerait fortement que ce soit la souris ou le clavier qui génère le CLOCK car ceux sont des esclaves. J'ai tout le temps vu le maître générer le CLOCK (I2C, SPI, ...) je pense plutôt que c'est le PC ou le micro ou le FPGA qui génère le CLOCK. Si j'ai raison alors la porte NON du premier schéma est à l'envers.

Donc ce schéma ne permet pas d'écrire dans le périphérique PS/2 et je pense (mais je vais vérifier) que la porte NON sur CLOCK est à l'envers.....

@Iradrille,
Tu as pu faire un essai avec juste des pull up sur le +3.3V sur DATA et CLK et alimenter ta souris en +5V ?
Tu as pu faire un essai avec juste des pull up sur le +3.3V sur DATA et CLK et alimenter ta souris en +3.3V également ?

[Iradrille]

... autant je comprends que le fait de saturer les transistors via C et D vont forcer Data et Clock à 0 sans risque d'endommagement, là dessus je suis ok mais c'est l'intérêt de faire ça qui m'échappe ????

C'est pour initier un transfert hôte -> périphérique.

- Pour CLOCK le problème est tout autre ! Et ce que je vais vérifier rapidement. Franchement, de vous à moi, ça m'étonnerait fortement que ce soit la souris ou le clavier qui génère le CLOCK car ceux sont des esclaves. J'ai tout le temps vu le maître générer le CLOCK (I2C, SPI, ...) je pense plutôt que c'est le PC ou le micro ou le FPGA qui génère le CLOCK. Si j'ai raison alors la porte NON du premier schéma est à l'envers.

A peut près partout on peut lire que se sont les périphériques qui génèrent le clock, et seulement eux. Pas vérifié par contre. (ce qui pose le problème de la synchronisation, mais c'est un problème logiciel, on verra plus tard =)).

@Iradrille,
Tu as pu faire un essai avec juste des pull up sur le +3.3V sur DATA et CLK et alimenter ta souris en +5V ?
Tu as pu faire un essai avec juste des pull up sur le +3.3V sur DATA et CLK et alimenter ta souris en +3.3V également ?

Rien pour le moment.

[Vincent PETIT]

A peut près partout on peut lire que se sont les périphériques qui génèrent le clock, et seulement eux. Pas vérifié par contre. (ce qui pose le problème de la synchronisation, mais c'est un problème logiciel, on verra plus tard =)).

Ok, j'ai peut être tord en faisant l'analogie avec d'autre protocole. Je vérifie rapidement

[Auteur]

Façon compliqué de dire que impédance == résistance.

non. On parle d'impédance en régime petits signaux (sinus), qui est le "contraire" d'un régime avec une tension continue.
En petit signaux :
- résistance : son impédance Z est R qui est égale aussi à sa résistance.
- condensateur : son impédance Z est 1/(Cw)
- inductance : son impédance Z est Lw.

Haute impédance : niveau 1 logique, mais personne n'a "écrit" '1' sur la ligne ? Comme ici, par défaut la tension sera proche de +5V à cause/grâce à la résistance de pull-up ?

La haute impédance est un statut particulier d'un CI :
https://fr.wikipedia.org/wiki/Haute_imp%C3%A9dance

[Iradrille]

Tu as pu faire un essai avec juste des pull up sur le +3.3V sur DATA et CLK et alimenter ta souris en +5V ?

Ça semble marcher.
J'ai changé la souris par un clavier pour tester (pas besoin de lui demander d'activer le reporting; donc pas besoin de communication bidirectionnelle).

Lors du relâchement de la touche 'A'


Une horloge @ 100kHz est utilisée pour vérifier les valeurs de data / clk; donc à vu d'oeil mon clavier utilise une horloge de ~25kHz.

Appuyer sur 'A' doit générer 0x1C.
Relâcher 'A' doit générer : 0xF0 0x1C.

Ce que j'obtiens : 0 1010 1000 0 1
start : 0
message : 0x15 (ou 0xEA si il faut inverser les bits).
parité : 0 => 3 bits à 1, c'est un nombre impair donc parité == 0.
stop : 1

Reste à interpréter ça. Le message n'est pas celui attendu

edit : 0x15 == 'Q'; je pensais que les claviers azerty fonctionnaient en azerty sans avoir besoin d'interprétation software, mais on dirait pas (en tout cas pas pour celui là).

Tu as pu faire un essai avec juste des pull up sur le +3.3V sur DATA et CLK et alimenter ta souris en +3.3V également ?

Marche pas.

[Vincent PETIT]

Ok je confirme aussi que l'horloge vient bien du clavier (je viens d'essayer voir copie d'écran touche enfoncée)


Ici on est alimenté en +5V et la fréquence mesurée est de 12.8kHz environ.

Mon clavier fonctionne toujours très bien en +3.3V.
Pour la souris, j'en ai trouvé une vieille chez moi mais visiblement elle est morte....

Point important ! Je n'ai pas mis de résistance de pull up donc j'ai bien l'impression que la sortie CLK du clavier n'est pas du tout de type collecteur ouvert... bizarre !!!!
Demain je ferai un essai en CLK et DATA


Ce qu'on fera demain, c'est que tu me dira avec qu'elle touche tu veux travailler pour tes tests et moi j'essayerai de te donner une copie d'écran de mon oscillo et je m'arrangerai pour qu'on voit CLK et DATA afin que tu puisses comparer avec ce que toi tu lis avec ton FPGA.

[Iradrille]

Point important ! Je n'ai pas mis de résistance de pull up donc j'ai bien l'impression que la sortie CLK du clavier n'est pas du tout de type collecteur ouvert... bizarre !!!!
Demain je ferai un essai en CLK et DATA

Je viens de tester; j'observe la même chose sur clk et data. Du coup ce salopiaud de clavier doit balancer du +5V sur data / clk. Pas cool.

Et le clavier veut pas marcher en 3.3V chez moi.

Au passage j'ai aussi une horloge de ~12.5kHz (les 25kHz du post précédent c'est une erreur de calcul ).

[Vincent PETIT]

Oui et il faut éclaircir ça.
Tout à l'heure lorsque j'ai démonté mon clavier pour repérer le câblage, j'ai vu des diodes Zener 5.6V sur ClOCK et DATA mais elles servait probablement de protection en surtension (car elles vont clamper à 5.6V pour rien endommager)

Peut être que les pull up étaient dans le clavier, je n'ai pas regardé car c'était le câblage que je voulais voir !!!!

Bon, je regarde ça demain.

[Iradrille]

Du coup, c'est peut être la solution : http://www.armadeus.com/wiki/index.php?title=PS/2

[Iradrille]

J'ai testé avec le pont diviseur (4.7k / 10k). Mon voltmètre me dit qu'il ya 0V entre data et gnd (ou clk et gnd), mais il doit être à moitié mort.

Sinon, appuie et relâchement de entrée (celui du pavé numérique) :

J'ai "resserré" la timeline


Appuie : 0xe0 0x5a
Relâchement : 0xe0 0xf0 0x5a

0x5a : entrée
0xe0 : marqueur de touche spéciale

Relâchement de touche spéciale : 0xe0 0xf0 [code touche]
Donc tout marche bien.

Plus qu'à s'assurer que ça ne marche pas en +5V et à faire les communications hôte -> périphérique.

[Vincent PETIT]

J'ai testé avec le pont diviseur (4.7k / 10k). Mon voltmètre me dit qu'il ya 0V entre data et gnd (ou clk et gnd), mais il doit être à moitié mort.

Je test ce soir.
D'après ma copie d'écran d'oscillo, entre CLK et GND (sans toucher au clavier) tu dois avoir +3.3V.

Plus qu'à s'assurer que ça ne marche pas en +5V et à faire les communications hôte -> périphérique.

Par contre avec un pont diviseur, ça risque de ne pas fonctionner. Un pont diviseur c'est monodirectionnel, il divise la tension issue de DATA pour donner 3.3V mais en aucune façon il va régénérer le +3.3V que tu vas envoyer dans le pont en +5V.
De plus, si tu mets ton FPGA en sortie, celle ci va être en conflit avec +3.3V.

Il te faut de l'électronique en plus pour gérer ça (je pense comprendre pourquoi il y a les transistors sur le premier schéma) je te fais une réponse ce soir.
Il faut aussi que je regarde si c'est vraiment des sorties collecteurs ouverts sur PS/2

Je n'arrive pas a trouver de doc officielle, comment ça se fait ? Ça porte un autre nom et PS/2 serait une abréviation ou un abus de langage ?

[Iradrille]

Par contre avec un pont diviseur, ça risque de ne pas fonctionner. Un pont diviseur c'est monodirectionnel, il divise la tension issue de DATA pour donner 3.3V mais en aucune façon il va régénérer le +3.3V que tu vas envoyer dans le pont en +5V.

Je m'en doutais un peu, ça aurait été trop simple.

Je n'arrive pas a trouver de doc officielle, comment ça se fait ? Ça porte un autre nom et PS/2 serait une abréviation ou un abus de langage ?

Mini din ou PS/2, mais la doc officielle est bien cachée. Je trouve pas non plus les specs.

En attendant je vais bosser un peu la logique pour la réception / envoie de données.