DIY - Node Blue

Génial ce tuto

Ça va être assez ouf ton truc, surtout quand ont a pas envi de se prendre le chou avec le codage!

Etienne a écrit :

on peut faire un peu n'importe quoi sans comprendre pourquoi ça marche pas.

On parle de moi ?

super taf

j'ai pas tout compris au fonctionnement mais j'ai saisie l'idée

Hello,

Je me suis essayé au tuto et chez moi ça ne commence pas trés bien!

Lorsque je fais le glissé - déposé du module j'obtiens ceci:

Et si je double clique dessus il ne se passe rien...

En faisant un clic droit sur l'espace de travail j'obtiens alors ceci:

2 modules et en double-cliquant sur ce dernier j'ai enfin le menu déroulant.

Je modifie la valeur, ok, la fenêtre disparait.

Mais rien lorsque je fais Export...

J'ai peut-être déjà loupé quelque chose...!

Bon, ça marche!

En fait, il faut que je lance Node Blue directement depuis le liens que tu as mis plus haut.

Si je lance depuis depuis le fichier téléchargé et installé dans le dossier Arduino , c'est pas bon.

On pourrait " programmer " une carte pour un simulateur ?

A regarder les exemples fournis avec le soft, on va pouvoir faire bien plus que cela!!

Donc, si je veux lancer node blue depuis mon pc (fichier téléchargé) il me faut l'ouvrir avec internet explorer pour qu'il soit opérationnel.

Avec les autres il s'ouvre mais ne fonctionne pas, sauf à recopier le lien directement dans le navigateur et la ça fonctionne avec tous.

J'ai commencé à faire joujou avec une uno et le tuto., ça va être génial ce truc!

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 !

Juste un mot pour décrire la satisfaction que je ressentirais à utiliser Node-Blue :

- atteindre la même précision (audio et coefficients tous deux codés en virgule fixe sur 24 bits) que le Motorola DSP56K qui date de 1988 (30 ans !),

- programmer graphiquement pour atteindre une lisibilité parfaite, et une modularité parfaite,

- créer certains modules en contrôlant tout jusqu'au dernier détail (cas des modules écrits en assembleur ARM Cortex-M),

- créer certains modules en les écrivant dans un langage standardisé indépendant du matériel (C ANSI),

- loger l'abstraction, là où plutôt que de ralentir la vitesse d'exécution, elle l'accélère,

- comprendre (et éventuellement optimiser à la main) le séquencement de l'exécution des différents modules,

- continuer à profiter de librairies, notamment celles très nombreuses, dont on estime que le temps d'exécution n'est pas critique,

- profiter du prix nettement dérisoire des cartes de prototypage STMicro Nucleo,

- profiter du prix nettement dérisoire des puces ARM Cortex-M produites par STMicro, NXP/Freescale, T.I., sans oublier Microchip/Atmel,

- choisir librement l'environnement de développement : Arduino, MBED, AC6 OpenSTM32, CooCox,

- choisir librement un éventuel exécutif, collaboratif ou préemptif, dont on peut régler l'interaction avec le traitement audio,

- écrire et compiler pour d'autres familles de processeurs (proches telles Cortex-A, éloignées telles PIC32 ou ESP32).

Une petite angoisse tout de même. Est-ce que je serai capable de me livrer à toutes les contorsions auxquelles les développeurs doivent se livrer aujourd'hui, pour réussir à écrire une une application, compiler celle-ci et programmer une puce ARM Cortex-M logée sur une carte de prototypage STMicro Nucleo ? Est-ce que je me retrouverai tributaire d'une kyrielle d'utilitaires et de librairies que je devrai m'efforcer de tenir à jour, des utilitaires et des librairies qui prendront des directions pléthoriques que je ne peux pas contrôler, et qui à force, pourraient infecter mon processus de création d'applications ? Les tutoriaux qui concernent Arduino tels http://www.toptechboy.com/arduino-lessons/ ont de quoi inquiéter. C'est comme si on s'ingéniait à rendre compliqué, ce qui est simple. Le tutoriel dit de faire ceci et cela, et encore cela, qui n'ont strictement rien à voir avec le but qu'on s'est fixé. Dans les années 1990, c'était autrement plus simple. On écrivait du code assembleur pour Motorola DSP56K, on le déboguait à l'aide du débogueur édité par Domain Technologies, on s'inspirait d'une des applications-modèle, et quelques heures plus tard, pour autant qu'on sache calculer les coefficients d'un filtre IIR Biquad ou d'un filtre FIR, le travail était terminé.

Je pose la question, car j'ai lu le forum consacré au Teensy Audio Library. Quelle galère !

Tout ça pour une seule et même carte de prototypage a puce NXP/Freescale ARM Cortex-M4.

Tout ça pour une seule et même carte audio.

Comment couvrir les cinq cartes de prototypage STMicro Nucleo ?

Comment couvrir différents modèles de cartes ADC et DAC ?

Il faut traiter ces questions dès premiers instants de la conception de Node-Blue. Est-ce le cas ? Vous voyez comment faire ?

Salut Etienne ,

Lol la remarque sur RacingMat !! Enfin j'espère que tout va bien chez lui !

Bon revenons à nos moutons , à dire vrai redesçendons sur terre parce que les 3 derniers posts .... 8(

J'espère que j'ai été assez clair ?

En plus vos posts ils sont bourrés d'erreurs de calcul (16*16) + 64 = 64 , vous êtes nuls en calcul ça fait 320 !! Mince alors , j'espère que des gamins ne liront pas vos'posts ....

Bon trève de plaisanterie .Dans ton wiki tu as donné des explications pour les volants fanatecs .Tu te souviens à l'epoque sous l'initiative de TortueG qui avait filé le tuyau on etait quelque uns à avoir acheter un volant fanatec en promo pour l'adapter ensuite sur nos direct drive ( avec le fameux QR de Mat avec le collier de velo ) .C'etait un clubsport formula , le plus basique avec juste un affichage 3 digit ( pas de leds) .

Ma question : en utilisant la carte tb01 et le dongle et le sans fil pour l'alim , il est possible alors de garder l'electronique du volant?

D'apres ton wiki oui mais je ne suis pas sur !

c'était le volant formula pour CSR Elite, pas le ClubSport, et il n'était malheureusement pas compatible car la communication entre ce volant et la base CSR Elite n'est pas la même qu'entre les volant formula/BMW/Porsche et la base ClubSport.

il faudrait faire le même travail que Darknao avait fait pour arriver à comprendre comment le formula CSR Elite communique.

Le plus simple je pense c'est de relier les boutons directement à une des cartes proposées par Etienne , ou alors virer l'électronique et mettre de nouveaux boutons et encodeurs

Merci du retour Hachoom

Etienne a écrit :

Ensuite il ne restera plus qu'à attendre que RacingMat sorte de sa léthargie pour bouger ces messages

ah ah ah ! c'est pire que de la léthargie... j'ai pas touché un volant depuis 6 mois au moins.

Quand je vois comme notre génial Etienne phosphore et produit des trucs incroyables !! j'ai l'impression d'être comme ça :

un revenant !!!

Content de te revoir dans le coin, je me faisais du souci :timide: !