Corona : activités d'éveil n°7, progression sur le convertisseur CV/GATE

Allez, on y croit : dernière semaine de confinement généralisé. Serait-ce le bout du tunnel?

En attendant, la semaine passée a été consacrée à la mise en place d'une procédure d’étalonnage du convertisseur CV/GATE 8 voies développé durant l'année 2019 :

L'image ci-dessus représente la dernière version de la carte développée. Je ne l'ai pas encore montée. Elle fait suite à deux autres prototypes dont celui qui sert actuellement de test pour la mise en place de la procédure d'étalonnage. La première version ressemblait à ceci :

J'ai développé une deuxième version de cette carte pour corriger une petite erreur de câblage au niveau d'un des régulateurs de tension. C'est cette deuxième version que j'ai utilisé cette dernière semaine pour développer le banc de test et d'étalonnage :

La dernière version du convertisseur CV/GATE propose un circuit imprimé plus petit, une amélioration  du schéma général pour une meilleur stabilité, et une rationalisation du fonctionnement.

Bien que les deux prototypes fonctionnent correctement, avec une linéarité tout à fait satisfaisante, la stratégie mise en place pour la calibration, elle, ne l'est pas. J'ai utilisé le principe de la fonction mathématique pour produire la valeur numérique à destination du DAC, correspondant à la note reçue par le biais de l'interface MIDI.

Le problème, est que d'une part la recherche de la bonne fonction a été très laborieuse puisque qu'à chaque fois il me fallait modifier le programme du processeur du montage, relever à la main les valeurs retournées par le DAC et vérifier la linéarité sur une feuille excel. D'un point de vue amateur, cela peut s'accepter, mais de façon plus sérieuse, cela fait quand même bricolage et surtout est trop laborieusement reproductible.

D'autre part le convertisseur utilisé ne propose pas une fonction de transfert stable sur l'étendue de sa conversion et je soupçonne que certaines caractéristiques de cette fonction dépendent aussi de chaque DAC.

J'ai donc décidé de modifier d'approche par l'utilisation d'une méthode plus 'brute force'. A savoir tout simplement l'envoi au DAC de toutes les valeurs possibles et sélectionner celles correspondant aux tensions voulues. Après tout, un clavier de piano ne comporte 'que' 81 touches donc au maximum 81 valeurs à retenir. En mettant en place une procédure automatique et rapide cela me permettra de calibrer chaque carte au mieux.

Le principe  : l'utilisation d'un PC pour gérer l'envoi des données au DAC et récupérer les tensions correspondantes. Le programme PC sélectionne automatiquement les valeurs correspondant aux notes d'un clavier standard et fabrique un fichier de correspondance à intégrer au source qui sera transféré dans le processeur de la carte. Avec de la 'chance', il ne sera peut-être pas nécessaire de répéter l'opération pour chaque carte si la dispersion du DAC n'est pas trop importante.

Le matériel :  pour l'envoi des données au DAC, et sachant que celui-ci fonctionne en bus SPI, le plus simple a été l'utilisation du Bus Pirate développé par Ian Lesnet (http://dangerousprototypes.com/). Connecté en USB sur le PC, il présente un port série standard et une configuration par simple protocole texte. J'utilise la version 3.6 :

La réception des valeurs de mesure se fait par l'intermédiaire d'un multimètre 22000 points classique et 'assez' précis de type UNI-T UT61E :

Publicité gratuite.

Ce multimètre possède l'énorme avantage de posséder une interface série opto-isolée disponible sur prise RS232C, un adaptateur USB s'avère donc nécessaire. J'utilise ceci :

Ça n'est pas l'adaptateur le moins cher, mais au moins il est correctement construit, possède les bons connecteurs ainsi que des LEDs d'indication pour l'émission et la réception.

Le multimètre utilisé envoi de façon automatique une chaîne de caractères dans un format spécifique qui ne pose aucun problème de décodage. Inutile donc de lui demander l'envoi d'une valeur, il le fait tout seul. Ce qui n'est visiblement pas le cas du FLUKE 289 que je possède par ailleurs :

Publicité gratuite.

Ce multimètre est très précis et possède aussi une interface série au protocole de type texte. Je suis bien tenté de commander son interface série pour l'utiliser dans mon banc d'étalonnage.

Le logiciel : avant toute chose, notez que je ressent une ABSOLUE AVERSION envers l'entreprise microsoft. Tant d'un point de vue technique que philosophique. Mon avis ne sera donc pas objectif. Ceci écrit, j'ai donc (à contre cœur vous l'aurez compris) décidé de développer une petite application sous windows (je ne mets jamais de majuscules aux produits microsoft).

