connecter un clavier ps/2 ou usb sur ancienne machine

[coconuts]

Programmez les avr en assembleur et vous aurez résolu les problème de timing de 1 ou plusieurs bits...

Par contre que se passe t'il si le clavier d'origine et l'avr sont connecté en direct sur le scan clavier (pia/via)
et que l'utilisateur utilise le clavier d'origine...

[Papy.G]

Il faut des sorties trois états et des résistances de tirage faible, sinon, passer par des portes logiques ou.

[Papy.G]

Je viens de voir que le sujet avait été déplacé dans cette rubrique, merci aux admins pour leur écoute et/ou leur intérêt, c'est sympa.

Je l'ai déplacé ici pour la postérité, mais c'est embêtant pour certains habitués qui tiennent à ne pas s'inscrire (Coconuts, par exemple), qui doivent poster comme un nouveau sujet en section "de passage" à chaque réponse qu'ils veulent ajouter, les modérateurs réintégrant automatiquement ces interventions dans le sujet de destination.

ok très bien, c'est juste que comme tu disais exactement "...passe par un buffer de port parallèle (PIA…)," , tu laissais entendre (pas forcément ton intention) que c'était une caractéristique propre aux PIA mentionnés, sans quoi je ne me serais pas embêté à démontrer concrètement le contraire

Non, je ne pensais qu'aux PIA en général, mais j'ai mis des points de suspensions, ne sachant pas s'il arrive qu'on les nomme autrement.

Je ne sais pas à quelle autre machine tu opposes ce fonctionnement, mais c'était bien le cas que j'ai explicité pour ces ordinateurs. Plus précisément (au risque de me répéter un paquet de fois) c'est généralement une écriture dans un registre suivie immédiatement d'une lecture dans un autre. Le reste des observations présentées concernant le fonctionnement matériel n'étaient d'ailleurs pas des impressions, mais faites après une étude attentive des schémas électroniques et de la documentation de ces circuits intégrés (même si je peux comprendre de travers ).

En fait, lors de l'étude technique du Minitel 1B Alcatel, je me suis rendu compte que les broches utilisées pour le scan de la matrice clavier, des broches d'IO utilisées comme avec un PIA, (on écrit les bits dans les registres de sortie, puis l'on interroge le registre d'entrée) pourraient être utiles en cas de lecture de carte SD ou tout autre périphérique SPI à cause de leur spécificité (interruption, impulsions compteur…), j'envisageais donc d'adresser les lignes de la matrice clavier dans l'espace d'adressage RAM et en direct, ce qui aurait simplifié et accéléré les routines de scan.
Je pensais que les anciennes machines, surtout quand elles n'utilisent jamais l'espace d'adressage complet pour leur RAM et ROM, faisaient systématiquement comme ça quand le clavier est interne.

J'ai essayé, pour faire avancer la discussion, de quantifier concrètement ces contraintes de timings, parce que je trouve ça plus constructif et positif (moins démotivant que "ça peut s'avérer tendu" et moins définitif que "c'est mort" sans confirmation du médecin légiste )

C'est tout à ton honneur, je n'ai pas eu le courage de me pencher sur mon sujet (à base de 8052), car mon temps de bricolage est un peu compté.
Et je suis peut-être le seul qu'une réponse aussi évasive qu'imprécise laisse entrevoir un espoir, et être motivé par le challenge que représente l'étaiement de la preuve du contraire.

En effet, pour un programme procédant plus directement (écriture puis lecture immédiate), on aurait déjà deux fois moins de temps...

J'ai essayé de retrouver des timings au cycle horloge prêt pour un 8051, je ne trouve que chez atmel, et les chronogrammes sont incomplets, il semble que l'adresse complète n'est présente que trois cycles, et les données ne sont lues ou disponibles que pendant 7 cycles, dix cycles à 12MHz, ça fait 13,3 cycles au mieux à 16MHz. (Ca reste de l'approximation, mais ça donne quand-même un ordre d'idée plus précis)

[nicolho]

Content de continuer cet échange, parfois critique, mais pour ma part, pas de problème tant que ça reste cordial et honnête.

...j'envisageais donc d'adresser les lignes de la matrice clavier dans l'espace d'adressage RAM et en direct, ce qui aurait simplifié et accéléré les routines de scan.

