Discussion :

[Vincent PETIT]

Le VGA c'est "pareil", de l'analogique. Mais les DAC R-2R ça à l'air simple; va juste falloir que je trouve la formule pour calculer R. Et j'espère que mon écran acceptera le +3.3V pour les signaux hsync / vsync; sinon même problème que pour le PS/2.

Le DVI c'est simple vu que c'est du digital, mais du coup j'suis bloqué à des basses résolutions (faut une fréquence monstrueuse à la place :/) et pour l'instant mon écran s'obstine à me dire "No Signal".

Un poil HS, mais pourquoi tout fonctionne en série ?
Quelle est la logique derrière ?

Exemple pour le DVI, c'est pas plus simple d'envoyer 24 bits / cycle @ 193MHz (1080p) que 3 bits / cycle @ 1.93GHz ?

Plus faible fréquence -> moins sensible aux "stimulis extérieurs" qui peuvent corrompre les données. Moins cher aussi car il faut des composants moins performants.
Et plus faible fréquence -> pas besoin de l'encodage TMDS non plus.

Alors ça je peux répondre ! Ta remarque est pertinente, de plus en plus on passe en communication série (USB, les disques dur de PC qui sont passés de IDE a SATA, HDMI, etc...)

Les raisons sont très simples :
Moins coûteux en câble (conducteur, blindage, matière, stockage, ...)
Moins d'encombrement (un petit contrôleur 24 bits parallèles ne pourrait pas être aussi miniaturisé que son homologue "série")
Aujourd'hui on arrive a atteindre des vitesses fulgurantes en série.

Donc plus ça vient et plus on est sur des protocoles sériels.

A la rigueur on pourrait regarder tout ça dans un autre poste car ça m'intéresse aussi (j'ai jamais pratiqué VGA ou DVI)

[Iradrille]

Je n'ai pas eu le temps de simuler ce montage.
Je le ferai ce week end et il doit me rester aussi pas mal de BC547B (grand classique), j’essaierai de la câbler en vrai pour voir.

Ça marche !

Je corrige 2/3 problèmes (genre ma FSM qui reste bloqué dans certains états) et je poste mes sources pour les curieux.

A la rigueur on pourrait regarder tout ça dans un autre poste car ça m'intéresse aussi (j'ai jamais pratiqué VGA ou DVI)

Pour l'instant pas de problèmes particulier avec. Mais on peut faire ça oui.

DVI : ma logique est fausse -> l'écran gueule;
VGA : j'ai oublié de souder les pins à mettre à la masse . Du coup je cherche un autre port VGA (après avoir soudé les fils, j'ai coulé du silicone pour pas que ça bouge, du coup impossible de rattraper l'erreur).

D'un point de vue électronique "pure" c'est par contre très simple :

8 GPIOs -> connecteur DVI

[Auteur]

Vous pouvez m'expliquer le rôle des transistors (les BC547) dans le message de Vincent ? Je n'ai jamais vu un tel montage.

[Vincent PETIT]

Vous pouvez m'expliquer le rôle des transistors (les BC547) dans le message de Vincent ? Je n'ai jamais vu un tel montage.

Oh que si tu as déjà vu ce montage ! Il est juste dessiné bizarrement.

Je vais te redessiner la partie en bleue


Voilà comment c'est fait mais dans un sens de lecture beaucoup plus lisible.
Intérieur du clavier correspond à l'intérieur de la fiche DIN PS/2 du schéma du dessus.


1) Etat du clavier en fonctionnement (on est dans le sens clavier vers FPGA) : Q2 est ouvert, on a donc 5V sur l'émetteur de Q1. Comment est Q1 ? Dans un état ouvert aussi car aucun courant ne va s'écouler du collecteur vers l'émetteur (il aurait fallu que l'émetteur soit à la masse mais il est au +5V) Donc l'entrée du FPGA est à +3.3V

2) Etat du clavier en fonctionnement (on est dans le sens clavier vers FPGA) : Q2 est saturé, on retrouve 0V sur l'émetteur de Q1. Comment est Q1 ? Dans un état saturé aussi puisqu'on a un courant de base et il y a bien un courant qui s'écoule du collecteur vers l'émetteur. L'entrée FPGA = 0V