Heureusement, j'avais développé une petite application de ce type il y a une vingtaine d'années, à l'époque ou il fallait tester le système d'exploitation parce que la simple ouverture de port se faisait différemment selon que l'on était sous windows 98, NT ou XP !!! Je m'attendais donc à ce que cela ne soit pas simple, même pour une toute petite application.

J'ai une fois de plus tenté 'visual studio' dernière version. Après avoir téléchargé 2Go correspondant à 8Go installés sur le disque, j'ai de nouveau constaté l’absolu archaïsme de ce système de développement (je me place au niveau d'une personne attendant un réel 'service' de la part de l'outil et non pas au niveau d'un développeur qui ne connaîtra que cette médiocrité de développement durant toute sa vie de développeur et qui donc y sera habitué, le trouvera hyper adapté et considérera que tout le reste n'est que distraction). J'ai donc opté pour une solution beaucoup plus adaptée mais totalement obsolète : WxDev-C++, 550Mo sur le disque, WxWidget compris. Au moins cette solution me permet de développer simplement une application de type boîte de dialogue comme ceci :

Je n'ai pas encore totalement terminé cet utilitaire. La sélection des bonnes valeurs correspondant aux notes d'un clavier n'est pas encore implémentée mais le plus difficile est fait : je récupère la tension générée par toutes les valeurs envoyées au DAC.

L'utilisation des ports de com n'est évidemment pas aisée sous windows. Rien n'a changé depuis mes développements précédents il y a presque 20 ans. Je n'avais pas envie d'utiliser les pthreads pour gérer la réception des trames séries : trop galère et compliqué à utiliser et bien trop consommateur de temps pour une si petite application. J'ai donc utilisé le déclenchement par timers pour lire à intervalle régulier la disponibilité, ou pas, de caractères reçus sur les ports. Et de toute façon cela tombe bien, WxDev-C++ ne possède pas de façon native la gestion des pthreads.

A noter que j'ai aussi tenté Code::Block et les WxWidgets dernière version et ai rapidement laissé tomber l'affaire. les aides à la création des fenêtres sont archaïques, incommodes et, la cerise qui fait le bonheur, plantent systématiquement : inutilisable pour ce besoin. Par contre, j'ai dernièrement utilisé Code::Block pour du développement sur Z80, cela fonctionne très bien.

Je me suis souvent dit que je passerais moins de temps à développer un petit ordinateur adapté à mes besoins plutôt qu'à essayer de faire faire quelque chose à windows. C'est d'ailleurs depuis toujours la politique de microsoft, fournir un outil de développement qui n'en est pas un et imposer des méthodes les plus éloignées possibles des besoins et capacité des gens 'normaux' pour les évincer de facto de la course à la concurrence.

C'est sur ce principe que ce sont construits les empires informatiques américains d'aujourd'hui, microsoft, google et autres : développer à outrance une technologie archaïque et improductive qui impose une organisation sociétale adaptée, propre à fournir une très grande quantité de personnes stupidement intelligentes et bien formées au sujet. Hormis la Chine dont le système de direction à permis d'imposer le changement sociétal nécessaire, pour le reste de la planète, c'est l'échec et la course perpétuelle et destructrice à l’échalote de la "startup nation" !

Bon, ça n'est pas le tout de divaguer en propos philosophiques, mais il me faut maintenant terminer cette application!