Je ne trouve plus assez de temps en soirée pour mener à bien comme je le souhaiterais mes développements en cours. Au fur et à mesure des avancées je finirai bien par retrouver l'équilibre, mais pour l'instant c'est un peu la course tous les soirs, surtout quand je me retrouve confronté à des petits problèmes qui consomment gentiment leur paire d'heures.
Dans la série nouveau circuit imprimé à monter et à tester, j'ai nommé le switch M.I.D.I. :
Ici encore, ce n'est pas du circuit imprimé de haute qualité (le design, pas la fabrication), mais cela devrait suffire pour effectuer les premiers tests. Le processeur de ce montage est cette fois-ci un membre de la famille PIC32 ainsi qu'un circuit externe contenant 4 ports série. Chaque switch comportera donc 5 ports série dont un dédié à un fonctionnement particulier...
Le projet de circuit de diagnostic pour la boîte à rythme Drumulator avance bien. Le plus gros des tests est implémenté. J'en ai encore d'autres à intégrer. Le développement sur ce système ne pose plus de problème depuis que ma carte électronique a été corrigée (voir post précédent) et que l'environnement de développement et de programmation du processeur fonctionne bien. La majorité des routines de bases étant écrites, l'écriture de code s'en trouve simplifiée. Un petit aperçu :
Parallèlement je 'tente' de démarrer une 'copie' de la Drumulator dans un FPGA. Parce qu'à étudier la machine comme je le fais, il me devient possible d'en tenter l'implémentation en logique programmable. Pour l'instant j'ai traduit une Drumulator 'very' minimum dans le FPGA mais l'affichage ne démarre pas sur son sempiternel 'Bad', ce qui pour une fois m'arrangerait bien, malgré la nature du message ;-)
21 novembre 2016 : un petit pas pour... moi ;-)
Après quelques difficultés à donner vie au 'cœur' processeur de la Drumulator sur une carte FPGA, le dernier caractère de la chaine 'bad', le 'd', s'affiche enfin. Pourquoi le dernier? Je pense que la personne ayant programmé la routine d'interruption de gestion de l'affichage à utilisé le mode décrément plutôt qu'incrément. Je soupçonne fort que le système a été développé en assembleur et non pas en 'C'. Et les 'habitués' se rappelleront qu'il est plus facile de faire un test sur zéro, que de tester une valeur. C'est une soustraction de moins à coder! Ce qui n'empêche que j'ai des problème de réarmement de l'interruption sur les routines que je code en VHDL pour émuler le CTC. Mais bon, je vais y arriver ;-)
22 novembre 2016 : pas difficile, en fait.
J'avais effectivement un petit problème de réarmement des interruptions sur l'émulation du CTC que je code en VHDL. Une relecture de la doc de ce composant m'a permis de comprendre mon erreur. Et puis aussi un petit souci sur le code de retour des touches 'virtuelles' appuyées, ou plutôt non appuyées étant donné que je n'ai pas encore codé cet élément et qu'il me faut donc émuler le bon code au bon moment pour signifier au programme qu'aucune touche n'est appuyée. Et comme les concepteurs de la Drumulateur n'ont pas hésité à ajouter une petite gâterie, forcément, je suis tombé dans le panneau ;-) Mais bon, malgré la difficulté que représente toujours la première mise en service d'un 'corps' étranger dans un fpga puisqu'on fonctionne pour beaucoup à l'aveugle, le cœur de cette boîte à rythme fonctionne à priori correctement dans ce gros circuit Altera :
 |