3) Conclusion : Quand collecteur de Q2 = 5V alors collecteur de Q1 = 3.3V. On a bien transformé le +5.5V en +3.3V

4) Et l'autre transistor monté en tête bêche ? Et bien il est simplement dans un état ouvert car il y a une pull-up au +3.3V sur son émetteur et aucun courant ne peut circuler du collecteur vers l'émetteur.

5) Etat du FPGA en fonctionnement (on est dans le sens FPGA vers clavier) : on applique le même raisonnement mais Q1 reste tout le temps ouvert et c'est le transistor monté en tête bêche qui va faire le boulot du +3.3V en +5V avec le même raisonnement qu'au dessus.

Avec l'ajout de l'autre transistor ça donne ceci.


Si c'est pas clair, je peux faire plusieurs schéma avec des couleurs comme je l'ai fait avec mon précédent montage

@Iradrille,
Nickel si ça fonctionne, moi en simulation c'est tip top ! Par contre, je vais devoir commander des transistors car je me suis rendu compte qu'il ne m'en restait quasiment plus
Pour VGA, je ne trouve pas de doc non plus !!! Tu te bases sur quel document ?

A+

[Iradrille]

Les sources.

Envoie / Réception d'octets :

Code VHDL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
 
entity ps2_comm is
	port(
		i_clk: in std_logic := 'X';
 
		i_ps2_data: in std_logic := '0';
		i_ps2_clk: in std_logic := '0';
 
		o_ps2_data: out std_logic := '0';
		o_ps2_data_we: out std_logic := '0';
 
		o_ps2_clk: out std_logic := '0';
		o_ps2_clk_we: out std_logic := '0';
 
		o_msg: out std_logic_vector(7 downto 0);
		o_data_available: out std_logic := '0';
 
		i_msg: in std_logic_vector(7 downto 0);
		i_we: in std_logic := '0'
	);
end entity ps2_comm;
 
architecture arch_ps2_comm of ps2_comm is
 
	type ps2_state_t is (
		idle,
		receiving,
		check_msg,
		clk_inib,
		sending,
		wait_for_ack
	);
 
	type ent_state_t is (
		init,
		ready
	);
 
	function comp_parity(s : std_logic_vector) return std_logic is
		variable parity : std_logic := '0';
	begin
		for i in s'range loop
			parity := parity xor s(i);
		end loop;
 
		return parity;
	end function comp_parity;
 
	constant CLK_INIB_CYCLES: integer := 8191;
 
	signal ent_st: ent_state_t := init;
	signal ps2_st: ps2_state_t := idle;
 
	signal msg: std_logic_vector(10 downto 0);
	signal old_clk: std_logic := '0';
	signal parity: std_logic := '0';
 
	signal bit_sent: unsigned(3 downto 0) := (others => '0');
	signal bit_received: unsigned(3 downto 0) := (others => '0');
 
	signal cnt_clk_inib: integer := 0;
 
