Teensy 3.1, 3.2 - Sonorisation locomotive

[Benoit92]

Le simple fait de faire un copier/coller du programme utilise 236 Ko dans "NotePad".

[Dominique]

Moi je ne trouve que 4k sur mon Mac !!

[Benoit92]

Dans le code que j'ai intégré dans mon message, je n'ai pas mis la totalité des fichiers "son" pour éviter de faire exploser mon post (> 192 ko).
J'ai remplacé une partie des fichiers "son" par des petits points.

[Benoit92]

Bonjour,
Au total, j'ai essayé les configurations suivantes :
1) - Arduino Nano + Carte SD + Bibliothèque "SoftwareSerial.h"- Sortie PWM:
            -> le temps est trop long entre chaque morceau de musique pour mon application. Cette architecture semble plutôt faite pour des lecteurs MP3.

2) - Arduino Nano + Bibliothèque "PCM.h"+ codage son "EncodeAudio"- Sortie PWM:
-> Cette architecture inspirée du le site "Train35" est intéressante en terme de temps de réponse, mais la durée des bruitages doit être très courte (32 Ko Flash Memory sur l'Arduino).

3)  - Teensy 3.2 + codage son "wav2sketch" + bibliothèque "Audio.h" - Sortie Convertisseur Numérique Analogique (DAC A14)
-> Ce contrôleur, compatible de l'arduino (instructions + IDE arduino) est plus rapide que le Nano (72 MHz au lieu de 16 Mhz), mais plus cher (environ 25 €). Il possède 256 Ko de Flash.
Le temps de réponse est bon (peut être liè surtout au performance des bibliothèques plus que la vitesse du processeur et à l'adéquation entre la bibliothèque utilisée et l'application?). La bibliothèque Audio.h est assez lourde. Elle est dédiée (en association avec une carte "son" PJRC SGTL5000") pour des applications complexes de mixage, d'effets sonores et de calcul (Transformée de Fourier).
 La capacité mémoire est à la fois trop importante pour de bruitages de type EncodeAudio" (voir 2), mais pas suffisante pour des sons complexes et de longues durées : Il faudrait à priori entre 500 Ko et 2Mo de Flash (en utilisant le codage "wav2sketch").

4) - Arduino Nano + Carte SD + Bibliothèque "TMRpcm.h"- Sortie PWM:
Cette architecture ressemble à la 1) - mais la bibliothèque utilisée est différente. Le temps de réponse est bon (pas de temps d'attente). Le manque de mémoire est compensé par la carte SD. Je crois que je vais choisir cette configuration.
Il me reste le choix entre 2 possibilités :
        4.1) Carte Arduino Nano (Décodage DCC + moteur + éclairage) + Carte Arduino Nano (Décodage DCC + commande "son") + Carte SD
               -> Problème de synchronisation avec l'arrivée d'une trame dcc valide pour le "son" de la locomotive) -> interruption ??

        4.2) Carte Arduino Nano (Décodage DCC + moteur + éclairage) + Carte Arduino Nano (piloté en liaison série Tx/Dx par le 1er Arduino Nano) + Carte SD.--> reste à essayer
              -> Je pense que la synchronisation entre la commande "son" (provenant du premier Arduino) et la lecture des "sons" sur le deuxième Arduino sera plus facile :  ??

[Jean-Luc]

Moui

Si je me souviens bien il n'y a pas que le son à gérer. Penses tu pouvoir tout caser dans un Nano ?

[Benoit92]

Aujourd'hui, je pars sur l'hypothèse de l'utilisation de 2 Arduino Nano :
Arduino 1
Gestion de la vitesse (pont en H) + l'éclairage (Feux avant/Arrière + cabine) + Pantographe (servo) + Dételage (servo)

Arduino 2
Dédié pour le son, je pense le piloter à partir de l'Arduino Nano 1 par l'intermédiaire de la liaison série Tx/Dx.
L'Arduino 2 recevra les consignes de son (vitesse, accélération, freinage, arrêt, sifflet, . . .).
Une routine ISR dans l'Arduino 2 permettra de vérifier que la consigne de son n'a pas changé.
    - Si pas de changement de consigne, la lecture continue.
    - Si changement de consigne, la lecture en cours s’arrête et la lecture du nouveau fichier commence.
-> Je vais étudier le dossier "interruptions" du forum.

Je pense qu'il vaut mieux découpler la fonction "son" des autres. Les trames DCC arrive de manière asynchrone.
Un certain nombre de trames ne concerne pas la locomotive (Adresse)
Quand je lie un fichier son, l'Arduino ne fait rien d'autre (en particulier, la vitesse n'est pas gérer pendant ce temps). Je risque de rater des trames DCC concernant la locomotive.

[Jean-Luc]

Bon, c'est pas ce que je ferais 

[Benoit92]

1) Tu peux m'expliquer comment tu ferais pour mon application ?

2) Si j'ai bien compris, pour la liaison série, si j'utilise Rx Tx (pin 0 et 1), je ne suis pas obligé de charger la bibliothèque "SoftwareSerial.h".
    Par contre, dans ce cas, je ne peux pas utiliser le moniteur série.

[Jean-Luc]

1) Le Teensy en a assez sous le pied pour faire tourner la totalité de ton application

Certes tu as deux activités, le son et le décodage du DCC, qui sont concurrentes et critiques concernant le temps mais le DCC peut utiliser la fonction input capture d'un des timers pour dater les transitions du signal via le hardware et différer son traitement (tant qu'on ne diffère pas du temps minimum d'un bit). Cette fonction existe aussi sur le TIMER1 de l'AVR d'ailleurs.

