74hc540

[vs2prod]

Bonjour,

je dois "scanner" 256 entrées logiques le plus rapidement possible (modification de console d'orgue à tuyaux).

je ne peux pas utiliser des registres à décalage et une liaison SPI car je veux minimiser le temps de scrutation.(réduction de la latence au maximum)
je ne peux pas utiliser un système a matrice non plus.

je pense utiliser des 74HC540. Sur les 8 entrées de chaque 74HC540 seront connectés des capteurs a effet hall détectant la position de la touche. les huit sorties de chaque CI formeront un bus de "data" qui seront sur le port D d'un pic.
je vais donc avoir 256/8 soit 32 74HC540 dont les sorties vont être en parallèle.

sachant qu'il n'y aura qu'un seul 74hc540 qui sera "activé" a la fois par la validation des entrée OE1 et OE2, et que les autres seront en sorties haute impédance, est ce raisonnable de mettre ces 32 sorties de circuit en parallèle ?

merci pour votre avis !

un bout de schéma avec seulement 7 circuits.

-----

[jiherve]

Bonsoir,
tant que les charges sont CMOS il n'y a pas de probleme si ce n'est qu'il ne faudra pas aller trop vite car chaque bit du bus sera chargé par environ 400pF donc les transitions seront mollassonnes.
JR

[Qristoff]

Salut,
pourquoi fermer la porte aux liaisons séries qui peuvent vraiment êtres très rapides ! par exemple, avec les port I/O intégrés en 40 bits avec gestion des interruptions comme ici, ça peut aller vraiment très vite ! (toujours plus qu'avec des 540...)
En plus, tu peux avoir une gestion intelligente par interruption !

[jiherve]

Re
Avec de l'I²C à 400Khz il faudra au minimum 640µS (hors emballage) pour transmettre 256 bits, avec sa solution même en multiplexant à 100kHz(ce qui est très pessimiste) il ne faut que 320µS.
Une solution // est toujours plus rapide qu'une solution série mais toujours plus encombrante.
Maintenant la question qui tue est : quelle est la latence admissible car il y a tout de même un bonhomme dans la boucle , l'organiste, qui ne doit pas pouvoir faire beaucoup mieux que 100ms entre action.
JR

[A voir en vidéo sur Futura]

[vs2prod]

+1 pour JR !

j'ai de la place dans l'orgue !

Et oui en SPI ou I2C c'est plus long (j 'ai déja fais des essais).
la latence s'entend non pas pour la vélocité de l'organiste mais pour le temps qui se doit le plus court possible entre le moment ou l'on appui sur la touche et le moment ou la soupape (un genre d’électroaimant) libère l'air vers le tuyau.

sachant qu'il y un traitement dans le pic pour aiguiller les entrées(clavier) vers les sorties(électroaimant) suivant les jeux enclenchés il faut réduite au maximum le timing !

une latence maxi de 40 ms est admise. sachant que les claviers peuvent être a 10 mètres des tuyaux et la vitesse du son 340m/s on a vite une latence "naturelle" qui peut être gênante pour l'organiste (essayez de parler dans un micro casque avec votre voix en retour dans ce casque décalée de 100ms !)

pour Qristoff: je dois rester dans des circuits pas trop exotiques pour une maintenance aisée, c'est pour aussi cette raison que j'ai exclu les expandeurs de port en liaison i2c ou autre.

[Qristoff]

Salut,
Effectivement l'I²C est un peu lent pour l'application. Tu peux utiliser des registres 74HC165 montés en série, et avec une rafale de 256 coups d'horloge à 10MHz, tu récupères toutes les entrées en série en 25µs.
Avantage: pas besoin d'adressage !

[jiherve]

Bonjour
en effet c'est une autre solution, présentant un encombrement similaire.
Donc coté capture du clavier il n'y a pas vraiment de soucis de latence, reste la partie software, qui, je l'espère est codée en assembleur.
JR

[Qristoff]

Les gros avantages que je vois:
- pas besoin d'adressage des 32 circuits 74HC165 en série
- pas de décodage/matriçage au niveau logiciel
- suppression des 4 x 74HC138
- simplification câblage