| Message d'invite lorsque la RAM n'es pas sauvegardée... |
Petite réflexion du jour : histoire de tester quelques algorithmes avant de passer à leur programmation dans ma carte de test (circuit prenant la place du Z80) de la Drumulator, j'ai voulu utiliser le PC pour exécuter quelques lignes de code C. Parce que moi, le C++ ou le C#, en programmation micro-contrôleur, ça ne m'est pas bien utile. J'ai donc tenté la version gratuite du C 'crosoft'. Le constat est toujours le même : des gigas de téléchargement, des possibilités infinies, et au final, impossible de faire du C en mode console. Évidemment, il n'est pas de l'intérêt de 'crosoft' de permettre encore ce genre de chose sous leur système, bien que 'crosoft' soit en train de permettre l'utilisation d'Unix sous windowsx!!! Mais bon, une fois de plus, je constate que l'intérêt de l'utilisateur passe au ixième plan dans la stratégie commerciale de 'crosoft'. J'ai donc supprimé l'installation de cette chose énorme (près de 10Go de fichiers et pas loin de 50 'programmes' devant être désinstallés à la main : serveur web, serveur sql, serveur de déploiement, x versions du .net, etc etc. Une totale invasion. Comme d'aucuns peuvent le dire, un super méga virus, en fait! Chance, après avoir 'à peu près' tout désinstallé, le système fonctionne toujours, et pas un message d'erreur : INCROYABLE!) et inutile pour passer à Code::blocks. 75Mo à télécharger, du C en mode console de façon tout à fait normale, du débogage temps réel bien fait, bref, tout ce qu'il faut pour être opérationnel en quelques minutes seulement sans contraintes matérielles ou logicielles. Un outil fait pour ceux qui ont besoin de se prendre la tête avec leur code, et pas avec une stratégie commerciale douteuse et pénible depuis des... décennies!
Tout ça, pour implémenter le DUMP mémoire de la ROM. Et oui, comme mon système comporte sa propre ROM programme puisqu'il s'agit de la flash du processeur Atmel, il n'y a plus besoin de ROM externe pour le fonctionnement du système de diags. Du coups comme les bus sont libres, cela permet de lire la ROM au même titre que n'importe quel composant de la carte de la Drumulator. Il m'est donc possible de calculer en même temps le checksum de la ROM et donc d'en vérifier l'intégrité de son contenu. Petite fonctionnalité impossible avec le système de diag originel de chez E.M.U.
Je vais mettre maintenant en pause ce travail autour de la Drumulator parce que j'en suis arrivé au moment ou il est nécessaire de comprendre et j'espère émuler le fonctionnement du micro-séquenceur de génération sonore de la machine. Je n'ai pas trouvé d'infos à ce sujet sur le net, et les explications fournies par E.M.U. dans sa donc est forcément... succincte! Quelques tests à l'analyseur logique s'imposent donc.....
En ce qui concerne la perte de 'paires d'heures' qui arrive parfois, voici une petite mésaventure survenue lors de la ré-écriture du code de test des afficheurs de la Drumulator. Les afficheurs d'origine, des TIL312, ne sont pas très lumineux. Comprendre que pour obtenir un 'éclairage' suffisant, il est nécessaire de leur injecter un certain courant. Je n'ai pas mesuré ceux présents sur la Drumulator, peu importe, seule le principe compte (2,8W sous 10V quand même, affiché sur mon alimentation de laboratoire, pour un afficheur allumé au complet à 20% du temps).
Ce courant, vu la taille des résistances de limitation est de toute façon important, puisque ces résistances sont au moins des 5W. Retenir que ce courant est potentiellement dangereux pour les afficheurs. Or, le système d'affichage étant multiplexé, chaque afficheur, et LEDs puisque le groupe de LEDs est traité comme un afficheur, n'est allumé QUE 20% du temps. Donc, pas de problème.
SAUF que pendant mes développements, il m'est arrivé de stopper le processus de test alors qu'un afficheur était alimenté, en l’occurrence l'afficheur de droite. Et au bout 'd'un certain temps', une odeur de chaud puis une légère fumée s'est dégagée de la carte de la Drumulateur. J'ai tout éteint immédiatement évidemment, et ai tenté de trouver l'origine du problème. L'odeur venait effectivement de la zone d'affichage. Je suspectait peut-être le 'claquage' d'un transistor de commande.
Au lancement du test suivant, je m'aperçus de suite que le segment horizontal du bas de l'afficheur de droite ne s'allumait plus, le segment D. Pas normal.... mais... logique! Moins logique par contre, le segment B du même afficheur s'allumait alors que ma fonction de test des afficheurs/LEDs allumait les LEDs, justement, et pas l'afficheur de droite : très étrange.
Après quelques instants de réflexion, le test de la résistance du segment D de l'afficheur de droite m'indiquait une résistance inférieur à 10Ohms, donc pratiquement en court-circuit. Et l'explication de l'allumage du segment B devint évidente :
Or donc, quand le segment B des LEDs est commandé (bien qu'il n'y ait pas de LED branchée sur ce segment), les autres segments sont éteints, donc à '1'. Le courant part donc du signal CATH0 (correspondant au segment D), traverse le segment D défectueux de l'afficheur de droite et alimente donc l'ensemble de l'afficheur. L'afficheur ainsi alimenté par une alimentation 'fantôme', est en mesure d'alimenter le segment B du même afficheur, lorsque le signat CATH4 est à '0', signal correspondant au potentiel segment B des LEDs. La raison pour laquelle cela n'arrive qu'avec le segment B est que justement, il n'y a pas de LED branchée sur ce segment. Le courant ne trouve donc pas un chemin 'plus facile' pour s'évacuer, et passe donc par le segment B de l'afficheur de droite.
Depuis, j'ai non seulement remplacé l'afficheur défectueux, mais aussi fait en sorte que le signal CATH4 correspondant au segment B soir toujours à '1' lors que j'adresse les LEDs. Parce que lors du remplacement de l'afficheur, je me suis rendu compte que le transistor de d'alimentation de commande de l'afficheur de droite n'était pas totalement bloqué, et qu'une très légère lueur apparaissait sur le segment B de ce nouvel afficheur lors que j'adresse les LEDs. Je n'ai pas changé le transistor de commande, qui fonctionne bien cependant. Ses caractéristiques auraient-elles changées par un excès de courant? Possible!
Sur cette photo, l'afficheur de gauche est un modèle neuf, celui de droite est celui retiré de la Drumulator. Effectivement, ça a chauffé vers le bas de l'afficheur. Alors pourquoi uniquement ce segment, alors qu'il y en avait plusieurs d'allumés? Pas d'explication.
Et pendant que j'y suis, une petite pub gratuite pour Nikolay Nikilov de Bulgarie qui tient la boutique Electron-pv sur eBay, ou je me suis procuré quelques exemplaires de TIL312. Parce que ces TIL312 ont une particularité utilisée sur la Drumulator, les deux points décimaux. Deux point décimaux qu'il est très difficile de trouver sur des équivalents, et spécialement le point de gauche.
Scratch 2 : j'ai été sollicité pour le développement d'une solution adaptée à l'utilisation de ma carte compatible Arduino. Après m'être documenté sur le sujet, et notamment la façon dont la communication entre Scratch2 et la carte Arduino était réalisée, j'ai décidé de ne pas perdre mon temps avec ce sujet, bien que cela m'ait pris quelques heures pour pousser un peu le bouchon et 'tenter' une première approche avec ma carte.
Avis très personnel :
A mon sens, ce système est amusant, je parle de Scratch2, et totalement inutile, j'assume. D'ailleurs cela ne m'étonnerait pas que dans très peu de temps ce système ne soit plus utilisé, une fois que le buzz 'algorithme pour tous' dans l'éducation nationale sera retombé. Je ne développerait pas mes arguments. Tout juste rajouterais-je que les personnes 'vraiment' intéressées par la programmation et la réalisation d'objets autonomes sauront bien mieux atteindre leur objectif avec l'IDE Arduino, et qu'il y a un âge minimum pour cela qui n'est pas 8 ans, mais qui se situe entre 14 et 15 ans (hors cas exceptionnel et sous réserve d'un réel intérêt pour la chose), ou jamais, selon la très grande majorité des personnes... Mais bon, le 'numérique' est la boutique à rêves ("l'opium du peuple") contemporain : bien piètres objectifs!
Histoire de continuer sur ma lancée, certains établissements ont choisi l'utilisation de petits robots comme les Blue-Bot pour initier les 'jeunes' à algorithmie, c'est bien. J'ai personnellement mis à la poubelle au début des années 2000 (je vous rassure, je ne le ferais plus maintenant, et à mon grand regret je n'en ai pas conservé une seule!), un stock de tortues LOGO fabriquées par Jeulin. C'était la même chose, dans le même contexte, à une autre époque. On reprend (presque) les même et on recommence : Logo et sa tortue
L'enfumage politico-médiatique, j'avoue qu'à la longue, ça lasse ;-)