begin
 
	process(i_clk)
 
	begin
		if rising_edge(i_clk) then
 
			old_clk <= i_ps2_clk;
 
			if i_we = '1' then
				-- prepare msg
				msg <= '1' & comp_parity(i_msg) & i_msg & '0';
				o_data_available <= '0';
				ps2_st <= clk_inib;
 
			else
				case ps2_st is
				when idle =>
					o_ps2_clk <= '1';
					o_ps2_clk_we <= '0';
					o_ps2_data <= '1';
					o_ps2_data_we <= '0';
					o_data_available <= '0';
 
					if old_clk = '1' and i_ps2_clk = '0' then
						ps2_st <= receiving;
						msg <= i_ps2_data & msg(9 downto 0);
						parity <= i_ps2_data;
						bit_received <= (others => '0');
					end if;
 
				when receiving =>
					if old_clk = '1' and i_ps2_clk = '0' then
						if bit_received = 9 then
							ps2_st <= check_msg;
							bit_received <= (others => '0');
						end if;
						bit_received <= bit_received + 1;
						msg <= i_ps2_data & msg(9 downto 0);
						parity <= i_ps2_data xor i_ps2_data;
					end if;
 
				when check_msg =>
					if msg(0) = '0' and msg (10) = '1' and msg(9) = parity then
						-- nok, resend TODO
						ps2_st <= idle;
					else
						-- ok
						o_data_available <= '1';
						o_msg <= msg(8 downto 1);
						ps2_st <= idle;
					end if;
 
				when clk_inib =>
					o_ps2_clk <= '0';
					o_ps2_clk_we <= '1';
					o_ps2_data <= '0';
					o_ps2_data_we <= '0';
 
					if cnt_clk_inib = CLK_INIB_CYCLES then
						cnt_clk_inib <= 0;
						ps2_st <= sending;
					else
						cnt_clk_inib <= cnt_clk_inib + 1;
					end if;
 
				when sending =>
					o_ps2_clk_we <= '0';
					o_ps2_data_we <= '1';
 
					if old_clk = '1' and i_ps2_clk = '0' then
						if bit_sent = 9 then
							bit_sent <= (others => '0');
							ps2_st <= wait_for_ack;
						else
							bit_sent <= bit_sent + 1;
							if msg(0) = '1' then
								o_ps2_data <= 'Z';
							else
								o_ps2_data <= '0';
							end if;
							o_ps2_data <= msg(0);
							msg <= '0' & msg(10 downto 1);
						end if;
					end if;
 
				when wait_for_ack =>
					o_ps2_data_we <= '0';
					if old_clk = '1' and i_ps2_clk = '0' then
						if i_ps2_data = '0' then
							-- ok
							ps2_st <= idle;
						else
							-- nok
							ps2_st <= idle;
						end if;
					end if;
 
				when others =>
					ps2_st <= idle;
 
				end case;
			end if;
		end if;
	end process;
end architecture arch_ps2_comm;

Exemple basique d'instanciation :

Code VHDL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
 
entity debouncer is
	generic(
		DEBOUNCE_CYCLES: integer
	);
	port(
		i_clk: in std_logic;
		i_data: in std_logic;
		o_data: out std_logic := '0'
	);
end entity debouncer;
 
architecture arch_debouncer of debouncer is
	signal cnt: integer := 0;
	signal current_value: std_logic := '0';
begin
	process(i_clk)
	begin
		if rising_edge(i_clk) then
			if i_data = current_value then
				cnt <= 0;
			else
				if cnt = DEBOUNCE_CYCLES then
					cnt <= 0;
					current_value <= i_data;
				else
					cnt <= cnt + 1;
				end if;
			end if;
			o_data <= current_value;
		end if;
	end process;
end architecture arch_debouncer;
 
library ieee;
use ieee.numeric_std.all;
use ieee.std_logic_1164.all;
 
entity ps2 is
	port(
		i_clk: in std_logic := 'X';
		i_resend: in std_logic := '0';
 
		io_ps2_data: inout std_logic := 'Z';
		io_ps2_clk: inout std_logic := 'Z'		
	);
end entity ps2;
 
architecture arch_ps2 of ps2 is
 
	component debouncer is
		generic(
			DEBOUNCE_CYCLES: integer
		);
		port(
			i_clk: in std_logic;
			i_data: in std_logic;
			o_data: out std_logic := '0'
		);
	end component debouncer;
 
	component ps2_comm is
		port(
			i_clk: in std_logic := 'X';
 
			i_ps2_data: in std_logic := '0';
			i_ps2_clk: in std_logic := '0';
 
			o_ps2_data: out std_logic := '0';
			o_ps2_data_we: out std_logic := '0';
 
			o_ps2_clk: out std_logic := '0';
			o_ps2_clk_we: out std_logic := '0';
 
			o_msg: out std_logic_vector(7 downto 0);
			o_data_available: out std_logic := '0';
 
			i_msg: in std_logic_vector(7 downto 0);
			i_we: in std_logic := '0'
		);
	end component ps2_comm;
 
	signal data_in: std_logic := '0';
	signal clk_in: std_logic := '0';
 
	signal data_out: std_logic := '0';
	signal clk_out: std_logic := '0';
 
	signal d_data_in: std_logic := '0';
	signal d_clk_in: std_logic := '0';
 
	signal data_we: std_logic := '0';
	signal clk_we: std_logic := '0';
 
	signal msg_in: std_logic_vector(7 downto 0);
	signal msg_out: std_logic_vector(7 downto 0);
 
	signal da: std_logic := '0';
	signal we: std_logic := '0';
 
	signal d_resend: std_logic := '0';
	signal old_resend: std_logic := '0';
 
