Fuzz Flaxtory - Re-design - Randagodron Blog

Où l’on subit la pénurie massive, et que l’on fait comme tout le monde dans l’industrie électronique : on refait le design.

Au cas où cela aurait échappé au lecteur, il y a en ce moment une énorme pénurie de composant électroniques qui fait rage. Certains types de composants sont plus touchés que d’autres, et certains constructeurs sont plus touchés que d’autres. A priori Microchip ça va à peu près (entre autres parce qu’ils ont quelques usines aux USA), par contre Xilinx, NXP et ST sont en grosse grosse hess. Et donc, sourcer du STM32 en ce moment, c’est juste pas possible, et les prévisions ne sont pas joyeuses, même sur un horizon de plusieurs années.

Mais au fait pourquoi la pénurie ? A priori c’est multi-factoriel, conjonction des suites d’une sécheresse à Taïwan qui se répercute jusqu’à maintenant (l’industrie du silicium consomme énormément d’eau), des tensions géo-politiques et commerciales entre les USA et la Chine, des pénuries d’autres ressources, du minage de crypto-monnaies qui accapare énormément de capacité de production pour les GPUs et leurs p***** d’ASICs de merde … Sérieux j’en veux à mort aux crypto-bros, ces gens sont la lie de l’humanité.

Bref, pour ce circuit, j’ai choisi un STM32F303 en boîtier TQFP100. Or, en ce moment, en STM32 on ne trouve que du cortex 0 ou 1 en boîtier QFN ou BGA avec des pitch pas possibles que personne ne sait monter (en tous cas pas avec des machines prévues pour moins de 10k cartes par run). Ce choix me ferme la possibilité de cannibaliser une pièce sur une carte d’évaluation ou une Nucleo, car il n’y a pas d’outil d’évaluation avec ce type de boîtier. Conclusion : je suis ken’. C’est de ma faute, j’aurais dû acheter les composants dès que je les ai choisi, procrastination + pénurie globale de silicium ne font pas bon ménage.

Maintenant : quoi faire ? Attendre est aléatoire, il y a une probabilité non nulle que le composant ne redevienne jamais dispo. Il ne me reste donc qu’une solution pour avancer : modifier le design pour utiliser des composants disponibles. Ahlala, j’en pète de joie comme disait l’autre.

Mais en fait il n’y a vraiment RIEN en boîtier raisonnable, donc je vais être obligé de faire un truc que j’avais voulu éviter : utiliser une Nucleo. Et vu que j’ai besoin de beaucoup d’IOs, ça va être une 144, donc une énorme. Misère … Avec un bail pareil, je suis parti à refaire entièrement la méca, avec peu de chances de pouvoir récupérer quoi que ce soit du routage déjà fait. Turbo-relou.

Note pour la suite : j’appelle “FF” le “circuit principal” (la Fuzz Factory en elle-même, celle dans laquelle entre le signal d’entrée) et “REF” le deuxième circuit qui sert de référence.

Choix de la carte de commande

Déjà on va voir ce qui est disponible, voir si on peut trouver un truc dans un format raisonnable (Nucleo 144 c’est gros quand-même). Et on ne la met sur le PCB uniquement après l’avoir commandée et reçue, pour être sûrs. De toutes façons en ce moment ya que comme ça qu’on se fait pas rotte-ka.

Si on regarde ce qui est dispo chez Farnell, des Nucleo 144 en F4, F7, H7, yen a, ok, au pire je prendrai ça. Étant donné que j’ai récemment pas mal creusé TouchGFX, faire des interfaces tactiles ne me fait plus trop peur, donc je me dis que ça ne serait pas absurde de prendre une Discovery avec un écran, genre la Discovery STM32F429I, celle que j’ai utilisé pour expérimenter avec STM32Doom. Elle a un MCU en 144 pins, beaucoup de signaux dispo sur les connecteurs, donc sans doute suffisamment pour mon application, et elle ne prend pas tant de place que ça. Surtout que l’écran n’est pas de la surface perdue dans ce cas. Autre avantage de prendre une carte d’éval : l’USB avec le VCOM et la prog est déjà présent, donc pas besoin de le prévoir, ni d’approvisionner un FTDI pour ajouter cette fonctionnalité. Joie ! Par contre il faut faire gaffe au placement mécanique de la carte pour que le connecteur soit facilement accessible de l’extérieur.