C'est juste que je ne comprenais pas pourquoi tu avais soudainement introduit cette ambiguïté en ramenant tout mon raisonnement à des machines (non-identifiées) qui fonctionneraient différemment, alors que je parlais de la même chose que toi, et toujours du même cas de figure (pas limité au PET) : des matrices en quelque sorte "mappées" en mémoire, pour reprendre ta terminologie, où chaque bit d'un registre correspond à l'état immédiat (si on excepte la latence de propagation dans les circuits, négligeable à cette échelle) d'une ligne en sortie, connectée à la matrice, c'était exactement le cas étudié, et pas du tout un autre.

Et je suis peut-être le seul qu'une réponse aussi évasive qu'imprécise laisse entrevoir un espoir, et être motivé par le challenge que représente l'étaiement de la preuve du contraire.

Euh, le seul ? Fort heureusement il reste des gens prêts à chercher le sens et le bien fondé des propos tenus. Dans cet ordre là, pourquoi pas, mais une réponse évasive et contradictoire faite à une argumentation étayée, c'est déjà moins engageant .
Sans vouloir polémiquer davantage mais pour qu'on se comprenne, notamment sur l’ambiguïté dont je parlais : alors que j'avais patiemment démontré la faisabilité sans problème avec des serviettes, tu étais intervenu un peu de cette manière : "je résume pour ceux qui ne s'y connaîtraient pas en linge de maison : en gros, c'est possible avec les torchons, mais avec les serviettes, c'est mort !". Enfin, sans rancune...

Maintenant, pour en revenir à nos moutons, le 8051 dont tu parles, c'est plutôt 'un microcontrolleur de chez Microchip (et oui ! je viens juste de me rendre compte que Atmel, sasdipu ! ) à 12 Mhz, peut-être un AT89 : https://en.wikipedia.org/wiki/Atmel_AT89_series ?
Pour mémoire, ce jeu d'instuctions est originellement celui d'une célèbre famille de "microcons" des années 80 les Intel MCS-51 ( https://fr.wikipedia.org/wiki/Intel_8051 ) qui avaient déjà cadencés à 12MHz. Peut-être que, pour le calcul des cycles, tu t'es référé à la documentation existante pour celui-ci (je pensais à la page 25 de ce pdf du datasheet http://web.mit.edu/6.115/www/document/8051.pdf , parce que les timings que tu évoquais font davantage penser aux périodes de lecture/écriture sur le bus).

Là encore, c'est plutôt ambigu, parce que tu mentionnes ATMEL, qui a produit des "compatibles 8051" depuis les années 90, toujours en vogue de nos jours surtout parce que ce constructeur les a depuis longtemps améliorés pour leur faire disposer du même avantage que ses célèbres AVR, à savoir : une nouvelle instruction exécutée à chaque cycle ! (3ème fois que j'en parle dans ce sujet )

Enfin admettons, on dirait que tu as voulu calculer le délai que celui-ci mettrait à faire lui-même un "scan clavier" à la manière des vieux ordis (également en comptant le temps qui lui faudrait pour effectue une lecture + une écriture en mémoire, je suppose). Et dans ce cas de figure théorique, je suis d'accord, ça semblerait trop court si on voulait répondre à ce "scan clavier" dans les délais pour simuler la matrice avec une puce similaire à une fréquence légèrement supérieure (le cas très pessimiste que tu évoquais), et ça peut "s'avérer un peu tendu" avec un AVR 16MHz et ses instructions en 1 cycle (disons environ 10x plus rapide pour les 10 cycles à 12Mhz dont tu parlais, donc encore loin du ratio 120x par au 8 cycles du PET à 1MHz pour lequel je disais que ça me paraissait complètement faisable).
Alors en effet, pour avoir une bonne marge de manœuvre avec le délai que tu as calculé, comme on l'a dit ça nécessiterait d'utiliser une puce opérant nettement plus vite au niveau instructions/secondes. Pourquoi pas, c'est pas le choix qui manque, même si c'est souvent sensiblement plus cher, ça reste tout à fait abordable.

En gros, je résume : ça suffirait pour un vieux 8051, mais pour les versions "1 cycle/instruction", c'est mort ! Enfin pas forcément, mais du coup on risquerait de reparler d'utiliser (entre autres) un Raspberry Pi et de donner finalement raison à coconuts :

je vous laisse jouer avec un raspberry pi et du javascript...
puisque quand on lit les forum ça semble être la solution a tous les problèmes...

ah oui, bonne idée, histoire de participer à la branchouille web, ça pourrait peut-être même se faire en javascript, avec un Espruino : https://www.espruino.com/ , sérieusement !

[coconuts]

j'ai beaucoup plus simple:

on fait une pile de tous les claviers, tous les commodres toutes les vielles machines...
on prend un rouleau compresseur... on reduit le tout en bouillie
on passe le tas de detritus a la benne...

on prend le raspberry et on install vice...
dans le fond pourquoi s'emmerder avec un vieux commodore...

[Papy.G]

Certes, et d'ailleurs, pourquoi s'entêter à utiliser tous ces logiciels obsolètes?

Je pense que, finalement, vous êtes assez d'accord: lorsqu'un clavier est absent ou irréparable, il est intéressant de le remplacer, quand on le peut seulement avec un AVR programmé proprement, sinon, avec un petit crosspoint en plus et c'est bon.

Maintenant, pour en revenir à nos moutons, le 8051 dont tu parles, c'est plutôt 'un microcontrolleur de chez Microchip (et oui ! je viens juste de me rendre compte que Atmel, sasdipu ! ) à 12 Mhz, peut-être un AT89 : https://en.wikipedia.org/wiki/Atmel_AT89_series ?
Pour mémoire, ce jeu d'instuctions est originellement celui d'une célèbre famille de "microcons" des années 80 les Intel MCS-51 ( https://fr.wikipedia.org/wiki/Intel_8051 ) qui avaient déjà cadencés à 12MHz. Peut-être que, pour le calcul des cycles, tu t'es référé à la documentation existante pour celui-ci (je pensais à la page 25 de ce pdf du datasheet http://web.mit.edu/6.115/www/document/8051.pdf , parce que les timings que tu évoquais font davantage penser aux périodes de lecture/écriture sur le bus).

Merci pour ce rappel, mais Microchip n'existait pas encore quand mon Minitel a été fabriqué.
En fait, il n'était pas question d'utiliser un 8051 pour faire l'interface, mais j'essayais d'avoir une idée de grandeur du temps de réponse nécessaire si je devais mettre une interface dans un minitel équipé d'un 8052/32 à 12MHz, courant à l'époque (Intel, Siemens, Philips…), qui aurait reçu la modification dont je parlais plus haut.
Merci pour le lien, je n'avais pas trouvé de PDF propre des docs intel auparavant, donc, j'avais récupéré une doc Atmel et lu les timings en mode "legacy", douze oscillations par cycle instruction, faute de mieux. Dans ta doc, je ne me suis pas servi des temps de cycle par instruction, mais du temps de cycle horloge nécessaire à une lecture sur le bus de données externes, donc plutôt la section 3-34, fig.37.
Du coup, c'est pire que ce que je pensais, il y a quatre oscillations entre le passage bas de /RD, et la lecture du bus de données, sur la cinquième.

Enfin admettons, on dirait que tu as voulu calculer le délai que celui-ci mettrait à faire lui-même un "scan clavier" à la manière des vieux ordis (également en comptant le temps qui lui faudrait pour effectue une lecture + une écriture en mémoire, je suppose).

Pourquoi vouloir faire une écriture puis lecture, lorsqu'on "voit" les lignes de matrice clavier comme des emplacements mémoire, une seule instruction, de lecture, suffit à lire une ligne. Par contre, c'est vrai que le temps de faire diverses choses, la mémorisation de la touche, un debounce ou autre, l'incrémentation d'adresse pour la ligne suivante, l'AVR a le temps de préparer des données, mais c'est un autre sujet, il me semble.

…on risquerait de reparler d'utiliser (entre autres) un Raspberry Pi et de donner finalement raison à coconuts :

je vous laisse jouer avec un raspberry pi et du javascript...
puisque quand on lit les forum ça semble être la solution a tous les problèmes...

ah oui, bonne idée, histoire de participer à la branchouille web, ça pourrait peut-être même se faire en javascript, avec un Espruino : https://www.espruino.com/ , sérieusement !

Je crois bien que coconuts était ironique.

Sauf, peut-être à propos de l'Espruino, je ne sais pas exactement ce que c'est, ni ses possibilités.
En fait, ça m'évoque la contraction de espéranto et Arduino, ce qui me laisse dubitatif quant au sérieux du truc et/ou ses perspectives d'avenir.

[nicolho]

vous êtes assez d'accord: lorsqu'un clavier est absent ou irréparable, il est intéressant de le remplacer, quand on le peut seulement avec un AVR programmé proprement

Tu dis "vous êtes d'accord', un peu comme si tu nous renvoyais dos à dos . Alors même si on échange des infos intéressantes, ce que je regrette c'est que tu résumes des conversations que tu n'as visiblement pas forcément bien suivies dans le détail et je si comprends très bien qu'on lise en diagonale, c'est un peu ch*ant de voir ses intentions ou ses propos déformés (d'où mon usage un peu systématique des citations). En plus, à force d'en être réduit à dire "ça a déjà été dit" ou "non, ce n'est pas du tout ce qu'on a dit", je passe pour un radoteur (désolé), enfin j'arrête de chouiner.

Personnellement, je le répète une dernière fois : je ne faisais que répondre aux questions du l'usage possible d'Arduino (c'est pas moi qu'a demandé ) et corriger des affirmations techniques un peu péremptoires, en essayant d'apporter un peu de concret et de bon sens (pour des exemples pratiques, même encore plus "tendus", j'en ai en magasin mais quel intérêt quand les spécifications suffisent?), et ce n'est pas du tout mon intention de remplacer aucun clavier.