begin
 
	deb_data: debouncer
		generic map(
			DEBOUNCE_CYCLES => 50 -- 1µs
		)
		port map(
			i_clk => i_clk,
			i_data => data_in,
			o_data => d_data_in
		);
 
	deb_clk: debouncer
		generic map(
			DEBOUNCE_CYCLES => 50 -- 1µs
		)
		port map(
			i_clk => i_clk,
			i_data => clk_in,
			o_data => d_clk_in
		);
 
	ps2: ps2_comm
		port map(
			i_clk => i_clk,
 
			i_ps2_data => d_data_in,
			i_ps2_clk => d_clk_in,
 
			o_ps2_data => data_out,
			o_ps2_data_we => data_we,
 
			o_ps2_clk => clk_out,
			o_ps2_clk_we => clk_we,
 
			o_msg => msg_in,
			o_data_available => da,
 
			i_msg => msg_out,
			i_we => we
		);
 
	deb_resend: debouncer
		generic map(
			DEBOUNCE_CYCLES => 5000000 -- 100ms
		)
		port map(
			i_clk => i_clk,
			i_data => i_resend,
			o_data => d_resend
		);
 
	process(i_clk)
	begin
 
		if rising_edge(i_clk) then
			data_in <= io_ps2_data;
			clk_in <= io_ps2_clk;
 
			if data_we = '1' then
				io_ps2_data <= data_out;
			else
				io_ps2_data <= 'Z';
			end if;
 
			if clk_we = '1' then
				io_ps2_clk <= clk_out;
			else
				io_ps2_clk <= 'Z';
			end if;
 
			old_resend <= d_resend;
			if old_resend = '0' and d_resend = '1' then
				we <= '1';
				msg_out <= "11111111";
			else
				we <= '0';
			end if;
 
		end if;	
 
	end process;
end architecture arch_ps2;

Pour VGA, je ne trouve pas de doc non plus !!! Tu te bases sur quel document ?

http://javiervalcarce.eu/html/vga-si...-specs-en.html (Par exemple)
http://www.tinyvga.com/vga-timing

Résistance de terminaison : 75 ohm.
R / G / B analogique (0V = 0; +0.7V = 255)
hsync / vsync digital +5.0V (compatible +3.3V normalement). En fonction de la résolution ils peuvent être "inversés" (synchronisation horizontale / verticale quand ils sont à 0).

[Auteur]

euh

Pour moi le collecteur de Q2 est relié à l'émetteur de Q1 et le collecteur de Q1 à l'émetteur de Q2. Les bases de Q1 et Q2 sont reliées. Non, là je ne vois vraiment pas l'intérêt de ce montage tête bêche.

[julien terrier]

Salut Iradrille,

par curiosité quel FPGA utilises tu ? Je te pose cette question parce que je suis tombé sur une doc Xilinx d'un FPGA qui peut etre configurer selon l'alim de tes clavier/souris 3.3v ou 5v. Il possède bien entendu un PS/2 DIN Connector.

Cela a attiré mon attention car j'ai lu l'intégralité du post avec les solutions proposées et dans cette doc un jumper et une résistance de 270 ohm font l'affaire...









Maintenant j'ai cru comprendre que les bank du FPGA pouvez être alimentées différemment ==> The VCCO supplies, one for each of the FPGA’s I/O banks, power the output drivers, except when using the GTL and
GTLP signal standards. The voltage on the VCCO pins determines the voltage swing of the output signal.

