Bonjour, en m'inspirant comme vous de Paul Beckmann (DSP Concepts) et de Paul Stofffregen (PJRC), j'essaie d'arriver à ce que des puces ARM Cortex-M exécutent du traitement numérique du signal audio en temps réel.
Les cartes de prototypage suivantes, que tout le monde peut se procurer à l'unité chez Mouser, sont présentées par STMicro comme "ARM MBED Enabled". Leur connectivité qui est compatible Arduino, comporte de nombreuses broches supplémentaires permettant à l'application d'exploiter la totalité des périphériques situés dans la puce.
- STM32F072RB Nucleo - Cortex-M0 - 9,13 eur - 2 x simplex I2S
- STM32F446RE Nucleo - Cortex-M4 - 12,38 eur - 3 x simplex I2S et 2 x SAI
- STM32F446ZE Nucleo - Cortex-M4 - 16,80 eur - 3 x simplex I2S et 2 x SAI
- STM32F746GZ Nucleo - Cortex-M7 - 20,33 eur - 3 x simplex I2S et 2 x SAI
- STM32H743ZI Nucleo - Cortex-H7 - 20,33 eur - 3 x duplex I2S et 4 x SAI
Il serait bon que Node-Blue permette à l'architecte audio de définir l'un ou l'autre module de son canevas, en langage assembleur plutôt qu'en langage C ANSI. Selon que l'architecte audio cible une puce Cortex-M0+, ou Cortex-M4, ou Cortex-M7, il peut écrire un code assembleur spécifique qui recourt aux mnémoniques ARM, qui n'a rien de compliqué, qui exploite au maximum le jeu d'instruction de la puce. La réflexion à ce niveau porte sur les possibilités suivantes : virgule fixe ou virgule flottante, multiplication-accumulation, auto-incrémentation de pointeurs, boucles rapides, SIMD. Selon le jeu d'instructions disponible, selon les mémoires cache disponibles, on devra dérouler les boucles, séquencer les calculs d'une façon particulière, etc. Kishore Dasari (DSP Concepts) a produit un bon papier à ce sujet : Designing with the Cortex-M4 - Arm. Kishore Dasari parle de modules simples tels un filtre Biquad IIR, une cascade de filtres IIR Biquad, un filtre IIR long de 256 échantillons, un filtre IIR long de 2048 échantillons.
En ce qui concerne les cartes de prototypage listées plus haut, STMicro recommande de les mettre en oeuvre de la façon suivante : http://www.st.com/en/development…roductId=SC2106
- confier à l'utilitaire ST32CubeMX la génération de code C ANSI (code source) pour l'initialisation qui configure les horloges, pour l'initialisation qui configure les périphériques (UART, SPI, I2C, CAN, I2S, SAI), pour l'initialisation qui configure les interruptions, et pour l'initialisation qui affecte les différentes fonctions aux différentes broches en sortie,
- confier le développement du corps de l'application à un environnement de développement et de test qui recourt à un ou plusieurs langages, et là vous voyez qu'il est aussi question des environnements de développement gratuits tels Arduino, ARM MBED, AC6 OpenSTM32, CooCox.
- confier à l'utilitaire ST-LINK la préparation du code exécutable devant être implanté dans la mémoire Flash de la puce,
- confier à la sonde de débogage ST-LINK/V2, tant le flashage de la puce, que le débogage de l'application.
Pour notre bonheur, l'équivalent d'une sonde de débogage ST-LINK/V2 fait partie de chaque carte de prototypage Nucleo. La partie du circuit imprimé qui lui est dédiée, est détachable de façon à ce que le prototype gagne en compacité une fois que le développement logiciel est terminé. La partie du circuit imprimé qui est dédiée est à la sonde de débogage ST-LINK/V2, comporte un petit microcontrôleur doté d'un port USB qui établit une passerelle entre votre PC (qui sert d'environnement de développement et de débogage) et le port "Cortex-M Debug" de la puce que l'on programme et que l'on teste. Sur une carte STMicro Nucleo, sur la partie du circuit imprimé qui est dédiée à la sonde de débogage ST-LINK/V2, les signaux SWDIO / TMS, SWDCLK / TCK, SWO / TDO, NC / TDI, nRESET sont routés (via straps) vers la puce ARM Cortex-M, et sont routés en direct sur une rangée 1 x 6 = 6 pins au pas de 2,54 mm, rangée nommée "SWD" sur la sérigraphie. Si on coupe le circuit imprimé de la carte de prototypage Nucleo pour en détacher la partie dédiée à la sonde de débogage ST-LINK/V2, cette partie constitue bel et bien un sonde de débogage, grâce à cette rangée de 6 pin. On peut la connecter sur n'importe quelle carte à ARM-Cortex-M qu'on aurait développé, pour autant qu'il s'y trouve une rangée de 1 x 6 = 6 pins au pas de 2,54 mm. Qui soit dit en passant, n'obéit pas au format 2 x 5 pin au pas de 1,27 mm qui est préconisé par ARM en tant que nouveau standard. Ce n'est pas grave, car tous les signaux nécessaires sont présents sur la rangée de 6 pins.
Notez qu'une fois qu'on a amputé une carte de débogage STMicro Nucleo de sa sonde de débogage ST-LINK/V2, il devient difficile de reconnecter sa puce ARM Cortex-M sur une sonde de débogage ST-LINK/V2 externe, car sur le circuit imprimé subsistant, celui qui comporte la puce Cortex-M, ne se trouve aucun connecteur de débogage. Mieux vaut donc ne jamais séparer les sous-ensembles. Les straps dont question plus haut permettent d'isoler la puce ARM Cortex-M, permettant à l'application d'exploiter ces lignes anciennement dédiées au débogage, sans rentrer en conflit avec la sonde de débogage ST-LINK/V2. C'est bien pensé !
Et donc voilà, en fonction de toutes ces informations, si vous architecturez convenablement Node-Blue, il pourra être exploité en tant que composant logiciel universel, qui injecte tant du code C ANSI (petits modules écrits en C), que du code ARM assembleur (petits modules écrits en assembleur), dans n'importe quelle filière de développement logiciel. Du code C ANSI pourra probablement suffire en ce qui concerne la gestion des pointeurs (entrées et sorties audio), et en ce qui concerne le séquencement de l'exécution des différents modules (n'exécuter un module que si il n'a pas déjà été exécuté, et que toutes ses entrées sont définies). Au bout du compte, Node-Blue se borne à livrer à l'environnement de développement de votre choix, du code assembleur et du code C ANSI. Que l'environnement de votre choix compile. Point barre. Ne cherchons pas midi à quatorze heures. En guise de simplification, compte tenu de ce que les puces énumérées plus haut sont abondamment pourvues en mémoire Flash, on peut dupliquer N fois un même module en mémoire Flash, lorsque l'application requiert d'exécuter N modules de tel type. Noter qu'en procédant de la sorte, on tue des opportunités de mises en cache, ce qui est dommage s'agissant des puces ARM Cortex-M7.
Est-ce que pareillement à Synthmaker, un module pourrait être construit et sauvé, regroupant des module existants ?
Il existe un public, qui n'a pas l'envie ou la compétence pour installer un environnement de développement sur son PC, qui trouverait avantageux de faire compiler Node-Blue sur le "cloud" pour les cinq cartes de prototypage répertoriées plus haut. Et si tel service est gratuit, c'est encore mieux. L'utilisation de Node-RED (IBM) au sein de Node-Blue empêche-t-elle une monétisation ?
En ce qui concerne une application audio, je me contenterais de mettre en oeuvre les quelques périphériques suivant :
- I2S ou SAI pour un module miniDSP miniStreamer (audio stéréo de bonne qualité, provenant d'un PC)
- I2S ou SAI pour 2 ADC stéréo (4 canaux donc, notamment pour la mesure du gain et de la phase)
- I2S ou SAI pour un ou deux TDA7801 ou TDA7802 (circuit intégré quadruple ampli de puissance 15 watt Classe AB avec entrée I2S)
- SPI pour configurer ces périphériques
- I2C pour configurer ces périphériques
- réception des ordres d'une télécommande infrarouge (il existe des chips 3 pattes + fenêtre infrarouge, qui opèrent une partie du décodage, non ?)
L'horloge audio (44,1 kHz ou 48 kHz) provient du miniDSP miniStreamer qui est équipé d'un quartz à 256 * Fs, en conséquence de quoi le chip ARM Cortex-M ne voit que l'horloge bit (BCLK), et l'horloge trame (LRCK). On ne peut plus simple. Les circuits ADC et DAC reçoivent en plus, l'horloge 256 * Fs émise par le miniDSP miniStreamer.
En fonction des possibilités des chips ARM Cortex-M, j'implémenterais des préamplis + filtres répartiteurs pour enceintes acoustiques fonctionnant selon Linkwitz-Riley, selon Lipshitz-Vanderkooy (complémentaires, à délai compensé), ou selon des filtrages complémentaires de type FIR, tous au moyen d'une arithmétique (16*16)+64=64 en virgule fixe. J'augmenterais ensuite la précision des calculs au moyen d'une arithmétique (16*24)+64=64 en virgule fixe, capable de filtrer de l'audio codé sur 16 bits à l'aide de coefficients codés sur 24 bits. Je recenserait les puces ARM Cortex-M, rapides assez pour supporter elle évolution. Puis j'essaierais une arithmétique (24*24)+64=64 en virgule fixe, capable de filtrer de l'audio codé sur 24 bit à l'aide de coefficients codés sur 24 bits.
Meilleurs vœux, et bonne continuation !