un petit crosspoint en plus et c'est bon.

euh, le crosspoint, ce n'est pas la panacée non plus, par exemple ça peut être un problème avec les jeux dans lesquels on est amené à se servir de pas mal de touches simultanément. Qu'en penses tu, par rapport à ce que j'avais déjà dit au sujet du crosspoint ? :

à 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.

Ok pour ton minitel modifié, ça aide à comprendre ta démarche

Dans ta doc, je ne me suis pas servi des temps de cycle par instruction, mais du temps de cycle horloge nécessaire à une lecture sur le bus de données externes, donc plutôt la section 3-34, fig.37.
Du coup, c'est pire que ce que je pensais, il y a quatre oscillations entre le passage bas de /RD, et la lecture du bus de données, sur la cinquième.

Oui, merci d'avoir précisé ta source exacte, les deux schémas montrent exactement la même chose (seule différence, celui que tu as trouvé a l'avantage de nous présenter également les cycles d'horloge). Donc c'est bien ce que je disais, tu a regardé les temps d'accès sur le bus, en lecture dans le cas que tu décris, et donc les temps impartis à la mémoire pour présenter ses données au processeur.

Mais je ne vois toujours pas bien le rapport puisque, on l'a dit et redit, ce qui nous intéresse en premier lieu, c'est l'écart entre le moment où la matrice va être "écrite" (par exemple : activation de d'une colonne) et le moment où elle va être "lue" (sur ses lignes). Donc c'est le temps d’exécution total, qui sépare ces accès au bus (de 2 instructions à la suite) qui nous est imparti pour répondre au scan de la première ligne (pour les suivantes, pas de problème puisque qu'on active toutes les lignes d'un seul coup).

Sauf, peut-être à propos de l'Espruino, je ne sais pas exactement ce que c'est, ni ses possibilités.
En fait, ça m'évoque la contraction de espéranto et Arduino, ce qui me laisse dubitatif quant au sérieux du truc et/ou ses perspectives d'avenir.

Oh, tout de suite négatif... C'est vrai que ça semble difficilement adapté à ce dont on parle (et encore, faudrait voir) et qu'il y a un côté un peu gadget, puisqu'un langage interprété est souvent considéré comme inefficace et un peu "too much" pour un micro-contrôleur... par contre, sur des vieux micro encore moins puissants, on aime bien faire du BASIC même si ça laisse beaucoup de gens dubitatifs (et on peut le comprendre)

Pour info : suite au succés foudroyant de la campagne Kickstarter qui avait initié le projet, quelqu'un près de chez moi me l'avait présenté fin 2013 (donc ça fait un petit moment que ça draine du monde, le développement est désormais mâture et se poursuit). C'est essentiellement une console javascript qui permet d'utiliser les périphériques du micro-contrôleur sur laquelle elle tourne : GPIO, UART, timer, I2C, SPI, etc.. et maintenant de nombreuses librairies couvrent l'usage de modules et capteurs les plus répandus.
Par conséquent, on peut aussi programmer en temps réel depuis un terminal série, ca qui est bien pratique pour tester des choses.
Bon, ça se destine aux fans de javacript, mis à toutes les sauces et envisagé comme langage universel, mais je n'avais pas fait le rapprochement avec l'Esperanto, tu as raison, ça doit être à l'origine du nom, bien vu !

Depuis, j'ai suivi ça de loin, bien que la communauté reste restreinte, ça semble mené par des gens très compétents, la documentation en ligne avec de très nombreux exemples est excellente. Et, comme quoi ils ne sont pas là pour vendre absolument leur carte maison (au prix somme toute raisonnable), ils donnent même des information pour installer leur firmware javascript sur d'autres cartes de développements populaires et moins chères (comme certaines Nucleo STM32).