[Iradrille]

Salut Iradrille,

par curiosité quel FPGA utilises tu ? Je te pose cette question parce que je suis tombé sur une doc Xilinx d'un FPGA qui peut etre configurer selon l'alim de tes clavier/souris 3.3v ou 5v. Il possède bien entendu un PS/2 DIN Connector.

Cela a attiré mon attention car j'ai lu l'intégralité du post avec les solutions proposées et dans cette doc un jumper et une résistance de 270 ohm font l'affaire...

J'ai une De0 nano SoC (Cyclone V).
Il n'y a pas moyen d'avoir du 5V je crois.

Maintenant j'ai cru comprendre que les bank du FPGA pouvez être alimentées différemment ==> The VCCO supplies, one for each of the FPGA’s I/O banks, power the output drivers, except when using the GTL and
GTLP signal standards. The voltage on the VCCO pins determines the voltage swing of the output signal.

J'ai pas tout compris au principe des banks, mais je crois que tous les pins appartenant a une bank sont alimentés avec la même tension.

J'ai aucune bank en +5V, c'est du +3.3V partout.

[Vincent PETIT]

euh
Pour moi le collecteur de Q2 est relié à l'émetteur de Q1 et le collecteur de Q1 à l'émetteur de Q2. Les bases de Q1 et Q2 sont reliées. Non, là je ne vois vraiment pas l'intérêt de ce montage tête bêche.

Alors je me suis mal expliqué. En voici une autre et avec un angle de vu un peu différent.
Contexte important : Nous parlons de lignes I/O (bidirectionnelles donc forcément a structure de type collecteur ou drain ouvert pour éviter les conflits/courts-circuit)

Voici la partie du schéma côté clavier et redessiné de manière plus lisible :

Lorsque Q2 est saturé alors Q1 se retrouve dans un état connu, son émetteur est relié au 0V, on a un courant de base constant et on a un courant qui s'écoule du collecteur vers l'émetteur, Q1 est saturé comme Q2. La sortie OUT 3.3V est à 0V et l'entrée IN 5V aussi puisque Q1 et Q2 sont saturés (équivalent à un fil en négligeant la tension VCE sat)

