On repart pour un tour !
Petit rappel des épisodes précédents : pénurie, pas de MCU, donc je me retrouve obligé de “jeter” mon routage. Je pars sur des cartes d’évaluation, mais je me rends compte qu’une seule ne suffit pas, et que si j’en mets plusieurs ça ne rentre plus, donc il faut re-faire entièrement l’architecture mécanique. Nous y voilà donc.
Bien que cela soit frustrant de devoir encore tout re-designer, je préfère m’en rendre compte relativement tôt. Et tout le design électronique, lui, peut être récupéré, donc le boulot que j’ai déjà fait de ce côté n’est pas perdu.
Il va donc falloir faire une architecture générale qui permette de rentrer les deux cartes d’éval et tout le reste pour que mécaniquement ça rentre dans le “nouveau” boîtier, et bien faire le pinout des deux cartes pour être sûr de ne pas se faire bananer encore une fois.
Destin farceur
A tout hasard, je refais un passage sur les stocks chez Farnell / Mouser. Et là, stupéfaction … Il y a des STM32 de la famille que j’avais choisi au tout début, dans le bon boîtier, en stock, et, genre, des milliers d’exemplaires \o/ WAT ?!? Damned, qu’est-ce que je fais ? Déjà il n’y a pas exactement le même modèle, mais des proches dans le même boîtier. Il est tentant de laisser tomber le re-design, reprendre la carte que j’ai déjà finie, et avancer. Mais en vrai, après réflexion, je trouve que mon archi n’était pas très bonne, mécaniquement, et même il y a des fonctionnalités que j’aimerais bien avoir et que je n’avais pas mis à l’époque. Et un écran tactile … Quand-même … Ça serait classe :)
Donc je vais en commander dès que possible, pour en avoir d’avance et ne pas me faire ken’ si la pénurie reprend. A minima ça me permettra d’éviter de mettre une Nucleo, et idéalement il faudrait que je fasse un design qui puisse utiliser soit une carte d’éval avec écran tactile, soit une carte custom, et cette éventuelle carte d’interface custom pourrait très bien utiliser les connecteurs et le pinout d’un Arduino tel que sur la Disco.
Reprise de l’architecture mécanique
Le stackup mécanique est toujours compliqué, sans surprise. On a ~32mm de hauteur interne dans le 1590DD, ce qui est très large. Pour rappel il y a trois besoins contradictoires:
- La Disco doit affleurer à l’avant pour que l’écran tactile soit accessible,
- La carte-mère doit “reposer” au fond autant que possible,
- Il y a des boutons et encodeurs qui doivent affleurer à l’avant aussi.
32mm c’est beaucoup et je ne pense pas raisonnable de chercher des connecteurs HE10 “allongés” pour pouvoir brancher directement la Disco sur la carte-mère, il faut donc une carte intermédiaire. Mais a priori ça ne tombe pas vraiment “juste”. Rien de critique, vu que les connecteurs de la Disco sont CMS, donc légèrement moins hauts que des HE10 traversants, et ça passe. De toutes façons ce n’est pas une surprise et les connecteurs de la carte d’évaluation étaient déjà un problème sur le design précédent. Sauf qu’ici il n’y a pas les “pattes” des HE10 traversants qui dépassent sur le dessus, un avantage non-négligeable.
La carte “IHM” qui tient les contrôles physiques est reloue, car elle impose de se placer plus en retrait que la Disco, et elle ne tombe donc vraiment pas “juste” au niveau étagement. Sur le design précédent j’avais prévu de la tenir avec des HE10 traversants à angle droit, ce qui “rattrape” ce décalage, et ça marche toujours ici. On arrive à un empilement dans ce genre:
Il y a donc une carte intermédiaire qui supporte la Disco et la carte IHM, c’était déjà le cas dans le design précédent, et j’avais mis la partie analogique sur cette carte intermédiaire, ce qui avait l’avantage de permettre de changer le circuit “facilement”, en tous cas ça coûte moins cher de faire une carte d’interface qu’une carte-mère (moins de surface, moins de connecteurs). Ici il faut ajouter la Nucleo, si je garde la même logique avec le circuit analogique sur la carte intermédiaire, le plus pertinent est de la mettre sur la carte intermédiaire, mais alors elle entre en concurrence avec la Discovery vu que les deux sont dans le même “espace”, et donc je ne peux pas mettre autre chose qu’une Nucleo 32. La représentation que j’ai faite ici montre une autre possibilité : connecter la Nucleo sur la carte-mère, ce qui donne un peu plus de flexibilité (peut-être) et pourrait me permettre de mettre une Nucleo 64, mais impose de faire transiter plein de signaux vers la carte-mère, ce qui n’est pas très heureux.
Sinon comment est-ce que je pourrais m’arranger pour placer la Nucleo sur la carte d’interface, mais pas en conflit avec la Disco ? Si je la met sur la face opposée ça va entre en conflit avec la carte-mère, donc il faudra que je fasse une ouverture.
Ou sinon encore pire : je mets la Nucleo à 90°, vu qu’elle fait 19mm de large, ça passe :p Mais Nucleo 32 seulement, et il faut que je fasse encore une interface pour attraper les deux connecteurs, donc c’est une idée stupide.
Au final, pour rester raisonnable et pratique il faut que la Nucleo soit sur la carte d’interface, et donc Nucleo 32, tant pis. Ça donne ça:
Si on regarde au niveau surface ce coup-ci, on a un truc du genre:
Sur la Disco les connecteurs sont au niveau des bords marges, donc la carte d’interface doit la “recouvrir” entièrement, ce qui fait qu’il n’est pas possible de superposer la Disco et les jacks / connecteurs MIDI, il n’y a que le connecteur d’alim qui peut potentiellement se glisser juste-juste, par contre la carte IHM est suffisamment “haute” pour pouvoir être placée au-dessus des jacks. C’est assez pénible car ça oblige à descendre l’écran alors qu’on voudrait pouvoir le remonter pour l’éloigner des footswitches, et en plus on préférerait avoir les boutons en-dessous pour la lisibilité. Mais d’un autre côté, avoir les boutons “bas” ça augmente le risque de taper dedans par erreur, donc au final ce n’est pas plus mal qu’ils ne soient pas en-dessous, et donc au final je trouve qu’y mettre sur le côté est pas mal.
Et en y regardant comme ça je me dis que la carte d’interface devrait faire toute la largeur du boîtier, de façon que je puisse mettre des entretoises de support sur sa droite, pour encaisser les efforts en vertical quand on appuie sur les boutons.
Et je me dis que aussi que, au pire, j’ai toujours la possibilité de glisser la Nucleo entre deux footswitches, quoique je doute que ça soit intéressant.
Concernant les footswitches, si je les mets “couchés”, je peux éviter de faire des ouvertures trop profondes dans la carte-mère. Aussi il y a des renforts centraux sur le boîtier sur la longueur, ce qui gêne le placement du switch central. Est-ce que je met le switch central “plus haut” que les deux autres ? Je crois que je l’ai déjà vu sur des pédales du commerce. Sinon, si je veux qu’ils soient tous le plus bas possible, il ne faut pas que j’aie de footswitch central, donc soit je fais un truc asymétrique, soit je mets un quatrième footswitch pour pouvoir en mettre deux de chaque côté. Dans ce cas il faudrait re-définir le rôle des footswitches. Grmpf … Je vais rester sur 3 footswitches, on ne va pas faire la révolution tous les 4 matins.
Ça c’est pour la configuration avec une Disco et une Nucleo. Si on met la partie algo sur le PCB avec le STM32 en direct (vu que je peux à nouveau en acheter), alors il n’y a plus de Nucleo à placer. Il faut que je voie comment agencer ça pour avoir les deux configs possibles sur le même PCB, ça serait l’idéal, sinon deux PCBs différents, mais bon, si on peut éviter …
Pour aller encore plus loin et ne pas utiliser de carte Discovery, il faut une carte d’IHM custom qui la remplace complètement. Je n’ai pas l’intention de faire le design détaillé de cette carte à court-terme, ceci-dit, je peux déjà définir les contraintes générales. Si c’est une carte à écran tactile, la config sera similaire à ce que je viens de définir, donc rien de spécial, je re-ferai une Disco, on va dire. Par contre si c’est une carte “à l’ancienne” comme je l’imaginais au tout début, avec des encodeurs et des 7-segments, elle doit être “éloignée” du haut du boîtier, donc je ne peux pas la connecter sur les connecteurs Arduino de la Disco, parce qu’elle va ramponner dans le boîtier. Il faudrait qu’elle se connecte entièrement sur le connecteur “de côté” de la carte IHM, si j’y mets assez de signaux ça pourrait suffire, par contre il faut que je prévoie du support mécanique, donc de quoi mettre des entretoises. Je pense que ça devrait suffire pour couvrir tous les cas.
Board edge de la carte d’interface : les connecteurs MIDI et les jacks vont gêner, donc je ne peux pas juste reprendre la forme de la carte-mère. Ça me laisse environ 178 x 87, moins les ouvertures pour les footswitches.
Pour me faciliter la vie, je ne vais pas découper les ouvertures dans les contours de PCB sous FreeCAD (pour les footswitches qui vont “traverser” tout le boîtier), je vais le gérer dans Kicad, quitte à y laisser “fermé” sur le PCB final et découper à la main sur le PCB fini. C’est pas génial, mais ça me prend moins la tête.
J’ai regardé les connecteurs “slim” pour voir si je peux intercaler une carte-fille sur la carte d’interface qui contiendrait le circuit analogique, pour permette de changer le circuit sans changer la carte d’interface complète. Les seuls qui me semblent raisonnables (dimensions, prix, dispo …) sont les Amphenol Bergstack en pitch 0.5mm. En prenant ceux qui donnent un espacement de 5mm il y a largement de quoi intercaler entre la carte interface et la carte-mère. Je vais garder ça en option, c’est à dire que je vais quand-même mettre le circuit analogique sur la carte d’interface, mais je vais aussi poser les connecteurs en parallèle, comme ils sont en CMS et sur le dessous, ils ne vont pas trop me contraindre, à part sur le routage de la carte-mère, il faudra que je fasse gaffe de ne pas mettre de composants hauts en face de cette carte. Je vais mettre deux connecteurs de 2x10 pour avoir de la marge.
Choix du MCU
Au final donc, le modèle que j’avais prévu (STM32F303VC) n’est pas dispo, par contre pas loin il y a le STM32F303VB, qui a deux fois moins de flash. Grmpf … Ça commence à faire pas beaucoup, mais je peux dire que j’utilise la flash / EEPROM externe pour ne pas que ça soit une contrainte.
Sinon, si je monte en gamme, j’avais identifié les STM32G4 qui ont la bonne granularité de Flash, et qui peuvent monter jusqu’à 170MHz, avec une consommation qui reste raisonnable visiblement. Je pense que je vais partir là-dessus, et je jette mon dévolu sur le STM32G473VCT6. Hum … Non, après réflexion il y a des Nucleo 32 avec du STM32G431, donc je vais plutôt partir sur un STM32G431VBT6.
Oui mais, est-ce que c’est pertinent de partir sur un énorme MCU, et laisser de quoi monter une Nucleo qui aura largement moins de pins disponibles ? Non, ça n’a pas de sens. Je ferais mieux soit de partir sur un MCU à la bonne taille, soit me démerder pour mettre le même MCU que sur la carte d’éval … Si ça passe ! Et après avoir check les signaux dispo sur la Disco, je me rends compte que ce n’est pas si évident que ça. Par exemple, il n’y a qu’un seul UART dispo, donc je n’ai pas moyen de mettre de l’intercom ET du MIDI sur la Disco, donc il me faut un bus de com en plus, mais pas de place sur le 32 pins qui est déjà blindé. Je sens que me mettre la contrainte de compatibilité Nucleo 32 est ingérable.
Grmpf …
Allez, on va arrêter de se mentir : il faut refaire une matrice de choix du MCU, mais avec d’autres paramètres.
Je vais reprendre ma liste de l’époque, mais en changeant la liste de signaux que je dois câbler dessus, si on vire les signaux d’IHM ça va alléger. Par contre les signaux disponibles sur la Disco vont être dimensionnant, il faut donc que je commence par faire son pinout, et en déduire de ce qu’il manque ce qu’il me faut sur le MCU de régulation, en essayant de viser (arbitrairement) un LQFP 64 pins plutôt que 100 pins, et idéalement un qui ait une Nucleo, pour pouvoir faire des manips “sans HW”. Et tant qu’à faire, 100MHz minimum, Cortex-M4 minimum pour avoir de la marge en puissance de calcul, et avec une carte Nucleo existante pour pouvoir développer et tester.
Déjà ce que j’avais vu, c’est que la contrainte d’avoir beaucoup de petites sections de Flash limite fortement, et il n’y a quasiment pas de MCU performant qui ait ça en-dehors des STM32G4. Ce n’est pas très étonnant, je suspecte que les “petits” MCU visent des marchés à très bas coût et/ou forte intégration, donc éviter d’avoir une mémoire externe peut être plus adapté ? Grmpf … Toujours est-il que ça me laisse peu de choix, et que j’ai bien envie de lever cette contrainte, en me reposant sur une mémoire externe.
Partons donc des cartes Nucleo 64 en stock chez Farnell : - F401RE : 84MHz, Flash512kB, RAM 96kB, 3 SPI, 3 UART, 10€, stock Farnell 8k - F410RB : 100MHz, Flash 128kB, RAM 32kB, 3 SPI, 3 UART, 7€, pas de stock chez Farnell - F446RE : 180MHz, Flash 512kB, RAM, 4 SPI, 6 UART, 13€, stock Farnell 28k - L412RB-P : 80MHz, Flash 128kB, RAM 40kB, 2 SPI, 3 UART - L433RC-P : 80MHz, Flash 256kB, RAM 64kB, 3 SPI, 3 UART - L452RE : 80MHz, Flash 512kB, RAM 160kB, 3 SPI, 4 UART - G431RB : 170MHz, Flash 128kB, RAM 22kB, 3 SPI, 4 UART, 9€, pas de stock - G491RE : 170MHz, Flash 512kB, RAM 96kB, 3 SPI, 5 UART, 12€, pas de stock
Je vais partir sur le 446RE, c’est le plus cher, mais aussi le plus performant et celui qui a le meilleur stock chez Farnell. Il a même de l’USB natif, que demander de plus ?
Vu que je me suis fait piquer mon ST-link quand on m’a fracturé ma caisse, il faut que j’en rachète. Au passage, ST vend aussi un module “embarquable” au format d’un ESP32 pour intégrer un ST-link dans un produit, un peu comme fait la partie débugger des Nucleo / Disco. C’est pas si cher (~10€) et c’est vraiment pratique et c’est cool qu’ils le proposent à la vente, et je vais voir pour en intégrer un. Il y a aussi une sorte d’intermédiaire qui se branche sur une connecteur 1.27mm mais il me semble moins pratique.
Donc au final c’est quoi l’archi ?
Carte mère avec les connecteurs. Carte “fille” / interface avec le circuit analogique et le MCU principal qui va faire la régulation. Carte IHM avec des boutons, encodeurs, LEDs, afficheurs. Carte Discovery STM32F469ZI pour l’IHM avec écran tactile, et qui va aussi gérer les signaux de la carte IHM.
Pinout
Nous sommes donc parti sur deux cartes : une Discovery pour l’IHM et l’interfaçage avec l’extérieur, un MCU pour la partie asservissement / régulation et “temps-réel”.
Si on reprend l’architecture générale, on peut découper et identifier les signaux requis pour chaque carte. Dans une approche “candide”:
Pour la carte IHM: - Entrées foot switches x 3 - Entrées encodeurs 2 x 2 position + 2 x poussoir - Sortie LEDs encodeurs x 4 - Entrées IHM x 3 boutons - Sortie commande bypass x 1 - Entrées expression : ADC x 2 - EEPROM externe : SPI x 1 - Debug : UART x 1 - Communication avec l’autre carte
Pour la carte d’asservissement: - Sortie DAC : PWM x 4 (2 DAC avec 2 PWM chaque) - Sortie VCA : PWM x 3 - Entrées analogiques pour polarisation : ADC x 4 - Entrées analogiques pour peak : ADC x 6 - Entrées analogiques audio direct : ADC x 3 (mais c’est optionnel) - PWM : 3 x input capture pour mesure fréquence, - Debug : UART x 1 - Communication avec l’autre carte (je vais appeler ça “intercom”)
Il y en a quelques uns dont l’assignation n’est pas évidente a priori: - Commandes digipots gain / volume / mix : SPI x 5 - Pompe de charge : PWM x 1 - Potentiellement les ADC directs : ADC x 3 - MIDI : UART x 1
Il faudra voir après assignation des autres où il reste de la place. J’ai donc commencé à regarder le pinout de la Disco, qui est le plus dimensionnant. Je n’ai accès qu’à une seule UART, donc je vais y laisser l’intercom, et mettre le MIDI sur le MCU de régul (ce qui n’est pas aberrant en soi).
Pinout carte de régulation
Nous partons donc sur un STM23F446.
Il y a deux USB, un FS et un HS. Sur la Nucleo, l’UART vers le ST-LINK est USART2 et il est connecté sur les pins de l’USB HS, donc si je veux être compatible il faut que je me contente de l’USB FS. Grmpf … A se demander s’ils n’ont pas fait ça spécialement pour dissuader d’utiliser les Nucleo tel-quel dans des produits. Après, l’USB ne servirait qu’à remplacer à terme le ST-LINK, donc debug, calibration et bootloader. Ai-je vraiment besoin du HS ? Pour l’horloge USB à 48MHZ, vu que je suis parti sur un résonateur à 20MHz pour avoir une valeur standard, si j’utilise la PLL principale comme source ça ne va pas convenir, car il n’y a pas vraiment de PGCD entre 20, 48 ni entre 48 et 180, donc ça m’obligerait à baisser la fréquence CPU pour tomber sur un multiple, genre 144MHz. Pour éviter ça on peut utiliser à la place la PLLSAI, en divisant l’horloge principale par 20 on tombe à 1MHz, puis x192 et /4 et on a pile poil 48MHz, sans toucher à la fréquence CPU.
Côté HW pour l’USB les signaux sont en direct entre le MCU et le connecteur, avec juste de la protection ESD et un switch pour le 5V. Le modèle qu’ils ont mis sur la disco 429 (je le prend comme exemple) est un STMPS2141STR en SOT23-5, qui est un peu cher (~1.4€). Chez Diodes ya le AP22802 qui est à 40cts mais il limite plus haut à 800mA, je me demande si ce n’est pas un peu dangereux. En tous cas ils sont pin-compatibles donc je peux déjà le provisionner.
Pour la com entre les deux cartes, je préférerais utiliser de l’UART pour me simplifier la vie. Sur la discovery il n’y a qu’un seul UART accessible, qui est d’ailleurs celui qui sert à communiquer avec le ST-link intégré, mais ça n’est pas trop un problème, juste je ne pourrai pas dédier ce canal au debug. Par contre ça veut dire que je ne peux pas mettre le MIDI sur la Disco, à moins d’utiliser autre chose que de l’UART pour l’intercom. Donc je vais plutôt tirer parti du fait que j’ai un “gros” MCU sur la partie régulation, et mettre le MIDI sur ce MCU, même si ça me parait un choix non-intuitif.
Un truc auquel j’ai re-pensé après : j’ai envie de provisionner une lecture direct des signaux d’entrée, des fois que je veuille faire des manips en utilisant ces signaux. Le truc c’est que dans un fonctionnement “normal” pour le signal d’entrée je ne remonte que le signal post-VCA, vu que c’est ce que je fais entrer dans la Fuzz. Serait-il préférable d’envoyer le signal audio pré-VCA ? Je me dis que non, je vais garder le signal post-VCA, et avec la mesure de crête je peux reconstruire l’amplitude. Donc je garde et je mesure uniquement le signal post-VCA.
Au final il me reste 6 pins libres sur le MCU.
Pinout carte IHM
Nous partons donc sur la Discovery STM32F469NI. En pratique il n’y a pas beaucoup de pins sur le connecteur Arduino, donc il faut rationaliser. Je vais mettre toutes les entrées en direct, par contre les sorties pour les LEDs je vais laisser tomber la régulation PWM des LEDs et je vais tout multiplexer sur une SPI avec les éventuels afficheurs 7 segments. Pour les entrées analogiques des pédales d’expression pas de place non plus donc je les mets sur le MCU de régulation finalement.
Au final il me reste 1 pin libre sur le connecteur Arduino.
Architecture et alims
Maintenant que l’on sait quelles cartes on va utiliser, voyons voir comment on va les organiser, comment on va assigner les fonctions, et comment on tire les alims.
En regardant ce que j’avais fait sur l’archi précédente, je ne comprends pas trop pourquoi je voulais alimenter la Disco sur le 5V, alors qu’on peut très bien l’alimenter directement en 9V. Je pense que je voulais éviter de faire surchauffer l’alim de la Disco, mais alors je me retrouve avec énormément de courant sur le 5V, et je me demande s’il ne serait pas plus sage de prendre un module DCDC tout fait, plutôt que m’emmerder à faire le routage d’un Buck. Au point où j’en suis, c’est peut-être mieux de ne pas me mettre trop de contraintes sur le dos. Un Traco TMR 3-1211 fera l’affaire, et je pourrais même y faire entrer du 12V si je veux diminuer le courant en entrée.
Pour le MCU de la carte d’interface / régulation, il va falloir que je rapproche l’alimentation du MCU, je ne vais pas la laisser sur la carte-mère, ça serait ridicule. Si je reste sur l’idée d’un Traco il faudra que je fasse gaffe à la hauteur, sinon pas trop le choix il faut que je reste sur un buck routé sur la carte. Il me faut donc un DCDC qui génère du 3.3V sur la carte d’interface, et du 5V pour la Disco et les interfaces. J’ai bien envie de générer du 5V sur la carte-mère et de le renvoyer sur la carte d’interface, pour éviter de faire plusieurs alims, mais ça va me faire des longueurs de piste d’alim pas possible, donc je vais plutôt renvoyer la tension d’entrée, et chaque carte aura son circuit d’alim. J’ai presque envie d’alimenter tout l’analogique de la carte-mère en 5V … Grmpf … risqué … A minima je vais mettre le potar du mixeur sur 5V, pour pouvoir en mettre un moins cher (genre des MCP41xxx ou MCP42xxx). Pas besoin de polariser des composants sur des tensions élevées, donc pas obligé d’alimenter ce module en 9V, il faut juste que je mette des protections adaptées. Au final même en alimentant tout l’analogique de la carte-mère en 5V, il ne va pas y avoir un courant énorme, donc je pense qu’un LDO suffira : LD1117 en SOT-223, ça fera l’affaire. Pour voir s’il y avait un modèle de LDO “conseillé” pour de l’audio, j’ai tapé “LDO SOT-223 audio” dans google et ça m’a sorti le LD1117 en premier résultat. Bon, on va en rester là.
Pour la carte d’interface, il faut un 3.3V pour le MCU, je pense un LD1117 en SOT-223 ça va le faire, sur la Nucleo c’est déjà un LDO (en QFN). Pour la Disco, je pense je vais plutôt alimenter directement en 9V, pour simplifier.
Premier jet des sur le PCB de la carte-mère donne ça:
Ça rentre laaaarge !
Zero-crossing le retour de la vengeance
Non, je ne peux pas continuer sans me poser la question du zero-crossing. Je ne veux pas prendre le risque de foirer tout par fainéantise, il faut que je mette un système de détection du zero-crossing sur les digipots. Après un tour rapide sur le net pour voir si la “situation” a changé depuis la dernière fois que je me suis penché sur le sujet, il n’y a visiblement pas grand chose qui a changé : les digipots avec zero-crossing intégré sont toujours aussi rares, et toujours cantonnés aux fonctions simplistes de contrôle de volume, donc soit avec des interfaces foireuses (up/down uniquement), soit nombre de pas très limité, soit log-only voire pas en dB, bref, rien qui ne me convient. On en revient donc à la topologie proposée dans la note d’appli d’Analog qui consiste à ajouter une détection analogique à base de comparateurs et un latch du chip select. Limite il faudrait que je fasse un module sous forme de mini-PCB avec un digipot et son système de détection, pour pouvoir faire des manips. Bref : on va ajouter ça sur les digipots du circuit.
Cependant, il y a un gros souci “nouveau” par rapport aux projets précédents sur lesquels j’avais envisagé mettre ce genre de circuit : maintenant on a plusieurs Chip Select. Ce qui veut dire qu’il faut attendre que la valeur ait été effectivement prise en compte par le digipot avant d’envoyer une commande dédiée à un autre digipot, ou alors masquer la clock quand le chip select (du MCU, pas celui qui est latché) n’est pas actif. Sinon, si la détection de passage à zéro ne s’est pas encore déclenché et qu’une nouvelle commande est envoyée, le premier digipot va “écouter” les data alors qu’elles ne lui sont pas adressées. Ça complique beaucoup le circuit d’un seul coup.
Sur mon circuit de tremolo j’avais prévu de mettre une porte XOR et une bascule RS à base de NAND. Je pense que je vais mixer avec la note d’appli pour avoir uniquement des portes NAND, ça passe avec 4, donc un seul CI est suffisant. Pour le masquage des commandes en attendant la détection du zero-crossing, je pense que le plus simple c’est de masquer la clock. Il faut s’assurer que ça ne va pas ajouter de délai sur le signal qui pourrait compromettre la lecture. A priori on pourrait ajuster les timings dans la config du contrôleur SPI du STM32, mais mieux vaut avoir une configuration hardware qui injecte le moins de perturbation possible. Et en même temps je ne veux pas utiliser de composant trop spécifique.
Je pense le plus simple c’est de mettre deux résistances en série, et un MOSFET (ou un PDTx) commandé par le CS qui tire le potentiel entre les deux résistances à la masse. Franchement, il ne faut pas que je me prenne la tête plus que ça.
IHM : quels contrôles ?
J’ai prévu deux encodeurs, deux LEDs, 4 boutons poussoirs, je me demande si je ne pourrais pas ajouter un “joystick” … Grmpf … On verra sur une autre version.
Routage
Tout mis bout à bout ça me fait presque 900 composants au total o/ Et l’article est déjà beaucoup trop long, donc à suivre …