Bonsoir / bonjour à tous.
Quelques lignes pour vous présenter mon projet. Je réalise enfin mon réseau HO. Pour cela, en parallele de cette réalisation, je maquette quelques solutions techniques chipées par ci par là (rmf, ptit\'train, amfn, rob ...). car je souhaite que le réseau soit sans \"interrupteur / swith\", uniquement pilotable / piloté par un Pc : allumer une lampe : clic sur un bouton, mettre une vitesse de consigne sur un canton : 60% avec la souris ... Ma maquette, à comprendre le test que je réalise, doit me permettre de valider toute la partie interface. J\'ai par exemple adapté un détecteur d\'occupation de canton trouver sur le site amfn. La sortie TTL est lue par ma carte E/S et le programme me retourne canton X = BUSY ou FREE ! C\'est le PC (le code que j\'ai fait !) qui passe les feux précédent au R / O / V. Idem pour le basculement d\'un switch, un petit montage piqué chez Rob Paysley et hop que du bonheur :un clic de souris et l\'aiguille bouge !
La partie finale (je veux que le train T1 passe par les Canton 1,2, 5 ,6 ... ) et gestion \"automatique\" du reste sera fait plus tard ... Mais pour moi, ce n\'est que algorithmique et programmation !!!!
Vous savez ce que je veux faire. Qui suis-je ... Informat\'pt\'it chien, j\'ai, sans avoir les chevilles qui enflent, une bonne maitrise des langages \"basic\" (C / C++ / Assembleur ) et des langagues plus évoluées (SQL / PL/SQL ...) Par contre, je suis un autodidacte de l\'électronique ... Mais avec les explications des auteurs de circuits, les datasheets, quelques notions revues sur le nets et quelques \"cramages\" (mais c\'est comme cela que l\'on apprend !!).
Bon venons en à mon \"problème\" : Etre capable de donner un \"vitesse\" de consigne à un canton via le port USB. Je voudrais envoyer une commande de type \"canton C\", \"Vitesse V\". Sachant que C peut être une adresse binaire et V idem ou un % .
Ce que j\'ai vu pour le moment, ne cadre pas avec mon interface car nécessite 8 bits (8 sortie) par canton ! Sachant qu\'à terme, il y aura environ 32 cantons ... Ce que j\'ai vu est à base de PMW/MLI et CNA.
Faut il une \"carte\" d\'interface capable de recevoir et interpréter les deux octets (address et vitesse) et de les \"envoyer\" au canton ? ..
Quelques infos complémentaires : tension de rails : 12 V environs !sur deux rails. PC : W7 + USB 2.0 pas de port // ou série (ben c\'est ça le modernisme !)
Peut être avez vous quelque chose de plus simple, m\'enfin je l\'espère !
Si vous avez besoin d\'informations complémentaires, n\'hésitez pas.
Par avance merci et bon week end.
Al\'
Re: Alimentation de canton à travers le port USB
Modérateurs : Philippe Cousyn, Tibrus, Patrice, Arnaud Guyon
Re: Alimentation de canton à travers le port USB
Bonjour
Je fait pour mon réseau des choses très semblables. Tout passe par un port USB. C\'est l\'ordinateur qui contrôle tout.
Qu\'est ce que tu as comme carte d\'entrées/sorties (USB???)
Pierre
Je fait pour mon réseau des choses très semblables. Tout passe par un port USB. C\'est l\'ordinateur qui contrôle tout.
Qu\'est ce que tu as comme carte d\'entrées/sorties (USB???)
Pierre
-
Tibrus
- Modérateur
- Messages : 9682
- Enregistré le : 31 mai 2008 08:23
- Localisation : Dans mon sous-sol
- Epoque(s) : IV, V et VI
- Région(s) pratiquée(s) : Un penchant pour Rhone Alpes
- Echelle(s) pratiquée(s) : H0
- Contact :
Re: Alimentation de canton à travers le port USB
Salut Pierre59
Bienvenue sur le forum RMF
Je crois qu\'il fa falloir que tu ouvres une discussion dans cette section du site pour nous expliquer tout cela
Schéma à l\'appui, cela serait un bon tremplin pour pas mal de membre qui souhaiteraient utiliser ce système sur port USB. Enfin si tu te sens de partir dans des explications théoriques et pratiques :laugh:
Moi je te dis déjà merci d\'avance :whistle:
Bienvenue sur le forum RMF
Je crois qu\'il fa falloir que tu ouvres une discussion dans cette section du site pour nous expliquer tout cela
Schéma à l\'appui, cela serait un bon tremplin pour pas mal de membre qui souhaiteraient utiliser ce système sur port USB. Enfin si tu te sens de partir dans des explications théoriques et pratiques :laugh:
Moi je te dis déjà merci d\'avance :whistle:
Re: Alimentation de canton à travers le port USB
Bonsoir Pierre et Tibrus
Pour ma part j\'utilise des cartes de elexol et decision computer. Carte du marché, qui peuvent sembler avoir un prix élever. Néanmoins, compte tenu du cout des pièces du temps de montage et des aléas, je pense que cela vaut le coût. Enfin c\'est mon avis, en effet, je ne peux qu\'appliquer un schéma et pas le créer (le modifier à la marge à la rigueur).
Je suis d\'accord pour participer à la disussion et partager mes idées, réalisations et ... déboire.
Pour le moment, sur ma maquette (un oval, deux voies d\'évitement, un croisement, 1 voie de garage, avec un locotracteur et un wagon donc loin de la réalisation que je fais) j\'ai réalisé la gestion des feux de tous les cantons et celle de l\'alimentation (tout ou rien) d\'un canton en fonction des feux.
Deux infos : chaque canton à deux zones : celle de pleine voie et celle d\'arret avec pour chaque un détecteur de consommation et chaque canton est mono sens, donc mon oval de test ne tourne que dans un sens !
J\'ai deux chantiers en cours : 1) le basculement des aiguillages (de type jouef à électo aimants), avec un montage de Rob\' piloté par un action manuelle sur le PC (clic sur un icone) 2) pouvoir réduire / augmenter la vitesse du train en fonction du canton (vitesse de consigne, feux, type de train ...) , là ou je coince !
Je planche aussi sur l\'algo de gestion de circuits : le train A passe par les cantons 1,2,4,5 et le B par 1,2,3,5 avec basculement des aiguilles ...
Mon point noir, c\'est de pouvoir \"gérer\" la \"vitesse\" avec un minimum bits donc de lignes d\'E/S....
A bientôt pour la suite.
Al\'
Pour ma part j\'utilise des cartes de elexol et decision computer. Carte du marché, qui peuvent sembler avoir un prix élever. Néanmoins, compte tenu du cout des pièces du temps de montage et des aléas, je pense que cela vaut le coût. Enfin c\'est mon avis, en effet, je ne peux qu\'appliquer un schéma et pas le créer (le modifier à la marge à la rigueur).
Je suis d\'accord pour participer à la disussion et partager mes idées, réalisations et ... déboire.
Pour le moment, sur ma maquette (un oval, deux voies d\'évitement, un croisement, 1 voie de garage, avec un locotracteur et un wagon donc loin de la réalisation que je fais) j\'ai réalisé la gestion des feux de tous les cantons et celle de l\'alimentation (tout ou rien) d\'un canton en fonction des feux.
Deux infos : chaque canton à deux zones : celle de pleine voie et celle d\'arret avec pour chaque un détecteur de consommation et chaque canton est mono sens, donc mon oval de test ne tourne que dans un sens !
J\'ai deux chantiers en cours : 1) le basculement des aiguillages (de type jouef à électo aimants), avec un montage de Rob\' piloté par un action manuelle sur le PC (clic sur un icone) 2) pouvoir réduire / augmenter la vitesse du train en fonction du canton (vitesse de consigne, feux, type de train ...) , là ou je coince !
Je planche aussi sur l\'algo de gestion de circuits : le train A passe par les cantons 1,2,4,5 et le B par 1,2,3,5 avec basculement des aiguilles ...
Mon point noir, c\'est de pouvoir \"gérer\" la \"vitesse\" avec un minimum bits donc de lignes d\'E/S....
A bientôt pour la suite.
Al\'
Re: Alimentation de canton à travers le port USB
Bonjour
Pour ma part j\'utilise aussi des modules Elexol (auparavant appelés Ravar). Il existe plusieurs sortes de modules : MOD3 USB/serie, MOD4 USB/parallèle, MOD5 double USB/série ou parallèle, USBIO24 24 lignes d\'E/S.
Le module USBIO24 fournit 24 lignes d\'entrées/sorties c\'est bien évidemment très limité, mais il existe des solutions pour augmenter le nombre de lignes utilisables :
- utilisation de multiplexeurs/démultiplexeurs
- utilisation de registres à décalage (comme l\'AMFN sur leurs pages techniques)
- utilisation des 3 bus SPI du module, il existe beaucoup de circuits avec une interface SPI
- utilisation d\'un circuit contrôleur SPI/I2C, il existe aussi beaucoup de circuits avec une interface I2C
- mélange des solutions précédentes
Le module MOD3 est un convertisseur USB série RS232 (peu utilisable ici ?).
Le module MOD4 est un convertisseur USB parallèle destiné à être interfacé avec un micro-contrôleur.
Le module MOD5 est un double convertisseur USB série ou parallèle au choix.
Sur mon réseau j\'utilise un MOD5 USB/parallèle qui est interfacé avec deux micro-contrôleurs ATmega8 d\'Atmel, chacun des micro-contrôleur gére un bus I2C. Cela fait donc 2 bus I2C sur lesquels sont connectés toutes les cartes de gestion du réseau (alimentations PWM et DCC, détections par consommation de courant, relais de zones, aiguilles, ...), ces cartes sont souvent dotées aussi d\'un micro-contrôleur, mais aussi de circuits I2C.
Voila, n\'hésitez pas à poser des questions.
Pierre
Pour ma part j\'utilise aussi des modules Elexol (auparavant appelés Ravar). Il existe plusieurs sortes de modules : MOD3 USB/serie, MOD4 USB/parallèle, MOD5 double USB/série ou parallèle, USBIO24 24 lignes d\'E/S.
Le module USBIO24 fournit 24 lignes d\'entrées/sorties c\'est bien évidemment très limité, mais il existe des solutions pour augmenter le nombre de lignes utilisables :
- utilisation de multiplexeurs/démultiplexeurs
- utilisation de registres à décalage (comme l\'AMFN sur leurs pages techniques)
- utilisation des 3 bus SPI du module, il existe beaucoup de circuits avec une interface SPI
- utilisation d\'un circuit contrôleur SPI/I2C, il existe aussi beaucoup de circuits avec une interface I2C
- mélange des solutions précédentes
Le module MOD3 est un convertisseur USB série RS232 (peu utilisable ici ?).
Le module MOD4 est un convertisseur USB parallèle destiné à être interfacé avec un micro-contrôleur.
Le module MOD5 est un double convertisseur USB série ou parallèle au choix.
Sur mon réseau j\'utilise un MOD5 USB/parallèle qui est interfacé avec deux micro-contrôleurs ATmega8 d\'Atmel, chacun des micro-contrôleur gére un bus I2C. Cela fait donc 2 bus I2C sur lesquels sont connectés toutes les cartes de gestion du réseau (alimentations PWM et DCC, détections par consommation de courant, relais de zones, aiguilles, ...), ces cartes sont souvent dotées aussi d\'un micro-contrôleur, mais aussi de circuits I2C.
Voila, n\'hésitez pas à poser des questions.
Pierre
-
Tibrus
- Modérateur
- Messages : 9682
- Enregistré le : 31 mai 2008 08:23
- Localisation : Dans mon sous-sol
- Epoque(s) : IV, V et VI
- Région(s) pratiquée(s) : Un penchant pour Rhone Alpes
- Echelle(s) pratiquée(s) : H0
- Contact :
Re: Alimentation de canton à travers le port USB
Sympathique les cartes de decision computer
De plus, je constate qu\'il fournisse les DLL pour que celui qui programme un peu puisse développer son interface logiciel afin de piloter son réseau. Et ceci sous plusieurs outils de développement.
Pour le Pb de ama0000, je verrais bien dans ce cas une carte USB/I2C.
Et ensuite un module I2C/PWL par canton.
De plus, je constate qu\'il fournisse les DLL pour que celui qui programme un peu puisse développer son interface logiciel afin de piloter son réseau. Et ceci sous plusieurs outils de développement.
Pour le Pb de ama0000, je verrais bien dans ce cas une carte USB/I2C.
Et ensuite un module I2C/PWL par canton.
Re: Alimentation de canton à travers le port USB
Bonsoir à tous !
L\'USBIO24 24 lignes d\'E/S me semblait un bon tremplin pour faire la maquette, et je ne suis pas déçu... si ce n\'est que je pense l\'avoir claquée ... J\'ai contacté leur support mais ils ont fait le même diag\' ...
Je dois dire que le site le L\'AMFN est rès bien. Coup de chapeau à leur équiê. Dommage qu\'il n\'y ait pas de nouveauté technique, mais il faut reconnaitre que ce qui est exposé / montré est toujours d\'actualité. Je m\'en suis inspiré très largement ... et en plus c\'est en Français !
Pour le moment, je n\'ai pas trop envie de passer sur I²C ou des microproc\'. Pourquoi ? pare que je pense / crois que le Pc doit être capable de gérer ce que je veux faire ! Bien sur je ne suis pas obtus ... donc j\'y reviendrais peut être plus tard !
Si je reviens à mon problème de gestion de \"vitesse\", je pense utiliser des TLc7226 (merci AMFN !) : En résumé, un chip pas chère, 4 amplis et 4 cantons de gérés ! A ce sujet quel ampérage le montage de AMFN peut il supporter ? Je pense qu\'il est taillé pour des trains \"normaux\" : chaque sortie = 250 mA environ ?
Je table sur 32 cantons ( 2^6 !). J\'ai donc besoin de 8 lignes pour la \"vitesse\" et 6 bits pour l\'adresage. Si je regarde le montage AMFN un montage à base de hct574 doit me permettre de passer l\'adresse et les data en deux \"write\". Mais ... car il y a un mais, le TLC7226 à besoin de 2 bits (lignes) en entrée pour \"décoder\" quelle sortie est à utiliser ... Or je ne sais / connais / ai la connaisance / compétence / pour passer de 8 bits en 8 * 2, c\'est à dire exploser / éclater 6 bits (mini, qui peut le plus peut le moins), en 8 * 2 bits (ces deux bits servant à cahque 7226) .
Pas clair ? oui je reformule !
Un 7226 peux alimenter 4 cantons. Pour cela il faut donner la fréquence (8 bits) ainsi que le canton pour ce 7226 sur 2 bits (donc 4 cantons).. Ayant 32 cantons, le ratio me dit : 8 puces 7226. Donc un bus de données de 8 bits commun au 8 puces 7226 et 6 bits pour trouver quel 7226 adresser ? Donc comment décoder et avec quel chips décoder 6 (ou 8bits) en paquets de 2 .
Algo de en programmation \"pure\" :
Hypothèse : les bits sont numérotés de 0 à 7 / les sortie des TLC sont numérotées de 0 à 3
0 0 0 0 0 0 0 0 > boitier 0 / sortie 0
0 1 0 0 0 0 0 0 > boitier 0 / sortie 2
0 0 0 1 0 0 0 0 > boitier 4 / sortie 3
il faut adresser donc
0 à 3 chip 0
4 à 7 chip 1
8 à 11 chip 2
12 à 15 chip 3 ... pas de soucis si on fait +1 !!!
Si bit1 alors boitier 0
si bit2 alors boitier 1
si bit3 alors boitier 2
-- en clair botier x pour bit(x-1)
Je pense que ce bit / fil doit entrer en tant qu\'activateur de chip ... mais lequel
?
Ben je vous laisse plancher ...
Belle soirée
Al\'
L\'USBIO24 24 lignes d\'E/S me semblait un bon tremplin pour faire la maquette, et je ne suis pas déçu... si ce n\'est que je pense l\'avoir claquée ... J\'ai contacté leur support mais ils ont fait le même diag\' ...
Je dois dire que le site le L\'AMFN est rès bien. Coup de chapeau à leur équiê. Dommage qu\'il n\'y ait pas de nouveauté technique, mais il faut reconnaitre que ce qui est exposé / montré est toujours d\'actualité. Je m\'en suis inspiré très largement ... et en plus c\'est en Français !
Pour le moment, je n\'ai pas trop envie de passer sur I²C ou des microproc\'. Pourquoi ? pare que je pense / crois que le Pc doit être capable de gérer ce que je veux faire ! Bien sur je ne suis pas obtus ... donc j\'y reviendrais peut être plus tard !
Si je reviens à mon problème de gestion de \"vitesse\", je pense utiliser des TLc7226 (merci AMFN !) : En résumé, un chip pas chère, 4 amplis et 4 cantons de gérés ! A ce sujet quel ampérage le montage de AMFN peut il supporter ? Je pense qu\'il est taillé pour des trains \"normaux\" : chaque sortie = 250 mA environ ?
Je table sur 32 cantons ( 2^6 !). J\'ai donc besoin de 8 lignes pour la \"vitesse\" et 6 bits pour l\'adresage. Si je regarde le montage AMFN un montage à base de hct574 doit me permettre de passer l\'adresse et les data en deux \"write\". Mais ... car il y a un mais, le TLC7226 à besoin de 2 bits (lignes) en entrée pour \"décoder\" quelle sortie est à utiliser ... Or je ne sais / connais / ai la connaisance / compétence / pour passer de 8 bits en 8 * 2, c\'est à dire exploser / éclater 6 bits (mini, qui peut le plus peut le moins), en 8 * 2 bits (ces deux bits servant à cahque 7226) .
Pas clair ? oui je reformule !
Un 7226 peux alimenter 4 cantons. Pour cela il faut donner la fréquence (8 bits) ainsi que le canton pour ce 7226 sur 2 bits (donc 4 cantons).. Ayant 32 cantons, le ratio me dit : 8 puces 7226. Donc un bus de données de 8 bits commun au 8 puces 7226 et 6 bits pour trouver quel 7226 adresser ? Donc comment décoder et avec quel chips décoder 6 (ou 8bits) en paquets de 2 .
Algo de en programmation \"pure\" :
Hypothèse : les bits sont numérotés de 0 à 7 / les sortie des TLC sont numérotées de 0 à 3
0 0 0 0 0 0 0 0 > boitier 0 / sortie 0
0 1 0 0 0 0 0 0 > boitier 0 / sortie 2
0 0 0 1 0 0 0 0 > boitier 4 / sortie 3
il faut adresser donc
0 à 3 chip 0
4 à 7 chip 1
8 à 11 chip 2
12 à 15 chip 3 ... pas de soucis si on fait +1 !!!
Si bit1 alors boitier 0
si bit2 alors boitier 1
si bit3 alors boitier 2
-- en clair botier x pour bit(x-1)
Je pense que ce bit / fil doit entrer en tant qu\'activateur de chip ... mais lequel
?Ben je vous laisse plancher ...
Belle soirée
Al\'
-
Tibrus
- Modérateur
- Messages : 9682
- Enregistré le : 31 mai 2008 08:23
- Localisation : Dans mon sous-sol
- Epoque(s) : IV, V et VI
- Région(s) pratiquée(s) : Un penchant pour Rhone Alpes
- Echelle(s) pratiquée(s) : H0
- Contact :
Re: Alimentation de canton à travers le port USB
Peux-tu mettre le lien du montage de l\'AMFN avec le TLC7226 ?
J\'ai un peu de mal ce matin
Et si je veux jeter un œil autant que je partes sur la même base que toi
J\'ai un peu de mal ce matin
Et si je veux jeter un œil autant que je partes sur la même base que toi
Re: Alimentation de canton à travers le port USB
Bonjour
Pour commander un TCL7226 il faut lui envoyer SIMULTANEMENT les 8 bits de donnée, les 2 bits d\'adresse puis agir sur le bit WR pour valider la commande, cela fait 13 bits/fils pour un TCL7226.
Pour commander 8 TCL7226 les bits de donnée et d\'adresses peuvent êtres communs, restent les bits WR, il en faudrait 8, mais comme on ne commande qu\'un TCL7226 à la fois on peut utiliser un démultiplexeur 3 vers 8 qui nécessite 3 bits d\'adresse plus un bit de validation. Bilan 8 bits de donnée, 2 bits d\'adresse TCL7226, 3 bits d\'adresse démultiplexeur, 1 bit validation démultiplexeur soit 14 bits/fils utilises simultannement! Cela fait beaucoup, mais c\' est une solution de base, on peut peut être faire mieux.
Pour économiser des bits/fils on peut utiliser des 74HCT259, registres adressables. Deux 74HCT259 fournissent 16 bits (suffisant pour commander les 8 TCL7226. Pour commander les deux 74HCT259 il faut 4 bits d\'adresse, un bit de donnée et 2 bits de commande des 74HCT259. Soit 7 bits/fils. Ce système peut être étendu facilement en utilisant des démultiplexeurs, voir le schéma sur le site AMFN (http://amfn.nice.free.fr/para/para3.htm), personnellement j\'utilise ce système pour obtenir 64 bits (8x8) pour commander les feux des signaux lumineux.
Il pourrait être aussi intéressant d\'utiliser des convertisseurs digital/analogique commandés en série et non en parallèle, il en existe avec un bus SPI (bus présent sur l\'ISBIO24).
Pierre
Pour commander un TCL7226 il faut lui envoyer SIMULTANEMENT les 8 bits de donnée, les 2 bits d\'adresse puis agir sur le bit WR pour valider la commande, cela fait 13 bits/fils pour un TCL7226.
Pour commander 8 TCL7226 les bits de donnée et d\'adresses peuvent êtres communs, restent les bits WR, il en faudrait 8, mais comme on ne commande qu\'un TCL7226 à la fois on peut utiliser un démultiplexeur 3 vers 8 qui nécessite 3 bits d\'adresse plus un bit de validation. Bilan 8 bits de donnée, 2 bits d\'adresse TCL7226, 3 bits d\'adresse démultiplexeur, 1 bit validation démultiplexeur soit 14 bits/fils utilises simultannement! Cela fait beaucoup, mais c\' est une solution de base, on peut peut être faire mieux.
Pour économiser des bits/fils on peut utiliser des 74HCT259, registres adressables. Deux 74HCT259 fournissent 16 bits (suffisant pour commander les 8 TCL7226. Pour commander les deux 74HCT259 il faut 4 bits d\'adresse, un bit de donnée et 2 bits de commande des 74HCT259. Soit 7 bits/fils. Ce système peut être étendu facilement en utilisant des démultiplexeurs, voir le schéma sur le site AMFN (http://amfn.nice.free.fr/para/para3.htm), personnellement j\'utilise ce système pour obtenir 64 bits (8x8) pour commander les feux des signaux lumineux.
Il pourrait être aussi intéressant d\'utiliser des convertisseurs digital/analogique commandés en série et non en parallèle, il en existe avec un bus SPI (bus présent sur l\'ISBIO24).
Pierre
Re: Alimentation de canton à travers le port USB
Tibrus,
Le lien est dans le mail de Pierre !
Al\'
Le lien est dans le mail de Pierre !
Al\'
-
Tibrus
- Modérateur
- Messages : 9682
- Enregistré le : 31 mai 2008 08:23
- Localisation : Dans mon sous-sol
- Epoque(s) : IV, V et VI
- Région(s) pratiquée(s) : Un penchant pour Rhone Alpes
- Echelle(s) pratiquée(s) : H0
- Contact :
Re: Alimentation de canton à travers le port USB
Honte à moi, je n\'avais jamais regardé cette section sur le site de AMFN 
M\'en vais lire cela pour m\'imprégner de leur montage
M\'en vais lire cela pour m\'imprégner de leur montage
Re: Alimentation de canton à travers le port USB
Bonsoir Pierre,
J\'ai du faire une mauvaise manip\' car mon message d\'hier n\'est pas présent, pourtant, je l\'avais fais dans le foulée de celui de Tibus, mais comme je n\'ai pas vérifié ...
Je reprends mes notes et :
1) Je n\'avais pas fais attention qu\'il fallait alimenter simultanément toutes les infos du TLC
2) Ok pour les 14 fils / bits. Mais quel demux utiliser ? type 74HCT238 mais avec un bit de commande ?
3) J\'ai du loupé une étape pour piloter les deux HCT259 : 1 bit de donnée = ok, 2 bits de commande (1 pour chaque hct ) = ok, 4 bits d\'adresse, là je ne suis plus !
Merci de me corriger : dans ce type de montage, les bits d\'adresse (3) sont communs aux deux hct, 1 bit LE pour chaque hct (donc 2) et 1 bit commun pour la data (0 ou 1). Donc un hct pour les data 8 bits communs au TLC, 2 bits sur l\'autre hct pour l\'adresse (0 à 3) des TLC, 3 bits pour l\'entrée du 238 (?) pour le signal WR. (pas d\'autre bit avec le 238 E1 et E2 à 0 et E3 à 1 et 1 bit pour la validation du \"type 238\"
Est ce correct ?
En terme de programmation, l\'algo serait il du type suivant :
1) - hct des data :
boucle de 0 à 7 pour mettre les bits au niveau que l\'on veut (MR = 1 et LE = 0 cablé)
2) - hct adresse :
boucle pour mettre en place les bit 0 et 4 pour l\'adresse (0 à 1) des hct et le bit via le demux pour quel hct ( bits 2, 3 et 4) (MR = 1 et LE = 0 cablé)
3) - demux (238) : top d\'envoi du MR
Et là nous avons besoin de 7 bits :
- 3 pour les data en entrée des 259
- 1 pour l\'état du bit pour l\'adresse du dessus
- 2 bits pour les LE de chaque 259
- 1 bit pour valider le demux
Bon ben j\'\'espère que je vais cliquer au bon endroit !
Belle soirée
Al\'
J\'ai du faire une mauvaise manip\' car mon message d\'hier n\'est pas présent, pourtant, je l\'avais fais dans le foulée de celui de Tibus, mais comme je n\'ai pas vérifié ...
Je reprends mes notes et :
1) Je n\'avais pas fais attention qu\'il fallait alimenter simultanément toutes les infos du TLC
2) Ok pour les 14 fils / bits. Mais quel demux utiliser ? type 74HCT238 mais avec un bit de commande ?
3) J\'ai du loupé une étape pour piloter les deux HCT259 : 1 bit de donnée = ok, 2 bits de commande (1 pour chaque hct ) = ok, 4 bits d\'adresse, là je ne suis plus !
Merci de me corriger : dans ce type de montage, les bits d\'adresse (3) sont communs aux deux hct, 1 bit LE pour chaque hct (donc 2) et 1 bit commun pour la data (0 ou 1). Donc un hct pour les data 8 bits communs au TLC, 2 bits sur l\'autre hct pour l\'adresse (0 à 3) des TLC, 3 bits pour l\'entrée du 238 (?) pour le signal WR. (pas d\'autre bit avec le 238 E1 et E2 à 0 et E3 à 1 et 1 bit pour la validation du \"type 238\"
Est ce correct ?
En terme de programmation, l\'algo serait il du type suivant :
1) - hct des data :
boucle de 0 à 7 pour mettre les bits au niveau que l\'on veut (MR = 1 et LE = 0 cablé)
2) - hct adresse :
boucle pour mettre en place les bit 0 et 4 pour l\'adresse (0 à 1) des hct et le bit via le demux pour quel hct ( bits 2, 3 et 4) (MR = 1 et LE = 0 cablé)
3) - demux (238) : top d\'envoi du MR
Et là nous avons besoin de 7 bits :
- 3 pour les data en entrée des 259
- 1 pour l\'état du bit pour l\'adresse du dessus
- 2 bits pour les LE de chaque 259
- 1 bit pour valider le demux
Bon ben j\'\'espère que je vais cliquer au bon endroit !
Belle soirée
Al\'
Re: Alimentation de canton à travers le port USB
Bonjour
Autant pour moi, il ne faut bien que trois bit/fils pour adresser un HCT259 (je travaille souvent avec des démultiplexeurs 4 vers 16).
Je pense qu\'il faut utiliser un 74HCT138, la validation des TCL7226 se faisant par un passage à 0. Il faut que les sorties soient à 1 par défaut (à vérifier !)
Algo :
- positionner les 8 bits de donnée pour les TCL7226 dans le premier HCT259
- positionner les 2 bits d\'adresse pour les TCL7226 dans le deuxième HCT259
- positionner les 3 bits d\'adressage sélectionnant un des 8 TCL7226 dans le deuxième HCT259 (ces 3 bits sont utilisés par le 74HCT138 pour choisir un des 8 TCL7226 à valider)
- inverser dans le deuxième HCT259 le bit qui valide le 74HCT138 (bit E1 ou E2 ou E3) première fois
- inverser dans le deuxième HCT259 le bit qui valide le 74HCT138 (bit E1 ou E2 ou E3) deuxième fois
- c\'est fini
Les deux inversions successives vont générer en sortie du 74HCT138 un 0 qui validera le bon TCL7226, puis un 1 qui le dévalidera (pour pouvoir utiliser un autre). Choisir pour le 74HCT138 l\'entrée E1 ou E2 ou E3 en fonction des valeurs initiales.
Les positionnements des 8+2+3 bits ci-dessus peuvent êtres optimisés en ne changeant que les bits nécessaires.
Voila, tout cela est à vérifier et à essayer.
Pierre
Autant pour moi, il ne faut bien que trois bit/fils pour adresser un HCT259 (je travaille souvent avec des démultiplexeurs 4 vers 16).
Je pense qu\'il faut utiliser un 74HCT138, la validation des TCL7226 se faisant par un passage à 0. Il faut que les sorties soient à 1 par défaut (à vérifier !)
Algo :
- positionner les 8 bits de donnée pour les TCL7226 dans le premier HCT259
- positionner les 2 bits d\'adresse pour les TCL7226 dans le deuxième HCT259
- positionner les 3 bits d\'adressage sélectionnant un des 8 TCL7226 dans le deuxième HCT259 (ces 3 bits sont utilisés par le 74HCT138 pour choisir un des 8 TCL7226 à valider)
- inverser dans le deuxième HCT259 le bit qui valide le 74HCT138 (bit E1 ou E2 ou E3) première fois
- inverser dans le deuxième HCT259 le bit qui valide le 74HCT138 (bit E1 ou E2 ou E3) deuxième fois
- c\'est fini
Les deux inversions successives vont générer en sortie du 74HCT138 un 0 qui validera le bon TCL7226, puis un 1 qui le dévalidera (pour pouvoir utiliser un autre). Choisir pour le 74HCT138 l\'entrée E1 ou E2 ou E3 en fonction des valeurs initiales.
Les positionnements des 8+2+3 bits ci-dessus peuvent êtres optimisés en ne changeant que les bits nécessaires.
Voila, tout cela est à vérifier et à essayer.
Pierre
Re: Alimentation de canton à travers le port USB
Bonjour Pierre,
Pour le HCT138, est il possible de laisser E1 et E2 \"cablés\" à la masse et de ne \"jouer\" qu\'avec un bit/fil pour E3 initialisé à 0 pendant le chargement, puis le faire passer à 1 et retomber à 0 ?
Concernant l\'optimisation, c\'est à dire ne bouger que les bits nécessaires, est elle vraiement nécessaire et utile en terme de delai / timout par rapport à une moulinette comparant l\'état source et l\'état cible ... ?
Comme vous le dites, à essayer ! Donc à moi de jouer !
Autre point, quels outils utiliser vous pour le développement ? C / C++ / VB / Delphi ...
Merci
Al\'
Pour le HCT138, est il possible de laisser E1 et E2 \"cablés\" à la masse et de ne \"jouer\" qu\'avec un bit/fil pour E3 initialisé à 0 pendant le chargement, puis le faire passer à 1 et retomber à 0 ?
Concernant l\'optimisation, c\'est à dire ne bouger que les bits nécessaires, est elle vraiement nécessaire et utile en terme de delai / timout par rapport à une moulinette comparant l\'état source et l\'état cible ... ?
Comme vous le dites, à essayer ! Donc à moi de jouer !
Autre point, quels outils utiliser vous pour le développement ? C / C++ / VB / Delphi ...
Merci
Al\'
Re: Alimentation de canton à travers le port USB
Bonjour
Pour le HCT138, on peut mettre E1 et E2 à la masse et jouer sur E3.
Pour l\'optimisation, une moulinette optimisant les envois est beaucoup plus rapide que le temps d\'envoyer le bit par l\'USB. Mais tout est relatif, si cela va assez vite d\'envoyer tous les bits, pourquoi pas.
Je ne développe plus sur PC, je suis sur MAC et de toute façon en Java.
Pierre
Pour le HCT138, on peut mettre E1 et E2 à la masse et jouer sur E3.
Pour l\'optimisation, une moulinette optimisant les envois est beaucoup plus rapide que le temps d\'envoyer le bit par l\'USB. Mais tout est relatif, si cela va assez vite d\'envoyer tous les bits, pourquoi pas.
Je ne développe plus sur PC, je suis sur MAC et de toute façon en Java.
Pierre
