J'ai eu l'occasion à plusieurs reprises d'écrire sur ce processeur de la famille PIC32 fonctionnant avec un puissant interpréteur Basic créé par Geoff Graham. La dernière version de l'interpréteur Basic que j'ai pu tester était la version 4,6b. Version que j'avais implémenté sur ma carte de développement spécialement créée pour Micromite :
Carte pratique et efficace ;-)
Comme cette carte le permet, il suffit d'y 'plugger' l'interface de programmation PicKit3 :
Facile...
Et de lancer l'interface de programmation de chez Microchip afin de programmer le circuit avec le nouveau firware en version 5 :
J'aime qu'un plan se déroule sans accrocs!
Et enfin de constater quelques instants plus tard, que le processeur contient bien le nouvel interpréteur Basic :
Et voilà.
Bien. Et alors?
Je passerai sur les améliorations en tous genres que Graham à porté à son Basic pour pointer une caractéristique bien intéressante : la gestion directe des afficheurs graphiques commandés par un contrôleur ILI9341. Pour avoir tenté, et réussi, d'implémenter ce type de gestion d'afficheur sur un petit processeur Atmel, je n'ai pu qu'être séduit par le fait de disposer de telles ressources disponibles sous la simple forme de quelques commandes Basic.
Le type d'afficheur dont il est question :
Cet afficheur possède de plus une interface tactile.
Il est possible de trouver ces afficheurs en taille de 2,2", 2,4" ou 2,8", équipé ou pas, de l'interface tactile. Pour mes tests, je disposais d'un afficheur sans interface tactile, ce qui devait suffire cependant à évaluer le système.
Le type d'afficheur utilisé, avec contrôleur ILI9341.
Le montage utilisé se compose donc de ma carte de développement spécialement étudiées pour Micromite, d'un afficheur adéquat sans interface tactile et, pour mettre en pratique le petit code d'exemple fourni dans la documentation du Basic, d'un module d'horloge temps réel obtenu sur la 'Bay' :
Des fils partout mais cela reste simple!
Un petit mot au sujet du module Temps réel : de la même façon que pour l'afficheur couleur graphique, l'interpréteur Basic possède les instructions nécessaires à la gestion simple d'un tel module équipé d'une puce de type DS1307 de chez Maxim. Il est possible de trouver ce genre de modules équipé non pas d'un DS1307 mais d'un circuit DS3231, plus précis mais toujours compatible avec le DS1307, et comportant en plus une petite mémoire EEPROM :
Ce module n'utilise pas une pile CR2032 mais un accumulateur LIR2032
L'afficheur LCD couleur est connecté simplement avec quelques liaisons sur le bus SPI du processeur.
Le module Temps réel est connecté sur le bus I²C du processeur.
Le tout, en fils volants mais sans complexité.
Une fois ce montage réalisé, il suffit de rentrer les quelques lignes de code Basic suivantes :
OPTION EXPLICIT
CONST DBlue = RGB(0, 0, 128) ' A dark blue colour
COLOUR RGB(GREEN), RGB(BLACK)
FONT 1, 3
BOX 0, 0, MM.HRes-1, MM.VRes/2, 3, RGB(RED), DBlue
DO
TEXT MM.HRes/2, MM.VRes/4, TIME$, CM, 1, 4, RGB(CYAN), DBlue
TEXT MM.HRes/2, MM.VRes*3/4, DATE$, CM
' IF TOUCH(X) <> -1 THEN END
LOOP
pour obtenir le résultat suivant :
Remarque, la ligne Basic contenant la lecture de l'interface tactile de l'écran a été mise en commentaire car l'afficheur ne possédant pas cette interface, l'instruction de calibrage n'a pas pu être utilisée. Le test de l'interface tactile génèrerait alors une erreur et stopperait l'exécution du programme.
Force est de constater que la réalisation de systèmes conviviaux devient de plus en plus aisée avec ce type de matériel. Pourquoi ne pas imaginer la réalisation d'une version simple de thermostat?
Mise en situation : il y a un an je découvrais les nouvelles versions des 'petits' processeurs Atmel, et plus particulièrement l'ATmega168pb grâce à un kit de développement à très bas coût, le kit ATmega168 X PLAINED. Ces petits processeurs me semblaient assez puissants pour tenter de développer un thermostat d'ambiance un peu plus convivial que ceux que l'on rencontre partout de façon standard. Je ne parlerai pas ici des objets de ce type dont l'objectif n'est certainement pas de répondre de façon simple à un besoin simple :
J'ai déjà eu l'occasion de 'disserter' sur le sujet dans un billet précédent. Or donc, après avoir décidé la mise en chantier d'un thermostat personnel, vint la réalisation et les premiers tests en juillet 2015 :
En compagnie d'une précédente réalisation pour comparaison.
J'ai continué quelque peu à développer ce prototype, mais au fur et à mesure de son développement, je me rendais compte que mes choix technologiques n'étaient pas les bons, et ce, sur deux points.
- D'un point de vue ergonomique tout d'abord, l'utilisation de boutons physiques, même si elle peut présenter certains avantages, ne permet pas une ergonomie 'soignée' en cas d'utilisation de plusieurs affichages différents.
- D'un point de vue technique, même si le processeur utilisé est assez puissant pour gérer l'affichage graphique, la taille de cet afficheur s'est avérée bien trop petite pour y afficher les informations de façon claire. La multiplicité des objets graphiques à gérer complexifient très fortement le code processeur, générant une application complexe et lourde.
J'ai donc cherché une autre solution d'affichage susceptible de servir aussi de surface de contrôle. J'ai déjà eu l'occasion de tester un tel afficheur lors de la mise en pratique d'une solution d'automatisme :
Ce système fonctionne très bien mais l'afficheur ne peut être utilisé vraiment correctement que dans l'environnement technique de cet automate, aidé du logiciel de développement fourni avec la solution.
Je me suis donc mis en quête de quelque chose qui ressemblerait physiquement à ce petit afficheur, mais un peu plus grand quand même, disposant aussi d'une interface tactile et d'un logiciel de développement.
Il y a pléthore de solutions de ce type, mais il me fût assez difficile de trouver une offre fiable, bien intégrée et fonctionnelle, pas 'trop' propriétaire et pas trop complexe à mettre en œuvre.
Et j'ai fini par trouver un système qui me semble assez pertinent. En une petit image, voici ce qu'il est possible de réaliser assez facilement avec l'outil de développement proposé avec l'afficheur :
Et en plus, le rendu est plus agréable que sur le prototype d'origine.
Les affichages ne sont pas pertinents puisque configurés par défaut dans l'outil de création graphique. Tous les objets présents ont néanmoins diverses caractéristiques modifiables directement par des instructions envoyées sur le port série de l'afficheur, comme les valeurs chiffrées, les textes etc etc...
Les premiers tests de modification dynamique de l'afficheur à l'aide d'un émulateur de terminal sur PC ont montré l'efficacité du système. Pour avancer sur le sujet, je compte me servir de mon premier prototype de thermostat pour envoyer les informations des capteurs sur ce nouvel afficheur.
13 janvier 2016. J'ai connecté cet afficheur à ma carte de développement à base de processeur Z8F Zilog. J'apprécie bien ce type de processeur assez rapide, fourni en périphériques et faciles à programmer et à 'debugger' avec le logiciel de développement fourni gratuitement. Voici le montage de base :
Avec un circuit d'interface 3,3V vers 5V.
J'ai donc écrit quelques lignes de 'C' pour envoyer par l'intermédiaire de ce processeur, les données sur la liaison série nécessaires à la configuration des indicateurs et de certains textes, ainsi qu'à l'apparition de certaines icônes à l'écran. Notez bien qu'il s'agit d'une démo. me permettant de valider le principe. Il n'y a aucune pertinence des informations affichées...
11 février 2016 : J'ai aussi connecté cet afficheur à un nouveau type d'automate que je me suis procuré. La particularité de ce PLC est d'être Open-Source de type Arduino, donc de programmation très aisée en C standard grâce à l'IDE Arduino. En un rien de temps, j'ai pu retranscrire le programme 'C' écrit pour le micro-contrôleur Z8F sur ce petit automate et constater le fonctionnement parfait de cet afficheur ainsi piloté :
L'afficheur est relié directement en 'TTL' sur les broches adéquates de l'automate.
15 janvier 2016 : Petite digression... A l'origine, j'avais développé mon premier prototype de thermostat sur une base de processeur 8 bits d'Atmel. Comme c'était mon premier 'vrai' emploi de ce type de processeur, je n'avais pas remarqué que la fréquence maximale de ces circuit était limitée à 8Mhz en cas d'utilisation de l'oscillateur interne.
Force fût alors de constater que la gestion de l'afficheur était lente, empêchant tout affichage dynamique de grande envergure. Même en doublant la fréquence de fonctionnement du processeur, il n'était pas certain que cela aurait grandement arrangé la situation. A considérer donc avec la complexité du code devant gérer totalement l'affichage. Raison pour laquelle je me suis engagé sur une autre voie.
Je viens de tester la nouvelle version de l'interpréteur basic du MAXIMITE, la V5. L'intérêt de cette nouvelle version est de proposer nativement l'utilisation et la gestion du même type d'afficheur que celui utilisé sur mon prototype de thermostat.
Un processeur 32 bits à 40Mhz, même s'il tourne sous Basic offre quand même d'autres performances :
Carte de développement personnelle.
Je pense poster un petit billet sur ce sujet prochainement.
La nouvelle année apporte parfois son lot de bonnes... et de mauvaises nouvelles. S'agissant du côté 'espiègle' du Prophet VS, c'est en cette fin d'année 2015 que je constatai un nouveau problème sur ma machine. Celui-ci se manifestait par un redémarrage intempestif, comprendre RESET total, du VS dès la manipulation de la molette de pitch-bend : amusant non?
Enfin, pas si amusant que cela. Heureusement que la toute dernière version du système conserve en mémoire le dernier patch sélectionné!
Forcément, la première idée qui vient à l'esprit est de suspecter le système qui gère cette molette. Il s'agit de cela :
En provenance directe de la documentation Sequential.
Rien de bien compliqué. J'ai donc démonté le panneau avant du synthé et ai vérifié la diode D101 et le condensateur C106. Tout allait bien de ce côté. J'ai donc suspecté le convertisseur ADC0809, bien que je ne m'imaginais pas vraiment de quelle façon ce composant pouvait être à l'origine du RESET de la carte mère du Prophet. Pour travailler méthodiquement, j'ai quand même ôté ce DAC :
Les fils sont ceux qui alimentent le rétro-éclairage LED de cet afficheur compatible.
Puis je l'ai remis en place, sur un support de circuit, en fixant la patte d'entrée du signal de la molette directement à la masse :
Le support permettra de remplacer facilement le composant si besoin.
Après remontage de la carte dans la machine et test complet de celle-ci, tout semble fonctionnel si ce n'est que je n'ai plus l'information de la molette de pitch. Cependant les tests effectués ne me permettent pas d'affirmer à 100% que le problème provient de ce circuit. Pour en être sur, il convient de le remplacer par un exemplaire réputé neuf. Une petite quête sur la baie me permet d'obtenir rapidement un certain nombre de ces circuits pour un prix dérisoire de 10$:
1$ le circuit. En cas de problème sur d'autres machines, j'en aurai en stock!
Après remplacement de l'ancien DAC0809 par un de ces nouveaux exemplaires, le problème subsiste toujours. Il est donc évident que le problème ne vient pas d'ici. J'ai donc effectué d'autres tests sur la carte mère et notamment le test des liaisons des différents bus entre les mémoires et le processeur : toujours aucune erreur. Si le problème ne vient pas de la source, alors il doit provenir de la destination, à savoir les circuits présents sur la carte de synthèse de Prophet VS. Afin d'isoler le problème, je déconnecte la carte mère de la carte de synthèse en ôtant les connecteurs suivants :
Les connecteurs se trouvent dans le cercle bleu.
Il est possible de redémarrer la machine, même si la carte de synthèse n'est pas connectée. Bien que le processeur central soit un MC68000, les spécificités de l'asynchronisme du bus de données ne sont pas utilisées. Et voilà, le VS démarre normalement et, bien qu'ayant remis en place le DAC d'origine dans son état d'origine, l'utilisation de la molette de Pitch Bend ne 'plante' plus le système. La bonne nouvelle de 2016 est qu'après remise en place des connecteurs puis remise en fonctionnement de l'appareil, tout fonctionne de nouveau normalement.
Évidemment, j'ai perdu un peu de temps à tester la partie DAC du panneau de commande. J'ai aussi acquis dix DAC0809 qui ne me serviront peut-être jamais, quoi-que l'expérience m'a souvent démontré le contraire. Ce qui est sur par contre, c'est que l'idée de faire courir les différents bus d'un processeur tel que le 68000 sur des distances incroyable de plusieurs dizaines de centimètres dans ce Prophet VS est une totale aberration d'un point de vue électronique et intégrité des signaux. Séquential a réitéré ce type de design dans le Studio440, Moins dans le Prophet 3000.
Dans un post précédent consacré au Prophet VS, je suggérait de 'caser' toute cette glue logique bien au chaud dans un FPGA. En fait, il y a un peu plus d'un an, j'ai étudié la faisabilité de l'implémentation de l'ensemble de la carte processeur dans un circuit programmable. Cela donnait ceci :
développé durant l'année 2014.
Il ne restait plus qu'à y implémenter la partie génération sonore, à savoir les quatre gros composant custon de chez Séquential, puis d'implémenter la partie filtrage en analogique, pour conserver au maximum le grain sonore originel. Je vais peut-être m'y remettre. Si cela intéresse quelqu'un de participer à un tel projet, je ne suis pas contre une collaboration....