J’ai fait le tour de ce qui est dispo et … Ya pas trop d’autre choix, même hors-ST. Les autres Discovery avec écran sont soit trop grandes / trop chères, soit ne proposent que des connecteurs Arduino UNO basiques avec carrément pas assez de signaux disponibles. Donc, ben, je vais racheter de ces Disco-là (sachant que j’en ai déjà une en stock, j’en avais une deuxième mais on me l’a volée :( ). Petit tour sur Mouser par acquis de conscience : je ne trouve rien de mieux, donc on va donc partir là-dessus. (Au passage, le fait qu’ils interdisent d’en commander plus de deux par compte et par mois doit aider à maintenir les stocks)

Reprise de la méca

Tout de suite le projet prend une autre dimension :p Il va falloir intégrer l’écran et des contrôles en plus, donc l’archi interne ne va plus du tout être la même.

La Disco fait 120 x 66. Si on reprend le placement / routage précédent, le PCB fait 138 x 114, ce qui rentre large, mais mais mais il faut prendre en compte les connecteurs, si on les laisse dans la configuration actuelle ça laisse 120 x 90 … Ya tout juste la place de la mettre à l’horizontale. Et il reste donc 24mm en-dessous, ce qui est suffisant pour les switches, mais pas pour la carte analogique, qui n’a plus de place …

Check datasheet du boîtier : le 1590XX fait 35mm d’épaisseur interne. Avec la config précédente j’étais à 29mm totale, donc pas de marge. Si on considère qu’on peut “rabaisser” la Disco vu qu’elle ne portera pas les encodeurs, on peut arriver à, allez, 24mm ?Donc il reste 7mm pour mettre une carte de l’autre côté, ça ne passe pas. Essayer de la glisser sous la Disco ? Dans ce cas il faut relever la Disco jusqu’à ~20mm, en mettant des embases de ~9mm + 3mm pour les supports des connecteurs mâle + 1.6mm de PCB, ça rentre. Pour accéder aux trimmers, c’était déjà la galère avant, ça l’est toujours ici, il faut toujours percer des trous dans le PCB principal si on veut y avoir accès directement, donc rien de nouveau sous le soleil. D’ailleurs j’ai comme l’impression que j’ai oublié de mettre des trous sur la version “normale”, damned !

Et les potars / encodeurs / LEDs ? Arf, ya vraiment pas de place “en surface” … ça coince.

Est-ce qu’on peut remonter la Disco suffisamment pour la faire passer au-dessus des jacks ? Grmpf … je ne gagne quasiment rien (genre 5mm) puisqu’en largeur ya les connecteurs.

Aïe, là c’est dilemme : soit je supprime les contrôles physiques, soit je change d’approche et de boîtier. Avec une Nucleo 144 c’est encore pire, elle fait 133 x 70 donc elle ne rentre pas du tout quoi qu’on fasse, à part changer de boîtier, là aussi.

Bon, bon bon bon, est-ce qu’on peut complètement se passer de contrôles physiques et tout faire à l’écran tactile ? Je me demande si c’est vraiment pire que les encodeurs …

Allez, on part la-dessus, on verra bien ce que ça donne.

Déjà, en partant d’un espacement de 35mm et une carte GUI moins épaisse, je me rends compte que j’ai la place de mettre une carte intermédiaire, j’ai bien envie de faire une seule carte qui fasse interface avec la Discovery, et contienne aussi le circuit analogique. Ce n’est pas idéal au niveau CEM, longueur des pistes, aller-retours de signaux, certes, mais bon tant pis. Ça simplifie l’intégration mécanique, de toutes façons je n’ai pas trop de marge de manœuvre à ce niveau.

J’aimerais bien faire passer la Disco par-dessus des connecteurs pour gagner de la place et avoir plus de choix de placement, mais avec les connecteur ce n’est pas trop possible. Le seul moyen serait que la carte intermédiaire passe par-dessus les connecteurs, mais ya pas la place. Une hauteur de connecteur ce n’est pas suffisant pour passer par-dessus une hauteur de jack, et ya juste la place de mettre deux hauteurs de connecteurs avec les PCBs, donc pas moyen de rallonger.

Oh ! Sur la Disco ils ont mis des connecteurs sur le côté LCD, genre les connecteurs principaux qui dépassent beaucoup, que je vais sûrement être obligé de couper à la main :( Et des connecteurs 2.54 pour des jumpers et pour le SWD, il va falloir que je les démonte, et le bouton de reset + bouton user. Ce design ne va vraiment pas être viable pour de la “prod” … A moins de re-faire complètement une carte MCU + LCD, ce qui n’est pas la même affaire, mais pourrait tout à fait s’envisager pour plus tard. Ah, ya aussi le connecteur USB qui est au même niveau que le LCD, ce qui va être vraiment pénible pour faire le trou pour y accéder. Il vaudrait peut-être mieux que je le déporte d’une façon ou d’une autre ? Idem pour le connecteur OTG, que je pourrais récupérer pour pouvoir connecteur une clé USB -> nice-to-have pour plus tard.

D’ailleurs la Disco et tellement longue qu’elle ne pas pas entièrement et doit dépasser sur les connecteurs MIDI. En hauteur c’est large, par contre à cause des connecteurs je n’ai que 5mm de marge sur la carte. Surtout il faut que je n’oublie pas de décaler les connecteurs au max sur la carte d’interface, pour ne pas me faire rotte-ca.

Ça rentre pile-poil. Par contre ça fait que l’écran est vachement bas. Tout l’espace sur la droite est inutilisable, la Disco bouche tout. Par contre au-dessus des jacks je peux mettre une carte, ya la place en hauteur pour des encodeurs (on va l’appeler carte IHM pour la suite). Par contre : comment la faire tenir ? Elle tombe pile entre les deux autres cartes, je pourrais essayer de mettre une connecteur à ce niveau-là, mais il y a déjà les connecteurs de la Disco … Arf, ça veut vraiment pas, cette archi est vraiment reloue. A moins de faire un PCB avec un trou qui laisse passer le connecteur de la Disco, mais là ça devient acrobatique. Comment le PCB d’interface est “trop bas” je ne peux pas déborder sur les connecteurs MIDI, qui me gênent grave ici.

Il y a un “trou” sur la droite, au niveau de la partie debugger de la Disco, ça serait le seul point de passage direct. En plus il faudrait que j’utilise des connecteurs plus courts, sinon ça ne passera pas. Ou alors je la soude ? Ça me plaît moyen, mais ptet c’est la seule solution viable ? En plus ça donnerait de la rigidité, comme je n’ai pas d’autre point d’attache je n’ai peut-être pas d’autre choix :-/Prévoir une fixation avec vis + entretoise sur la gauche de la carte IHM ? C’est crado et ça demande du soin sur le perçage (pas moyen de se repérer en direct, il faut percer au bon endroit “à l’aveugle”) mais j’ai l’impression que je n’ai pas trop le choix.

Quelles autres options pour cette carte IHM ? Y attacher directement à des pins de la Disco ? Il faudrait que je soude, vu la hauteur ya pas moyen d’utiliser un connecteurs. C’est … Bof. Et surtout ça impose d’utiliser les pins qui sont de ce côté, et de les grouper, parce que ça voudrait aussi dire qu’il n’y aurait pas moyen de connecter ces pins sur la carte d’interface, donc ces pins seront sacrifiées pour la carte IHM. Je vais abandonner cette idée.

Si j’ajoute des connecteurs à 90°, ça donne un empilement dans ce genre :

Pfiou … J’ai déjà passé plusieurs heures sur l’archi mécanique, je n’ai même pas encore touché au schéma et au routage :( Quelle joie ce projet.

… Est-ce que je ne pourrais pas supprimer un connecteur MIDI (le THRU, ou le OUT dont je ne vois pas trop à quoi il pourrait servir) pour me garder un bout de place pour dépasser sur la gauche en haut ? Après un petit tour sur thomann pour voir ce qui se fait sur les multi-effets, avoir 3 prises MIDI est rare, souvent c’est 2, avec MIDI in et MIDI out, ou MIDI in et MIDI out/thru, donc je pense que je peux supprimer la prise MIDI du haut. Pour faire un MIDI-through on va juste connecter la “sortie” du front-end du IN vers un driver de sortie identique à celui du MIDI out. Donc pour faire la double fonction OUT+THRU on peut soit avoir un switch qui vient connecter le driver à la sortie UART du MCU ou à la sortie du front-end du MIDI in. Sinon on peut carrément faire un merge dans le MCU, genre il prend tous les messages qu’il reçoit en entrée (voir on peut les filtrer aussi) et les renvoie sur son out, en y ajoutant les messages que lui-même génère, et il refait un séquencement. Ça a l’avantage de la flexibilité, par contre ça veut dire qu’il faut gérer les collisions (ce qui n’est pas forcément u gros problème, mais il faut le faire).

Donc on va partir là-dessus : carte d’interface qui dépasse en haut à gauche, et carte IHM en “U”.

Carte IHM

Sur cette carte IHM je vais mettre des encodeurs et des boutons poussoirs en CMS, comme ça j’aurai aussi des boutons physiques qui ne prendront pas trop de place. Il faut que je choisisse si je prends des boutons tactiles “hauts”, ou si j’en prend des “normaux” auxquels j’ajoute un capuchon. C’est surtout un problème esthétique plus que technique, mais il faut que je choisisse avant de router. Dans tous les cas ils seront ronds, parce que, bon, faire des trous ronds c’est plus facile que faire des trous carrés. Est-ce que je mets des LEDs ? Je peux le provisionner. Est-ce que je les commande directement du MCU ou je mets un 595 ? Je verrai ce qu’il me reste comme pins dispo une fois que j’aurais tout assigné.

Choix des boutons : a priori la série B3FS chez OMRON a l’air pas mal, ya du stock, et du choix sur la force de pression, et ya du stock de capuchons, en noir, blanc et rouge (je pense je vais prendre les trois couleurs). Modèle exact : B3FS-1012 mais j’ai peur que le capuchon se barre, donc il faudrait plutôt du B3FS-1050 mais c’est 3 fois plus cher, et ya que le modèle avec la pression minimum (100g) qui est dispo chez Farnell. Sinon avec capuchon séparé, l’idéal c’est d’en avoir avec un épaulement pour qu’il soit retenu par la façade.

En switches avec LED intégrée, ya du Multimec, mais les modèles avec LED coûtent plus de 2 fois plus cher que les modèles sans, qui sont déjà deux fois plus cher que la plupart des autres. Est-ce que ça vaut le coup ? Grmpf … Je sais pas.

Chez Multicomp ya les MCDTS2 avec leurs capuchons. Ya du choix de couleur, c’est pas cher et ya du stock, c’est pas mal.

Chez C&K, du français, cocorico ! Ya la série D6, traversants, mais qui sont sans doute plus simples à mettre en oeuvre, pas besoin de capuchon. Très old-school je trouve. Et pas trop cher et choix de couleur et du stock. Attention yen a aussi des carrés, il faut bien prendre les ronds. Dans le même genre mais en CMS ya la famille KSA mais là il faut prendre les capuchons avec, qui ont épaulement donc ils ne risquent pas de se barrer. Ya moins de stock, mais c’est à peu près le même prix et ya du choix de couleur pour les capuchons. Ya la série KSC aussi, mais les capuchons n’ont ps d’épaulement, donc c’est un coup à ce qu’ils se barrent.

Chez APEM, PHAP-50 et leurs capuchons. Pas trop de stock, même prix que les autres, et ya du choix de couleur.

Les C&K D6 sont légèrement plus bas qu’un encodeur “standard” (5mm pour 6.5mm) mais le “capuchon” sort de 7mm, ce qui devrait être largement suffisant pour les faire affleurer du boîtier. Sinon des KSA en CMS mais je ne sais pas si ça va vraiment être nécessaire de les prendre en CMS. Par contre 9mm de diamètre c’est un peu gros. Si je veux plus petit il faut prendre soit du Multimec qui propose des capuchons en 6.5mm, c’est très cher (genre au moins 2 fois), soit passer sur des tactiles “basiques” sans capuchons, mais vraiment petits.

Est-ce que je mets un afficheur 7 segments ? Ça fait peut-être un peu chargé, mais pour la lisibilité sur scène ça peut être pas mal, pour afficher le numéro de banque et de preset. Pas un trop grand dans ce cas, parce que l’écran prend déjà beaucoup de place. Combien 15mm max ? 10mm max ?

En alphanumérique, en 13.8mm ya ça et ça, 6-8€, avec deux caractères à chaque fois, en rouge.

Je commence à avoir une idée de ce que je veux faire. L’écran aura plusieurs modes d’affichage: - Affichage des paramètres du preset en cours, - Affichage de la liste de presets pour pouvoir les sélectionner, - Affichage du titre du preset en cours en gros.

Pour chacun de ces modes il y a aura 1 bouton poussoir pour le sélectionner directement, plus 1 pour lancer sauvegarder, et un pour annuler les modifs. Les boutons pour changer de mode pourront être des gros de 9mm, sauvegarder + annuler des petits. Un encodeur avec bouton pour naviguer, un afficheur 7 segments ou alpha pour le numéro de banque + preset actuel, deux LEDs pour indiquer si l’effet est actif et pour un éventuel mode supplémentaire. Peut-être provisionner un ou deux boutons poussoirs en plus ? Il faut que je voie si j’ai assez de ports dispo sur le MCU pour gérer ça en direct, mais je pense que l’afficheur et les LEDs vont se prendre un shift register.

Sachant que je vais autant que possible utiliser les “fameux” encodeurs magiques de chez Bourns, qui ont une LED intégrée, les PELxxx.

Au passage, je ne suis pas obligé d’avoir la carte IHM avant de pouvoir faire des manips, je peux l’ajouter dans un deuxième temps.

Au passage, pour la connexion à la carte d’interface, je peux le faire “en dur” avec un simple connecteur HE10 mâle soudé des deux côtés, mais il me vient à l’esprit que je peux aussi utiliser des connecteurs à 90°. Avec une seule rangée, ça laisse 14mm entre les deux cartes, ce qui laisse 13mm pour le PCB (1.6mm) et les encodeurs (8mm). Ça passe, même limite ça laisse trop d’espace. En double rangée ça fait un peu plus de 4mm et ça laisse un peu moins de 13mm, ce qui est déjà mieux. Si je prends du “vrai” HE10 avec le contour en plastique, là par contre c’est trop épais (8.4mm) et ça ne passe plus. Pour éviter de devoir souder les deux cartes en dur, je vais donc prendre la deuxième option : HE10 90° double rangée sans embase plastique.

Au final ça donnerait un truc du genre:

Point appros

Avant de faire quoi que ce soit d’autre : un point sur les appros. Il n’y a pas que sur les MCU qu’il y a pénurie, et il faut faire le tour des composants actifs pour voir s’il n’y en a pas qui manquent à l’appel. S’il y en a en rupture, trouver un équivalent, et tout commander DIRECT ! On ne route pas tant qu’on a pas un sachet avec tous les composants dedans avec la bonne quantité.

Je pense en particulier aux potars numériques, AD5262 : Rupture de stock partout, cela va de soi. Gênant celui-là, parce que c’est un potar “haute tension”, et yen a pas beaucoup sur le marché déjà de base, donc là c’est chaud. Sur Farnell yen a seulement 4 qui collent, 16 sur Mouser.

Le LM2674 aussi est en rupture, il va falloir que je trouve un autre buck. Recherche rapide sur Farnell, Buck fixe en 5V en boîtier SO, il n’y a que le MAX1776, qui a l’air de faire le taf, un peu cher (7€+) mais le LM2674 était pas donné non plus. Et puis bon, on va pas faire la fine gueule. Sinon en ajustable il y a plus de choix, genre L5972D, TPS54231D, TPS54233D … C’est bon, je vais m’en sortir.

Les MC33202 c’est pas la joie, mais j’en ai en stock et yen a chez Mouser, je devrais m’en sortir (et c’est pas dur à remplacer).

Le STM32F429ZI entre dans la catégorie des MCUs qui ont une granularité faible sur leur Flash, il n’y a que 12 secteurs, donc potentiellement pas trop possible de mettre en place des méthodes pratiques pour la sauvegarde NVM. Ceci-dit, ce n’est normalement pas vraiment un problème si on le gère correctement, ce que je reprendrai dans un article additionnel à mon article précédent qui parlait du découpage de la mémoire. Dans le doute je vais mette une mémoire externe, quitte à ne pas la monter.

Les transistors doubles du modèle exact prévu sont évidemment en rupture, mais ce n’est pas très grave, le modèle exact n’a pas une influence si importante sur le comportement, rien qui ne soit calibrable, donc je vais en prendre d’autres, ça ira bien. En NPN on trouve des 3904, par contre en PNP je vais prendre du BC856, vu qu’il n’y a pas de 3906 dispo.

Pour les JFET, dans l’épisode 2 j’avais fait un petit banc d’essais avec plusieurs modèles, et j’en avais identifié 3 qui avaient un comportement satisfaisant. Le 2SK932 est dispo chez Farnell (chance !), le BF862 et arrêté et en rupture (dommage c’est celui qui avait la plage la plus large), et le MMBT4393 est en rupture. Chez Mouser il y a des MMBF4393 en stock, mais vu que la plage utile est la plus faible des trois je me demande si ça vaut vraiment le coup que j’en commande. En tous cas on va espérer que ceux qui restent conviendront effectivement.

Pour la mémoire externe, si je prends de la Flash SPI je pense que 128Mb seront suffisant (si je veux mettre des wavetables ou si je veux gérer plein de banques pour limiter l’usure), donc un truc comme ça devrait coller. En EEPROM forcément la taille est beaucoup plus faible, et en général c’est de l’I²C, ce qui n’est pas un problème en soi. Je pense 256kB ça suffit, donc un truc comme ça devrait suffire. En regardant les E²PROM SPI, je me rends compte que pour beaucoup en SO-8 elles ont le même pinout que les Flash SPI en SO-8, ce qui est très bien pour moi, ça veut dire que je n’aurai pas besoin de mettre deux empreintes :) I²C ? Conflit avec d’autres ressources sur la carte d’éval, donc pas possible.

Connecteurs, pour la Disco c’est du 2x32 en 2.54mm. Préférentiellement j’aimerais utiliser du CMS, mais j’ai quand-même un doute sur la tenue à l’arrachement. Ceci-dit, la dispo va vite me calmer : aucun modèle n’existe en 2x32 sur Farnell, ya du 2x16, mais pas en stock, et chez Mouser ya que du Samtec à 14€ pièce … 28€ de connecteurs c’est chaud. Sinon en 2x8 yen a à 3€ chez Farnell, ça fait 12€ le connecteur, pas beaucoup mieux. Si je prends du traversant, j’ai du 64 pins, à 3€ le connecteur, je crois la question elle est vite répondue. Je remarque au passage qu’il y a pas mal de connecteurs traversants qui sont vendus avec une réhausse, il faut que je le garde en tête. Au passage, il faut aussi que je prenne des connecteurs pour la carte IHM, et ceux de la carte d’interface avec la carte-mère. Pour ne pas prendre de risques il faut peut-être que je prenne la même taille que les connecteurs de la Disco ? Après, si je prends du standard en 2.54, je pourrai toujours compléter avec des bouts en plus si je me rend compte après la commande qu’il me faut du plus grand, ou je peux recouper si c’est trop grand, donc ce n’est pas critique. Par contre : est-ce que je prends du 2.54 HE10 classique, ou bien autre chose, genre 1.27mm ? Grmpf …

Pour les Bourns PELxxx, j’en ai quelques uns en stock, et, rappel, c’est Mouser-only. Il y en a une déclinaison avec un pas de vis pour y tenir en direct sur la façade, bien entendu aucun en stock. Dans ce qui reste, si je fais le tri, il me les faut en “knurled”, avec switch, vertical, et pour ce qui est LEDs, je prendrai ce qui est dispo. Un en rouge/vert me suffirait, mais arrivage en décembre, donc non. Reste un PEL12D-4225S-S1024 (bleu/orange … Grmpf) et un PEL12T-4225S-S1024 (RGB), je vais en prendre plusieurs de chaque, on verra bien ce que ça donne. Au pire du pire du pire je prendrai des sans LED, je vais provisionner des LEDs traversantes en plus sur le PCB à tout hasard. Note : les PEL12S avec une seule couleur n’ont pas de switch, donc c’est non.

Au passage, petit piège de la part de Bourns : la numérotation des pins est inversée entre les PEL12D et PEL12T … Un coup à se faire avoir, et un rappel qu’il faut toujours check TOUS les symboles et empreintes. Autre petite surprise : les LEDs sont en anode commune sur les PEL12T, mais en cathode commune sur les PEL12D, et le switch est sur le même circuit, donc sur les PEL12D il est en low-side, par contre sur les PEL12T il est en high-side. Tout est fait pour être sûr qu’on se plante en créant les libs et en faisant le schéma.

Pour les connecteurs de la carte IHM, autant les connecteurs mâle en 2 rangée ça se trouve, autant sur Farnell les contreparties femelle c’est pas terrible. Les seuls vraiment en stock ce sont les SAMTEC, donc hors de prix, genre 5€ le connecteur 16 pins … Je vais tâcher de chopper les moins chers, mais à long-terme c’est pas terrible comme solution, visiblement.

Toujours au sujet des connecteurs, l’on pourrait être tenté d’utiliser des connecteurs un peu plus spécifiques avec un profil plus bas, pour gagner en épaisseur, genre les Micro-Match chez TE. Ne pas oublier que ce ne sont pas des connecteurs standards, donc plus difficiles à trouver.

Reprise de l’archi PCB

On a donc deux cartes au lieu de trois : Carte principale et carte d’interface. Avec un gros connecteur entre les deux, dont on va voir l’interface.

Sur le MCU avec l’archi actuelle j’ai ~70 pins utilisées sur le MCU. Si je supprime des contrôles encodeurs, LEDs, ça en retire une dizaine, idem SWD. Par contre attention, je vais peut-être devoir ajouter des digipots et il va y avoir aussi des “échanges” en plus sur la partie analogique pure. On peut donc partir sur une interface de 70 signaux. Si on veut des connecteurs standards, il faudrait plutôt 2x36, donc 72.

Il faut vérifier la répartition des fonctions. Sur la carte principale, on va avoir : les connecteurs, les alims, les circuits de mesure (enveloppe, fréquence), les VCA.

Sur la carte d’interface : la Disco, les digipots (gain, volume), les circuits fuzz factory en eux-mêmes, la mémoire externe, les DAC, la pompe de charge.

J’hésite à chercher des connecteurs “plats” pour pouvoir intercaler une carte intermédiaire, genre ça avec ça, ou ça avec ça. J’ai peur que ça soit beaucoup d’emmerdes et de taf pour pas grand-chose, donc je vais rester sur une seule carte d’interface dans un premier temps.

J’hésite aussi à mettre la pompe de charge sur la carte principale, pour regrouper toutes les alims ensemble. Ça me fait peur de transporter cette alim qui va être bien dégueulasse sur les connecteurs, et j’ai beaucoup de place sur la carte principale maintenant que j’ai déplacé les 3/4 des fonctions qu’elle contenait.

J’hésite encore aussi à mettre un digipot pour le volume de sortie des fuzz. Vu qu’il y a déjà des VCA à la sortie, je me demande si ce n’est pas suffisant, en pratique. Oui, mais les VCA vont donc devoir scaler leur range par rapport au volume de sortie demandé, ce n’est pas dit que ça se passe bien à bas volume. Je pense que je vais les provisionner, je ne les monterai pas par défaut et je verrai si j’ai suffisamment de contrôle sans, et si ça ne suffit pas je les monterai.

Au passage, je me rends compte que je n’avais pas prévu de VCA pour la sortie REF. J’ai bien envie d’en ajouter un tant que je suis là, et aussi un circuit pour pouvoir mixer le REF avec la sortie normale. Et tant que j’y suis ajouter un chemin pour mixer du son dry avec le son saturé ? Grmpf … Ça commence à faire un truc compliqué. Mais bon, tant qu’à faire, vu que je suis en train de multiplier la surface PCB par 2.5, autant en profiter.

D’ailleurs et après réflexion, ça me semble une bonne approche pour rendre le design plus générique, et en faire une vraie plate-forme pour plus d’effets, et pas uniquement pour des circuits type Fuzz Factory. Genre, si je veux faire un truc du même style sur un Octave Multiplexer, par exemple, la carte principale aura tout ce qu’il faut pour ça, il n’y aura “que” la carte d’interface à adapter. Ça ne veut pas dire que ça sera une sinécure.

Si on prend ce nouveau découpage des fonctions, on a beaucoup de signaux à passer vers la Disco (sans surprise, le MCU doit gérer beaucoup de choses), par contre il n’y a pas beaucoup de signaux entre la carte principale et la carte d’interface: - En sortie du MCU les commandes PWM pour les VCA (3), la commande de bypass (1), - En entrée numérique, les footswitches (3), les mesures de fréquence (3), - En entrée analogique, pour chaque signal audio utile le signal en lui-même (pour traitement ADC) + la mesure d’enveloppe en entrée et en sortie de VCA (3 x 3), - L’UART pour le MIDI et la commande OUT/THRU (2 + 1), - Pour la partie analogique, entrée audio (1), sortie Fuzz Factory et sortie ref (2), - Masse (2 voire 4), alim 9V (2), alim 5V (2), commun (1).

Au total ça fait 32 signaux. Je peux économiser deux masses et descendre à 32 pour faire du 2 x 2 x 8, ou bien provisionner et ajouter de l’isolation avec plein de masses et monter à genre 40, 42, voire 48. Par contre, il y a beaucoup plus de signaux qui vont vers le MCU que de signaux qui vont vers la partie analogique, donc je ne vais pas trop pouvoir séparer les signaux sur deux connecteurs selon cet axe-là. Je vais plutôt tâcher de séparer les signaux analogiques des signaux logiques.

Pour les signaux entre la carte d’interface et la carte IHM, on a: - En sortie du MCU, deux encodeurs avec chacun trois signaux RGB (2 x 3), deux commandes de LED (2), - En entrée du MCU, switches d’encodeur (3), boutons poussoirs (5), signaux encodeurs (2 x 2), - SPI pour l’afficheur (4), - Masse (2), alim 5V (1), alim 3.3V (1).

Au total ça fait 28 signaux, ça passe dans 2 x 2 x 8.

Alimentations

La Disco s’alimente nominalement via l’USB, et génère un 5V (qui est le 5V USB vaguement filtré) et un 3V, qui est issu d’un 1117-33 avec une Schottky en série, donc plus 3V que 3.3V. En standalone on peut alimenter la carte via le 3V ou le 5V. Sur l’archi actuelle j’ai un 3.3V généré via un buck, et un 5V généré via un LDO. Il n’y a pas d’indication de la consommation de la carte dans sa doc, ils disent juste qu’il ne faut pas tirer plus de 100mA sur les alims. Par contre ils ont mis un jumper en série sur le 3V pour pouvoir mesurer le courant consommé par le MCU. Ben tiens, j’ai un Doom chargé dessus et un multimètre, faisons la mesure tout de suite : j’obtiens 80mA. Mais ça c’est le MCU seul, il y a aussi le debugger, la RAM, le LCD (le backlight doit pomper méchamment) … Il faudra que je fasse une mesure sur le 5V. Sur de l’USB 2.0 la conso max standard c’est 100mA, avec possibilité de tirer jusqu’à 500mA. Je pense que je vais partir sur 500mA sur l’alim générale 5V, pour ne pas avoir de mauvaise surprise. Donc je vais faire uniquement un 5V avec un buck à partir du 9V. Vu que le connecteur d’entrée de l’alim est sur la carte-mère, je vais laisser l’alim 5V dessus. Je vais virer le LDO qui ne sert donc plus à rien, il n’y a plus qu’une alim 5V.

Pour les digipots, je vais provisionner une alimentation double (à base de pompe de charge) que je ne monterai que si je n’arrive pas à les faire marcher en 0-9V (même si cette config est bien indiquée dans sa doc).

L’archi des alims va donner un truc dans ce genre:

J’arrive à ~600mA de conso sur le 5V. En vrai ça sera moins, mais ça veut dire que par précaution il faut que je fasse un buck 600mA. Ce qui donnera une conso de ~330mA sur le 9V, il faudra faire gaffe à l’alim que j’utilise.

J’avais mis un MOSFET de protection anti-inversion, il faut que je fasse gaffe à son dimensionnement. Je me rends compte que j’avais aussi mis un MCP51 en protection anti-inversion côté alim. Je ne sais pas trop pourquoi j’avais fait ça, mais ça fait double emploi avec le MOSFET, donc je le dégage.

Il faut que je fasse attention car le MCU est en 3.3V, mais l’alimentation principale est en 5V, donc je vais laisser toute la logique sur la carte principale en 5V (le MIDI surtout), et il faudra que je fasse gaffe de protéger les entrées sur la carte intermédiaire.

Design de la pompe de charge

Pour la pompe de charge, j’hésite entre partir sur un circuit tout fait mais cher, ou faire une pompe de charge “à la main”. J’avais déjà fait des simulations pour un circuit dans ce genre, et a priori ça me revient moins cher de le faire à la main. Mais bon, aussi, j’ai ptet pas envie de m’emmerder, et je peux partir sur un ICL7662 par facilité. Après le problème c’est que la fréquence de découpage de ces composants est pile dans la bande audio, et il faut trouver les modèles ultra-chers qui permettent de monter à 25kHz, ou alors les clocker sur une horloge externe pour les forcer à découper plus vite. Donc à ce niveau ça vaut ptet le coup de se passer de composant dédié et faire un driver en discret, et contrôler ça par le MCU. Je pense que les composants tout faits sont chers surtout pare qu’ils contiennent tout ce qu’il faut pour être totalement autonomes : driver, oscillateur, protections. Et en plus ils permettent d’avoir plusieurs topologies différentes (doubleur, inverseur …). Or, ici je ne veux qu’une seule topologie, et j’ai un composant qui peut générer une horloge et en plus réguler, donc je n’ai pas d’intérêt à m’enchaîner à un composant dédié.

J’ai re-sorti LTSpice pour l’occasion:

La simu donne ça:

Ça coûte 3 transistors, deux diodes et deux capas : adjugé vendu ! J’ai presque envie d’en faire une aussi pour générer une tension de 18V, mais les digipots vont commencer à ne pas aimer, à moins de mettre des régulateur linéaires derrière, et là ça devient peut-être un peu lourd. Je vais juste tâcher de mettre des petites selfs BLM en série pour pouvoir séparer l’alim le cas échéant, si ça merde et que je me retrouve à devoir ajouter une pompe de charge en verrue.

Re-design de l’interface MIDI

Je fais une section spécifique mais ya pas grand chose à dire : je vire la double interface OUT + THRU, je mets un seul connecteur pour les deux, et avec le quad-NAND j’ai juste ce qu’il faut en portes logiques pour faire un multiplexeur 2:1. Par contre je n’ai plus de quoi faire un buffer dédié pour le IN, et je n’ai pas envie d’ajouter un composant pour ça. J’espère que ça ne sera pas un problème :-/

Design de la détection de crêtes

Je suis retombé sur l’article de ESP à propos des redresseurs de précision. Et je suis en train de me rendre compte que le circuit que j’ai prévu de faire a des défauts qu’il vaudrait mieux que je corrige avant d’avoir des problèmes et de me retrouver le bec dans l’eau.

Pour rappel, le circuit que j’ai fait à l’époque est une sorte de compilation des différents circuits de détection de crêtes que j’ai développé au fil du temps sur les projets Trublion, en partant sur la base d’un détecteur de crête du Rhodes MK3. Il est conçu pour fournit un signal 0-3.3V de façon à exploiter au maximum la plage d’entrée des ADCs du MCU. Le redressement en lui-même est un full-wave “classique”, relativement basique, avec un LM1458 (ampli-op compensé, encaisse de grosses capas sur sa sortie, préférable dans ce genre d’application), qui a quelques problèmes, de ce qui est dit dans la section “Full Wave Precision Rectifiers” de l’article. En particulier il impose d’avoir une impédance basse en entrée, or j’en ai u en direct sur l’entrée guitare sans buffer … Not good. De plus, la résistance de feedback va fournir un chemin de décharge pour la capa, et même si elle fait 100k, ce n’est pas souhaitable, et il a des problèmes de réponse en haute fréquence, il faut des diodes rapides et un AOP rapide, et la tolérance des résistances est critique pour avoir une mesure correcte. Par contre ce circuit aurait une bonne linéarité pour des signaux faibles (de l’ordre du mV), d’accord. Globalement, ça ne me semble pas souhaitable de garder un circuit avec autant de défauts.

Tout le reste du circuit sert à mettre en forme le signal de sortie pour qu’il entre dans la plage des ADCs du MCU, avec du réglage pour calibrer sur carte, c’est juste du gain et de l’offset. J’ai aussi ajouté un driver pour le rail commun (Vcom, VCC / 2), qui utilise le deuxième AOP du LM1458.

Testons donc les autres circuits proposés dans l’article ESP. Celui basé sur la note d’appli Analog Devices (note d’appli que, d’ailleurs, je n’ai pas réussi à trouver en cherchant directement sur le moteur de recherche du site d’AD, il faut chercher la ref dans google en direct …) ressemble beaucoup, surtout après remplacement du FET par une diode. Différence principale : il y a deux AOP, et le premier est monté en non-inverseur, ce qui permet de couper le chemin de fuite de courant de la capa vers l’entrée. En mettant des Schottky (BAT54) on obtient un bon résultat même à 10kHz.

Par contre, inconvénient : la sortie est drivée en direct par un AOP, donc il va réguler la tension aux bornes d’une éventuelle capa de sortie. Donc il faut ajouter une autre diode en sortie pour que la capa lisse le niveau et ne suive pas “bêtement” la sortie de l’AOP. Pour cela, la variante “Neve” donnée sur la figure 6B est intéressante, car elle ajoute un troisième AOP qui fait buffer après la capa de filtrage, et le premier étage peut être modifié pour ajouter du gain. Ceci-dit, il faut toujours mettre en forme le signal en sortie pour le faire entrer dans la plage de fonctionnement de l’ADC.

Les autres topologies proposées après sont moins intéressantes ou trop spécifiques aux drivers de vu-mètre à aiguille, donc je vais partir de ce design et tâcher de le modifier pour avoir du gain et de l’offset pour l’ADC.

Au final, comparé à la topologie que j’avais avant, ce n’est pas une révolution : au lieu de bufferiser la tension de la capa puis de faire un sommateur pour gérer l’offset, maintenant j’ai deux AOP en amont pour le redressement, et un seul qui fait buffer + offset. Je vais ajouter des trimmers pour ajuster le gain et l’offset, même si ça m’embête parce que ça va prendre de la place. Mais dans le doute je préfère les provisionner.En fait je vais en prévoir pour le gain seulement, pour l’offset c’est moins critique, ça peut se corriger en SW, et au pire je perds de la résolution.

Je garde les deux AOP doubles, un compensé pour driver la tension de référence et pour driver la capa de filtrage de détection de crête, un en rail-to-rail pour driver l’ADC, et en buffer en entrée. Pour l’offset, il faut une tension proche de 9V, donc je mets juste un pont diviseur et j’ajusterai les valeurs exactes sur circuit, pour ne pas sortir de la plage de fonctionnement de l’AOP de sortie.

Je suis tombé récemment sur ce projet sur github, extrêmement intéressant. Il s’agit d’un octaver sub-harmonique, dont le principe général est similaire à celui d’un Octave Multiplexer, à la différence qu’il est plus complexe et ne génère qu’une seule harmonique. Je parlerai peut-être plus en détail de ce circuit dans un autre article, toujours est-il qu’il utilise un détecteur de crête synchrone à base de sample-and-hold, qui a l’air relativement efficace. Je garde cela dans un coin de ma tête, il faudra que je fasse des manips autour de ce type de circuit.

Mesures analogique

Pour les ADCs, il y a un problème : il n’y a que 16 entrées, et plus de la moitié est déjà bouffée par les périphériques. Décompte des signaux analogiques dont j’ai besoin: - Peak audio in - Peak audio in après VCA - Peak audio out - Peak audio out après VCA - Peak audio ref - Peak audio ref après VCA - Polarisation x2 - Polarisation ref x2 - Deux entrée pédale d’expression - Optionnellement : audio in et audio out

Ça fait 12, voie 14 signaux, donc ça ne passe carrément pas. Il faut soit multiplexer, soit utiliser des convertisseurs externes.

Pour multiplexer on va passer par des 405x, ce qui suppose d’avoir des signaux de contrôle. On peut mettre plusieurs multiplexeurs en parallèle, vu qu’il y a 3 cœurs ADC on peut par exemple envisager 3 x 4051 en 8:1, ce qui porte le nombre d’entrées à 24, ce qui est largement suffisant. Et pour ça il faut 3 entrées analogiques, et3 sorties de signaux de contrôle.

Après check des entrées dispo, de toutes façons il n’y a que trois pins ADC qui ne sont pas connectées à des trucs sur la carte : PA5 (ADC1_IN5), PC3 (ADC2_IN13) et PF6 (ADC3_IN4).

Concernant l’ADC externe en SPI. Ça coûte plus cher, en HW et en SW, mais ça intègre tout ce qu’il faut et on ne se pose pas la question du switch analogique. Idéalement il faudrait que j’implémente les deux … On va voir. Pour ce qui est du choix du modèle, je pense il faut tabler directement sur un 8 canaux, en SPI, en SAR (delta-sigma c’est un peu trop haut-de-gamme et compliqué à gérer) et en 12 bits, parce qu’au-delà les stocks ne me rassurent pas (les prix non plus). Pour la bande passante, 100kSPS ou 200kSPS devrait suffire.

Vu que je suis parti chez Mouser, je vais partir de ce qui est dispo chez eux. Yen a entre 5€ (Microchip plutôt) et 15€ (Maxim plutôt, la routine). Globalement il y a deux “types” différents : avec clock dédiée ou pas, dans le deuxième cas l’ADC se clocke sur la SPI. Le premier doit avoir l’avantage de permettre de configurer du scan automatique, l’autre doit être moins cher, je pense. Avec clock dédiée et suffisamment de stock, il y a le TLV2553 de chez TI, 11 canaux, 200kSPS, 11€HT. Sans clock dédiée, il y a le MCP3208 de chez Microchip, 8 canaux, 4.6€HT, 100kSPS \@5V.

Concernant le sample rate, il ne faut pas se tromper : vu qu’il y a plusieurs canaux, ce sample rate est partagé entre les canaux. Si on prend l’exemple du MCP3408, qui est clocké sur la SPI, il est indiqué que la fréquence max de la SPI est 2MHz. Il y a 12 bits à récupérer, on ne récupère qu’un seul canal à la fois, et il faut envoyer des commandes pour embrayer la conversion et pour indiquer ce que l’on veut. En pratique si on suit la datasheet une trame de lecture prend 24 bits, à 2MHz ça fait 12µs, ce qui donne 83kHz, ce qui serait le sample rate maximal théorique qu’on aurait si on ne lisait qu’un seul canal. Donc en pratique si on lit en permanence on a 1/8 de ça, donc à peu près 10kHz au mieux sur une seule mesure. Ici de toutes façons on aura pas les moyens de traiter les mesures aussi rapidement, donc ce n’est pas un souci, mais c’est à garder en tête.

Le MCP3208 est dans les libs Kicad, pas le TI -> je prend Microchip, ça fera l’affaire !

Vu le nombre de mesures à faire, il faut au minimum 2 convertisseurs, pour avoir 16 entrées. idéalement il faudrait 2 SPI séparées, mais je doute que j’aurais assez de pins dispo, donc on va partir du principe que tout cela est multiplexé sur le même bus et partagé aussi avec les digipots (ne pas oublier). Ça va faire du monde … Et donc il faut des chip select, 4 pour les digipots, 2 pour les ADC, 6 au total, en plus des 3 signaux SPI, donc 9 au total.

J’ai bien envie de provisionner un CODEC aussi, à tout hasard. J’ai une dizaine de vieux AKM que j’ai récupéré via un pote qui était en stage en Chine, et en ce moment on trouve des Cirrus Logic qui ont l’air correct à un prix … hum … raisonnable, genre celui-là. La plupart des CODECs sont stereo, mais j’ai trois signaux audio pertinentes : entrée, sortie fuzz, sortie ref. Problème … Et je ne vais pas mettre un codec 4 voies pour ça. Je ne sais pas trop ce que je ferais des flux de ces CODECs, donc autant ne pas y penser et oublier cette idée. A noter : à partir du moment où l’on se limite à des boîtier SOIC / TSOP / QFP le choix est drastiquement réduit. Ce qui est dommage parce qu’il y a plein de modèles disponibles à des prix intéressants, mais en QFN … C’est non.

Définition des bords de carte

La carte principale / carte-mère va garder le même board outline. Pour rappel, j’avais dessiné le board outline dans Kicad, je ne l’ai pas fait dans Freecad.

Pour les deux autres, ce que je fais pour gagner du temps c’est copier-coller le EdgeCut de la carte principale et les dimensions que j’ai mis sur le Eco1. Puis je mets tous les segments du EdgeCut sur Eco2, ce que Kicad ne permet pas de faire en groupe, il faut le faire segment par segment :( Relou mais bon. Comme ça, j’ai une sorte de canvas avec le bord extérieur “maximum”. Puis j’ajoute les découpes sur le EdgeCut, et je duplique les segments dont j’ai besoin pour compléter, du Eco2 vers le EdgeCut. Comme ça, aussi , je peux voir les overlap entre les cartes.

J’ai prévu des chanfreins de 4mm pour l’extérieur, je vais les ré-utiliser pour les découpes concaves, pour ne pas me faire tirer les oreilles par le PCB-house qui va devoir découper ça à la CNC. Au final ça donne un truc comme ça:

Et en surlignant les différentes cartes, en bleu la carte IHM, en rouge la carte d’interface:

On voit bien l’overlap en violet, où je placerai les connecteurs de la carte IHM. Ce n’est pas encore totalement figé, en fonction du placement je vais sûrement retoucher des choses. Il serait pratique que j’arrive à insérer un connecteur sur le bord commun entre les deux, ça serait mieux pour la tenue mécanique. Ceci-dit 1) je n’ai sans doute pas la place à cause du connecteur de la Disco et 2) les jacks en-dessous vont sûrement gêner. Il vaut sans doute mieux que je prévoie des trous de fixation, et je mettrai des entretoises quelconques, ça ne va pas être très simple à fabriquer, mais je ne pense pas que j’aie vraiment le choix. Le “vrai” design correct imposerait de refaire une carte équivalent à la discovery, mais on en a déjà parlé : plus tard, beaucoup plus tard.

Au final ça va faire exploser le coût du PCB, pas trop le choix :-/

Au passage je vois que la largeur de contact entre IHM et interface sur la gauche est faible, dans les 17mm, ce qui fait max 6 rangées en 2.54mm … Donc je ne peux pas mettre du 2x10 ni même du 2x8 de ce côté-là. Côté droit j’ai 37mm, ce qui permet de caler 14 rangées, donc je pourrais plutôt ajouter des pins à droite et en enlever à gauche. Ça empêche d’utiliser deux fois les mêmes connecteurs, mais ça permet aussi de faire du poka yoke, donc l’un dans l’autre c’est peut-être pas plus mal.

Après check chez les distributeurs, j’ai l’impression qu’il est plus facile de trouver du 24 voies que du 26, donc on va faire 12 voies à gauche, 24 à droite, et ça ira bien.

Pinout MCU

Il faut bien entendu repartir de zéro pour le pinout du MCU. Pour gagner du temps et éviter les erreurs, on va créer le projet CubeIDE et assigner les ressources au fur et à mesure, en vérifiant que les pins sont dispo sur les connecteurs via le user’s manual. Pour le projet CubeIDE on passe par TouchGFX, ça permet de générer un projet CubeIDE qui a déjà tout ce qu’il faut, et un .ioc configuré correctement.

Au passage : faire de la gestion de version avec les projets CubeIDE et TouchGFX c’est vraiment la hess, dès qu’on va prendre un template de gitignore ya plein de fichiers qui sont virés et qui sont nécessaires pour compiler, surtout que TouchGFX se base fortement sur des librairies pré-compilées. Ultra-chiant.

TODO

Check du stock : boîtier, connecteurs, encodeurs, switches Check / création du symbole et de l’empreinte pour la Disco => connecteurs “en l’air”. Check des digipots, classement par famille compatible + check / création symboles.

Commencer par la carte d’interface, plus simple, et de toutes façons je vais jeter l’intégralité de ce qu’il y a dessus : schéma, board outline, placement connecteurs, puis placement / routage.

Puis la carte-mère, sur le schéma je vire ce qui est supprimé ou qui passe sur la carte d’interface, entre autre les signaux MCU qui partent vers le connecteurs de la carte d’interface. Côté routage, je ne touche pas aux connecteurs, ni aux switches, ni au board outline. Je vire les fonctions inutiles et celles qui passent sur la carte d’interface, je regarde comment mettre les connecteurs de la carte d’interface et je réorganise à partir de ça. Ça limitera les modifications, et ça devrait me permettre de garder des bouts de routage, toujours ça de pris.

Grmpf … Tous les noms d’empreintes qui ont ENCORE changé, genre Resistors_SMD qui devient Resistor_SMD sans “s” … Relou … Argh ! Et en plus R_0603 devient R_0603_1608Metric fuuuu … ‘Tain la conversion va être longue et chiante …

Et sur les boutons poussoir, ya pas une empreinte qui ait un pinout compatible avec les symboles dispo. Comment c’est possible de sortir des lib autant incohérentes ?

Pinout

SPI : 14-segments, digipots, E²PROM, total 10 clients, donc 10 chip select, ça commence à faire beaucoup … Je pense qu’il vaut mieux que je mette tous les digipots ensemble vu qu’ils gèrent le son en live, et mettre l’affichage et l’E²PROM à part. Le truc c’est que les digipots ne sont pas tous sur la même carte, donc il va falloir que je les re-découpe, car je ne pense pas que ça soit une bonne idée d’avoir une SPI qui va sur plusieurs cartes. Donc a priori 3 SPI et 10 chip select.
PWM (sorties) : VCA du signal d’entrée, VCA FF et REF, DAC FF et DAC REF (2 chacun), commande pompe de charge, je ne vais pas pousser le vice jusqu’à mettre du PWM sur les LEDs, si je dois dimmer je le ferai à la main, tant pis. Donc au total 8 PWMs. Je vais mettre sur les mêmes TIM les “2 canaux” de chaque DAC : TIM9 pour DAC FF, TIM12 pour DAC REF (ces TIM n’ont que deux canaux). TIM2 CH1 pour VCA in, TIM2 CH2 pour VCA FF, TIM4 CH2 pour VCA REF. Et pour la pompe de charge, il reste un canal en TIM1 CH1(N) pour la pompe de charge.
UART : pour le MIDI, et on garde celle du VCOM, donc total 2.
ADC : 2 mesures de polarisation par circuit, crête entrée et sortie du VCA, crête entrée et sortie de l’effet, crête entrée et sortie REF, 2 entrées pédale d’expression, et on va provisionner le signal d’entrée, le signal de sortie et REF. Total : 15 (12 si on enlève les signaux directs).
PWM (entrées) : mesure fréquence entrée, effet et REF. Total 3. Les TIM du STM32 peuvent être configurés en mode “encoder” (sauf les TIM9 à TIM14) donc je vais essayer de câbler les entrées des encodeurs là-dessus, des fois que ça me permette de sauver du temps CPU. Par contre, vu le nombre de pins déjà prises sur la Disco, il n’y a que le TIM2 et TIM3 qui sont configurables en encoder, TIM5 aussi si on n’utilise pas les pins IN0 et IN1 de l’ADC. Par contre, ça me bouffe 2 signaux PWM à chaque fois, donc 4 au total, sachant qu’il m’en faut déjà 8+3 pour les “vraies” fonction PWM. Par contre, sur les TIM qui ont 4 canaux ça laisse les deux derniers dispo, toujours bon à prendre. Donc je mets les encodeurs sur TIM3 (CH1 et CH2) et TIM5 (CH1 et CH2). J’aurais bien voulu mettre les entrées de mesure de fréquence sur les canaux 3 et 4 de ces mêmes TIM, mais 3 sur les 4 entrent en conflit avec d’autres fonctions et ne sont pas dispo. Damned … Donc je vais devoir les mettre ailleurs. Encore un problème de conflit : les canaux 3 et 4 sur ces trois TIMs ne peuvent pas être configurés en sortie PWM non plus, donc les utiliser pour les encodeurs est vraiment de la “perte sèche” de ressources (parce que si je gère les encodeurs sur des GPIO je peux les mettre sur n’importe quelle pin). Il reste TIM1 CH2 pour la mesure de fréquence du signal d’entrée, TIM1 CH3 pour la sortie FF, TIM3 CH3 pour la sortie REF. Et il n’y a plus aucune ressource PWM disponible après ça \o/
GPIO (sorties) : commande MIDI out/thru, LEDs encodeurs (3 par encodeur, on et en RGB), LEDs “seules”, commande relai bypass, chip select SPI, commande multiplexeurs. Total : 22.
GPIO (entrées) : footswitches, encodeurs (2 signaux par encodeurs), switches poussoirs encodeurs, autres boutons poussoirs. Total 14.

Vais-je avoir 36 pins disponibles ? Rien n’est moins sur … Dans le user manual il y a le pinout complet avec tous les signaux dispo sur les connecteurs et leur assignation, on peut y voir les signaux qui ne sont pas utilisé par un périphérique.

PA0, PB4, PB7, PC3, PC11, PC12, PC13, PD2, PD4, PD5, PD7, PE2, PE3, PE4, PE5, PE6, PF6, PG2, PG3, PG9, et en piquant le bouton et les LEDs PG13, PG14 et PA0. Ça fait 23 au total, dont il faut défalquer les 3 ADCs. Il manque donc 15 signaux.

je peux dé-souder les micros, mais ça me fait gagner 4 signaux. Tout le reste c’est pour le LCD et le SDRAM dont j’ai besoin pour l’affichage.

Fuuuuu … Il faut que je m’y prenne autrement.

Changement d’épaule

Mieux vaut s’en rendre compte maintenant plutôt qu’après avoir fabriqué. Par contre je n’ai pas masse d’options disponibles.

Une autre carte d’évaluation disponible et pas trop chère avec écran tactile et suffisamment d’IOs ? Je doute d’avoir la patience et le courage d’en trouver une.

Ajouter un processeur à côté ? Relou à intégrer. Mettre une autre Nucleo que j’intègre tant bien que mal dans la méca ? Ya pas beaucoup de place … Ceci-dit, foutu pour foutu je peux repenser l’architecture de la partie commande. Étudions donc ça.

Si on reste dans les cartes dévaluation que j’ai envie d’utiliser, à savoir Nucleo / Discovery, les Nucleo 32 ont 22 signaux dispo sur leur connecteur, les Nucleo 64 en ont 52 sur les connecteurs Morpho. Une 64 aurait assez de signaux au global, et une 32 aurait assez de signaux en plus de la disco 429 pour compléter, donc on pourrait partir sur une Nucleo 32 additionnelle. Difficile à faire rentrer dans l’archi méca actuelle, mais peut-être en agrandissant le boîtier ? Ca ne m’enchante pas trop de re-partir sur un choix de boîtier (surtout que j’ai déjà acheté au moins deux exemplaires de l’actuel), mais si ça me permet de sauver le projet il faudra bien y passer.

Et si on changeait carrément la carte IHM ?

Sur la Discovery STM32F746G il y a 22 signaux dispo sur le connecteur Arduino, avec une Nucleo 32 en plus on arrive donc à 44 au total sur les deux cartes, pour 36 requises, sur le papier ça passe. L’écran et bien plus grand, ya plus de puissance, par contre elle est plus grande puisqu’elle fait 130 x 88, contre 120 x 66 pour l’actuelle.

Discovery 469NI, plus fine, 127 x 60 (même taille que l’actuelle), écran 4”, connecteurs Arduino mais aussi connecteur additionnel qui donne accès à des signaux en plus (je n’en ai pas vu en commun en tous cas). Je compte 22 + 11, donc avec une Nucleo 32 en support, ça marche aussi.

Pour rappel une Nucleo 32 c’est 20 x 7.5, une Nucleo 64 82 x 70.

Si on garde le boîtier actuel (1590XX), la 469NI est un peu trop longue, la 746G bouffe de la place sur les footswitches, en vrai il n’y a que l’actuelle (429ZI) qui rentre. Et je ne vois pas trop où j’ai du volume dispo pour rentrer une Nucelo, tout est déjà bien blindé. Pas le choix, il va falloir changer le boîtier :(

En plus grand dans la série 1590 chez Hammond, et en restant à ~35mm de hauteur il n’y a que les 1590DD et 1590BX2. Le BX2 est vraiment trop en longueur, pas pratique, donc reste le DD, que j’avais voulu éviter parce qu’il a des renforts au milieu de sa longueur, ce qui n’est absolument pas pratique pour placer des jacks et des switches. mais bon, on fait comme on peut.

Je me limite à ces boîtiers-là parce qu’ils ont une hauteur raisonnable (35-38mm), faire plus haut ça devient vraiment casse-gueule - dans tous les sens du terme. Ce qui aussi limite la marge de manœuvre sur le placement des cartes à l’intérieur, puisque ne disposant pas de beaucoup de hauteur, il y a vite interférences et conflits, les connecteurs n’arrangeant rien, ça impose vraiment de ne pas superposer les cartes entre elles et avec les connecteurs. En particulier, la carte avec l’écran va entrer en conflit avec les footswitches, qui sont aussi sur la façade, mais pas forcément avec les connecteurs, qui sobt sur la carte du fond. En prenant tout cela en compte, la 746G est encore vraiment trop grande, voilà, c’est dit. A moins de ne pas mettre de footswitch au milieu, et donc faire pas symétrique, ou mettre 4 footswitches, et même le connecteur ethernet va gêner.

L’actuelle (429ZI) et la 469NI par contre laissent la place pour le reste, et elles n’ont pas de connecteur “haut” ailleurs sur la carte qui pourrait faire interférence (ça tombe bien, je n’en ai pas besoin). Donc je pense que je vais partir sur une 469NI pour disposer d’un grand écran. Dommage, j’ai acheté deux 429ZI en rab pour ce projet … Tant pis, comme pour les boîtiers. Après j’en trouverai bien l’usage ailleurs, va.

Mon idée serait d’avoir la Nucleo qui gère les algo et le son, et la Disco qui fasse les interfaces, IHM mais aussi MIDI, expression, UART pour le debug et le remote. Pour avoir un peu de marge au niveau de l’algo, je pense que mettre une Nucleo F432 serait bien, qui gérerait donc les mesures des signaux audio (peak, input capture) et les signaux audio en eux-mêmes, les PWM pour les VCA, ça ferait 4 PWM, 6 + 3 ADC, 3 input capture, et la com avec l’autre carte, donc une SPI 4 signaux (UART ?), donc 20 signaux. Elle va être bien chargée, je vais déjà vérifier que je peux assigner autant de ressources différentes sur une Nucleo 32. Ah, il faudrait aussi gérer les digipots … Grmpf … Visiblement il va falloir que je garde un multiplexage des ADC. Et ptet plutôt un UART pour la com avec l’autre carte ?

Conclusion

L’article est déjà bien assez long, je vais refaire un autre article pour le re-re-design, sinon ça va encore faire 50 pages.

A terme et idéalement il faudrait modifier (encore …) le design pour ne pas dépendre d’une carte d’évaluation (ce qui est toujours une mauvaise idée niveau pérennité), ce qui supposera de refaire un design de carte équivalente, donc avec MCU + écran + mémoire, et donc cela supposera d’arriver à obtenir des composants, ce qui n’est pas gagné. Mais qui sait ? Un jour peut-être.