2) oui

Ensuite au lieu d'un SD Card, j'explorerais du côté d'une flash SPI, comme ceci : http://www.electrodragon.com/product/spi-flash-breakout-board-winbond-w25q64fvssig-64m-bit/
Ça te permettrait d'utiliser des sons en 22kHz en 12 bits pour une meilleure qualité.

[Benoit92]

1) Ok, je vais essayer de comprendre la fonction "Input Capture". Je ne sais pas si je dois modifier le NmraDcc.h / NmraDcc.cpp : je suis très loin d'être un Mozart de l'Arduino.
Nota : J'utilise et j'ai modifié le Timer 2 pour piloter le moteur (pont en H) à 125 Hz.

2) L'avantage d'une flash SPI par rapport à une carte SD.
Le temps d'accès ?
La mise en œuvre plus facile ?
Pour installer des fichiers dans une Flash SPI, j'installe mes fichiers sons dans des onglets différents (ajouter un fichier . . .), puis je fais des <Include> dans le programme principal (*.ino) ?

[Jean-Luc]

1) Paul a fait une bibliothèque pour gérer ça. https://github.com/PaulStoffregen/FreqMeasureMulti

2) le protocole d’accès est plus efficace que pour une carte SD, moins verbeux. Ça permet un débit qui sur Teensy devrait permettre de lire plusieurs canaux à 22kHz simultanément. Et puis c’est vraiment pas cher. Pour charger des données dans une flash SPI, il faut mettre sur le Teensy un programme qui va recevoir le son à partir d’un tableau comme tu l’as évoqué et l’écrire dans la flash. Paul a également une lib pour gérer un systeme de fichiers sur des flash SPI : https://github.com/PaulStoffregen/SerialFlash

Je pense que dans ton application, lire plusieurs canaux simultanément est intéressant, ça permet de superposer du sifflet au son moteur, etc

[Jean-Luc]

Note qu’un Teensy 3.2 a le SPI qui peut tourner à la moitié de la fréquence, soit 48MHz. La flash SPI monte à 62,5 MHz. Note également  que des utilisateurs overclockent le Teensy 3.2 a 120Mhz

[Benoit92]

Je vais suivre tes conseils :
1) Je crois que pour overclocker à des fréquences supérieures à 72 MHz, il faut que le Teensy soit alimenté en 5 V et non en 3,3 V.

2) Pour la Flash SPI j'ai vu sur Aliexpress :
https://fr.aliexpress.com/item/Free-Shipping-5pcs-W25Q64B-large-capacity-FLASH-memory-module-SPI-Interface-Electronic-Component/1000001623457.html?spm=a2g0s.9042311.0.0.8NPUAB
Je mettrai un 7803 pour l'alimentation.

3) Je vais essayer de tout mettre sur un Teensy 3.2
En espérant que les consommateurs (pont en H, Led + servo) ne vont pas faire écrouler le Teensy.
C'est pour cela que je vais laisser 5 V pour une sortance globale de 250 mA ( Il parait qu'en mettant 10 v, on peut avoir une sortance globale de 500 mA !!!) -> mais,  je ne suis pas partant pour faire des signaux de fumée !!!

4) Je vais récupérer mon programme sur Arduino Nano qui fonctionne (hors génération du son).
Il faut que je commence par supprimer les modifications du Timer2 qui me permettait de piloter le pont en H à 125 Hz et remplacer ce code par :

Code: [Sélectionner]

void setup() {
      analogWriteFrequency(3, 125); // Teensy 3.0 pin 3 also changes to 125 kHz
    }Comme d'habitude, chaque timer affecte systématiquement plusieurs pins en même temps.
"The PWM signals are created by hardware timers. PWM pins common to each timer always have the same frequency, so if you change one pin's PWM frequency, all other pins for the same timer change".
Teensy 3.1 & 3.2
Timer   PWM Pins                         Default Frequency
FTM0   5, 6, 9, 10, 20, 21, 22, 23         488.28 Hz
FTM1   3, 4                                           488.28 Hz
FTM2   25, 32                                       488.28 Hz

[Jean-Luc]

J’ai pas compris l’histoire de la tension et de la sortance.

Le MCU du Teensy ne s’alimente pas au delà de 3,3V, overclocké ou non, sinon il grille.

En revanche la flash fonctionne en 3,3V et peut être alimenté par le 3,3V du régulateur du Teensy. Ce régulateur, d’après la datasheet peut fournir 500mA mais c’est une valeur extrême. Limiter à la moitié est raisonnable. Ce régulateur est alimenté via VIN à partir de l’alimentation dérivée du DCC.

Un servo sur l’entrée de commande ne consomme rien. Sur son alimentation ça dépend de sa taille mais la c’est l’alimentation dérivée du DCC qui est sollicitée. Le pont en H L298 consomme sur ses entrées de commande un courant inférieur à 100μA.

Il faudrait faire un schéma pour tout de manière à savoir de quoi on parle 

Ps : le module est deux fois moins cher chez electrodragon. Sur le module Ali express, la flash semble avoir été soudée à la main vu la régularité des soudures. Soudé à la main = récup. Certe le port est payant chez electrodragon. Perso je prends Bpost, l’envoi est suivi, quand je commande des carte et je suis livrée en moins de 10 jours. Il y a moins cher mais plus long.

[Benoit92]

Ok, Merci.
Plus précisément :
 - Tensy 2.0 : 5V
 - Teensy 3.1, 3.2, 3.5 --> 3,3 V - 5V Tolerant
 - Teensy LC et 3.6 --> 3,3 V