Papy.G a écrit :je vais tenter un truc, pour que ceux qui n'ont pas un niveau technique comprennent.
Oula, personnellement, j'ai passé pas mal de temps à essayer d'être explicatif et en français normal, en évitant le jargon et les références lapidaires à des trucs obscurs. En contrepartie, surtout quand c'est pour étudier concrètement la question des latences (à la fois côté "vieille machine" et micro-contrôleur), c'est tout de suite plus fastidieux (et bourratif) que les déclarations mal ou pas étayées du tout auxquelles je faisais initialement réponse.
En gros, si la gestion de la matrice de touches passe par un buffer de port parallèle (PIA…), on peut espérer faire quelque chose simplement à base de microcontrôleur (rapide et programmé en code machine), mais si la matrice est mappée directement en mémoire, c'est mort, le temps de réponse risque d'être bien trop lent.
Je vois pas forcément la distinction entre PIA et "matrice mappée directement en mémoire", je m'explique (comme je peux) :
Les registres du PIA ne sont pas à proprement parlé en RAM, bien qu’adressés de la même manière par le CPU (via le bus partagé notemment par ces trois circuits/acronymes de trois lettres que je viens d'énumérer
).
Côté processeur, il ne s'agit que d’adresses qu'il va interroger sur le bus, chaque puce étant "câblée" pour répondre aux adresses qui la concernent, que ce soit le PIA, la ROM, la RAM, un gate-array...
Pour ce qui est du PIA, le contenu de ses registres, utilisés comme de simples "cases mémoire" côté programmeur, correspond immédiatement à l'état de ses lignes d'entrées/sorties lorsqu'il est interrogé, et par extension, on peut dire que ces lignes sont "mappées" en mémoire.
En ce qui concerne les fonctionnements que je connais (juste pour les avoir un peu étudié à l'occasion de cette discussion), la matrice clavier du PET et du MO5 est plus ou moins reliée en direct, parfois juste au travers de codeurs/décodeurs (qui permettent d'activer ou de lire une ligne à la fois, ce qui est suffisant pour chaque étape du "scan") donc le lien est quasi-instantané avec le registre, sans "bufférisation"ou cycle supplémentaire.
Mais ce n'est pas "mort" puisqu'il s'écoule un certain nombres de cycles d'horloge processeur (d'au plus quelques MHz pour les micros de cette génération) entre le moment où le processeur active un registre et en "capture" un autre, et c'est pour ça que je m'attardais à compter les cycles des routines en ROM (juste en me référant à la documentation, dans la mesure de mes faibles connaissances en la matière). Dans la plupart des cas, les instructions de lecture et d'écriture se suivent immédiatement dans le code, alors selon la vitesse du processeur ça laisse plus ou moins de marge de manœuvre avec un microcontrôleur qui exécute des instructions quelque dizaines de fois plus rapidement.
(pour le PIA du MSX, c'est la même chose sauf que ça se complique parce qu'après lui, l'électronique dédiée à sa gestion d'un bus bidirectionnel va temporiser l'activation de la matrice du clavier, ce qui raccourcit encore le délai au niveau du connecteur externe).
N'existe-il pas de composant ... où l'on puisse écrire avec le microcontrôleur des octets correspondants à la matrice...
S'il était bien question d'un tel composant plus haut dans cette discussion, pourquoi ne pas s'en servir au lieu de s'exposer aux risques liés à des timings limite.
Oui, il en était tout à fait question puisque coconuts avait évoqué dès le départ son usage dans des circuits de simulation de clavier existants (dont les siens), et j'avais par la suite décrit son fonctionnement : le "crosspoint zarlink" (ou plus communément "analog switch array").
Ca parait en effet le plus simple, puisqu'on n'a pas à se soucier des contraintes de réactivité côté ordinateur, surtout quand on s'occupe déjà de simuler logiciellement du PS/2 (ce qui est moins un problème quand on utilise une interface en partie gérée matériellement, genre UART, SPI, ou USB quand c'est le cas).
Mais à la différence d'un clavier, je ne crois pas qu'il soit équipé de diodes pour éviter les phénomène gênants de touches "fantômes" ou de "masquage" (voir les multiples explications disponibles sur Internet, par exemple
http://www.dribin.org/dave/keyboard/one_html/) qui se produisent lors de l'usage simultané de plus de 2 touches (d'après son manuel, le clavier du MSX PX-7 en a quelques unes pour gérer spécifiquement les combinaisons du type [GRAPH]+[SHIFT]+[autre touche sur les mêmes colonnes que les deux précedents]).
On peut aussi se servir d'un petit FPGA ou CPLD pour simuler efficacement la matrice, mais utiliser un programme dans un microcontrôleur (éventuellement accompagné de petits composants et circuits logiques plus basiques), en plus d'apporter plus de facilité et une souplesse dans la (re)programmation de l'interface série, relève davantage de l'économie de composants et tout simplement de moyens qui caractérise depuis toujours toute la production électronique, même la plus simple, et d'ailleurs un certain Steve Wozniak a connu un certain succès avec ce genre de complication (ou raffinement, c'est selon), alors qu'il se serait moins pris la tête en utilisant une puce dédiée à la gestion de tel ou tel périphérique, pour un surcoût très relatif... tout ça pour se la péter, évidemment !
)
quelle ruse ? ah c'est au conditionnel, je suppose 
).