Lorsque Q2 est ouvert, alors on va retrouver +5V sur l'émetteur de Q1 et celui ci est va être dans un état particulier. Comme il n'y aura pas d'écoulement de courant du collecteur vers l'émetteur (car il aurait fallu qu'il soit au 0V) le transistor Q1 est ouvert (équivalent a un interrupteur ouvert). La sortie OUT 3.3V est à 3.3V et l'entrée IN 5V à 5V puisque Q1 et Q2 sont ouverts (on peut considéré qu'ils sont presque absent)

Comment ça fonctionne ?
Quand le clavier est en lecture, il écoute, Q2 et Q1 sont ouverts (donc absents) et des données peuvent arriver sans encombre depuis IN 5V. La résistance de pull-up interne R1 n'aura pas d'influence sur les données qui arrivent.
Quand le clavier est en écriture, il émet un 0 en faisant saturer Q2 et Q1 OUT 3.3V fera de même, il créera un 0 logique d'une valeur de 0V. Si le clavier veut envoyer un 1 alors Q2 et Q1 seront ouverts (donc absents) et OUT 3.3V créera un 1 logique d'une valeur de 3.3V.
On peut remarquer que comme Q2 agit directement sur IN 5V, on va créer un echo de output dans input.

Maintenant voilà l'autre partie, la même structure mais côté du FPGA.

Il s'agit de la même structure que la partie clavier qui faisait +5V -> 3.3V mais cette fois ci pour faire la même conversion +3.3V -> 5V.
Le fonctionnement est rigoureusement le même que côté clavier.

Donc on peut relier OUT 3.3V à IN 3.3V (en bleu) et OUT 5V à IN 5V (en rouge)

On peut remarquer tout de suite qu'on vient de relier le collecteur de Q1 à l'émetteur de Q3 et l'émetteur de Q1 au collecteur de Q3. (montage tête bêche).

Étape suivante : simplification du schéma

Après avoir relié les structures, on remarque des doublons. On a une résistance de pull-up R1 au +5V et si on suit la liaison (en rouge) on se retrouve à nouveau avec un résistance de pull up R4 au +5V aussi. L'une des deux est inutile !
Les deux bases des transistors tête bêche sont alimentés par deux résistances de même valeurs et reliées toutes les deux au +3.3V. Une seule résistances est suffisante.
Si on suit la liaison OUT 3.3V (en bleue) on s'aperçoit qu'on a une résistance de pull-up R3 au +3.3V et aussi une résistance de pull-up R6 aussi sur le 3.3V. On va en supprimer une des deux.
Bon j'ai pensé à Iradrille, je me suis dit qu'il ferai la gueule si je lui demandais de disséquer sont FPGA pour intégrer R6 Je l'ai plutôt supprimer et laissé à la place R3

Est ce plus clair ?
Si non, aucun soucis, je peux encore expliquer différemment mais en plusieurs postes car j'aurai besoin de faire beaucoup plus de schémas "petites étapes par petites étapes".
Le schéma n'est pas du tout intuitif, je le conçois !

A+
Vincent

[Vincent PETIT]

@Iradrille et Julien,
Eh... attendez moi les copains..... j'arrive plus à suivre, on s'éparpille entre : le schéma, le VGA, le DVI, Le FPGA, Koh lanta hier (ouais, parce que chaque année ma femme me ressort mon vieux short dégueulasse, mon T-shirt qui sent le fauve et elle fait livrer 1m3 de sable dans le salon comme ça je suis en condition pour regarder ça tranquille dans le canapé avec ma bière)

Si il y a un doute avec le schéma du DE0 nano à la rigueur si on a le schéma on peut regarder tout ça sur un autre sujet !

[Iradrille]

Si il y a un doute avec le schéma du DE0 nano à la rigueur si on a le schéma on peut regarder tout ça sur un autre sujet !

Pas de problèmes de ce coté, @Julien se demandait si j'avais un port PS/2 sur ma carte (avec possibilité de l'alimenter en +5V).
Mais non, d'où le problème (je passe par des GPIO, du coup limité à 3.3V).

@Iradrille et Julien,
Eh... attendez moi les copains..... j'arrive plus à suivre, on s'éparpille entre : le schéma, le VGA, le DVI, Le FPGA, Koh lanta hier (ouais, parce que chaque année ma femme me ressort mon vieux short dégueulasse, mon T-shirt qui sent le fauve et elle fait livrer 1m3 de sable dans le salon comme ça je suis en condition pour regarder ça tranquille dans le canapé avec ma bière)

Pour moi, c'est tout bon.

Le problème du port PS/2 est réglé, le VGA ça marche en 1080p, le DVI ça marche pas mais osef pour l'instant.

Je marque résolu, mais n'hésitez pas si vous avez des questions / remarques.

[Auteur]

@Vincent PETIT : finalement ce système de transistors tête bêche c'est simplement pour avoir une compatibilité en tension pour les 2 systèmes (un peu comme les circuits logiques TTL / CMOS) ? Une sorte de porte "OUI" qui donne 3,3V en sortie lorsqu'il y a 5V en entrée et 0V en sortie s'il y a 0V en entrée.
Si je ne me trompe pas, Q1 et Q3 sont toujours passants car il y a toujours 3,3V/R sur leur base. L'état des transistors Q1 et Q3 ne dépend donc que de l'état de Q2. Du coup, peut-on remplacer ces transistors par 2 diodes têtes-bêches ?

J'ai juste ou je suis encore à côté de la plaque ?

[Vincent PETIT]

finalement ce système de transistors tête bêche c'est simplement pour avoir une compatibilité en tension pour les 2 systèmes (un peu comme les circuits logiques TTL / CMOS) ?

Oui c'est ça, c'est un level translator mais bidirectionnel et non inverseur.

Une sorte de porte "OUI" qui donne 3,3V en sortie lorsqu'il y a 5V en entrée et 0V en sortie s'il y a 0V en entrée.

C'est ça et dans l'autre sens aussi, un transistor est dédié à chaque direction (clavier 5V vers FPGA 3.3V et l'autre sens FPGA 3.3V vers clavier 5V)

Si je ne me trompe pas, Q1 et Q3 sont toujours passants car il y a toujours 3,3V/R sur leur base. L'état des transistors Q1 et Q3 ne dépend donc que de l'état de Q2. Du coup, peut-on remplacer ces transistors par 2 diodes têtes-bêches ?

Alors, non, même si Q1 et Q3 on toujours un courant sur leur base, ils ne sont pas toujours passant il y a des conditions qui ne sont pas bonnes sur leurs émetteurs à un moment donnée (voir après).

Regardons le schéma :
On va regarder une communication qui part du clavier => FPGA (j'ai donc effacer le transistor du FPGA qui restera toujours bloqué car en écoute du clavier)

Le clavier envoi un 0 logique (couleur bleue)
- Q2 est saturé pour créer un 0 logique donc un 0V.
- Le 0V arrive sur INPUT du Clavier mais aussi sur l'émetteur de Q1.
- Q1 est dans une condition de saturation car il y a un courant sur sa base mais surtout il y a un courant dans son collecteur (un courant va traverser R3 puisqu'elle est entre le +3.3V et le 0V)
- Ce 0V va se retrouver sur l'émetteur de Q3 et sur le INPUT du FPGA si on suit la liaison.
- Il va se passer quelques chose d'important au passage, Q3 va saturer aussi car il est dans de bonne condition, il y a un courant sur sa base mais surtout il y a un courant dans son collecteur (un courant va traverser R4 puisqu'elle est entre le +5V et le 0V)


Le clavier envoi un 1 logique (couleur rouge pour le 5V et orange pour le 3.3V)
- Q2 est bloqué pour créer un 1 logique donc un 5V et c'est pour ça que je l'ai effacé.
- Le 5V arrive sur INPUT du Clavier mais aussi sur l'émetteur de Q1.
- Q1 est dans une mauvaise condition pour saturer même si il a un courant sur sa base aucun courant ne circulera dans son collecteur car l'émetteur est à un potentiel. C'est à la masse qu'il fallait qu'il soit pour saturer (au pire au travers d'une résistance d'émetteur pourquoi pas mais elle même à la masse, comme dans un transistor émetteur suiveur) Q1 est donc bloqué.
- Ce 5V va se retrouver sur le collecteur de Q3 et donc retournera a sa source si on suit la liaison.
- Comme Q1 est bloqué, on a le 3.3V qui va se retrouver sur l'émetteur de Q3 et il sera bloqué aussi et ce, pour la même raison que Q1 est bloqué (émetteur à un potentiel alors qu'il faudrait qu'il soit à la masse)


Dans mon poste #44 (point 4) c'est vrai que je n'ai pas été clair du tout. Au contraire en disant ça, c'est à dire la moitié de l'explication, je me rends compte que j'ai apporté plus de confusion qu'autre chose.

Le même raisonnement s'applique si on est dans le sens FPGA vers Clavier.
C'est un système bidirectionnel, non inverseur et anti conflits de tension (aucun court circuit)

Si tu simplifies le schéma comme dans mon précédent post alors tu obtiens le schéma initiale qui m'a demander un certain temps pour tout comprendre (justement à cause de la simplification qui nuit à l'étude du bidule)

Je ne pense pas qu'on puisse remplacer ce montage par des diodes têtes bêches ou alors je ne vois pas comment.

[Auteur]

Bon... je n'arrive pas à comprendre la logique...
J'ai suggéré les diodes car pour moi les transistors ayant toujours un courant de base ils fonctionnent un peu comme une diode. Mais a priori c'est une idée fausse que je n'arrive pas à m’ôter de la tête ce qui peut sans doute expliquer que ce montage avec transistors tête bêche me laisse perplexe.

Je ferai le montage et des mesures.