salut, ça fait déjà un moment que je suis en train de créer une surface de contrôle avec fader motorisé pour logiciel de son (Cubase, protools, flstudio...) et à l'intérieur j'y ai mis 6 arduino qui contrôle ou relève des valeurs. le problème c'est que j'aurais besoin qu'il puisse comuniquer entre eux (c'est-à-dire envoyer et recevoir des donnés).
j'ai essayé pas mal de truc mais rien à fonctionner comme je le voulais. j'ai essayé software serial mais je n'ai aps reussi à communiquer avec plusieurs aruinos car quand que je mets le second arduino en écoute, je reçoit n'importe quoi.
Avez-vous un idee pour resoudre mon probleme ?
ps désolé pour les fautes d'ortograph je suis fortement dyslexique et sur ce pc je de dispose pas d'un corecteur .
merci
Combien de faders motorisés, de boutons poussoirs, de boutons rotatifs doivent être gérés?
Les affichages, combien d'écrans?
Quelle interface vers ton PC (Cubase etc..), USB, MIDI ?
Quels types de données doivent être communiquées aux différents Arduino?
Quel type d'Arduino?
salut, merci de ta réponse. alors sur mon controlleur il y a :
6 fader motorisé penny + giles avec un fil pour la detection du touché que j'aimerasi utiliser a therme.
6 bouton pour les mutes
2 bouton pour page +/ page -
1 bouton rec
1 bouton play/pause
6 encoders rotatifs pour le pan
6 encoders rotatifs pour les envoi d'aux
3 encoders rotatifs assigniable
1 encodeur rotatif pour les regleges de l'ecran
1 ecran lcd nokia 5110
mon controleur comuniquera via usb a mon pc.
en ce qui est de la communication j'ai :
un arduino "mere" qui recoit tout et dispatch en fonction du type de message (arduino nano)
un arduino qui mesure les 6 faders et leurs 6 moteur (arduino uno)
deux arduino dédié au encodeurs rotatifs (arduino nano)
un arduino qui gere l'écran et son encodeur (arduino nano)
un arduino qui gere les autre encoders et boutons (arduino nano)
je voudrais que les arduino comunique de la sorte, exemple: je pouse un fader, le uno envoi a l'arduino mere le numero de tranche, le numero de bouton de la tranche (ici 4 car le fader est le quatrieme bouton de la tranche) ainsi que ca valeur de 0 a 127. en suite l'arduino mere envoi les valeur au pc en serial, les envoi a l'arduino de l'écran pour afficher quelle tranche on a touché et la valeur a la quelle nou soment. enfin l'envoyer a l'arduino qui a therme controlera l'alumage du rétroéclairage des tranche pour signialer que nou utilison cette tranche.
pour le moment il reste des choses qui ne sont pas connécté (boutons, led de rétroéclairage ....) bref des petit truc
dsl si c'est un peu flou, je fait tout de tete, je vais esayer de faire un plan histoire de poder les choses ;p
si j'ai utiliser des audionos nano c'est en raison de leurs cout tres faible (2 euros) le but de ce projet étant de creer un controleur pour le moins cher possible.
Tu as essayé d'utiliser le bus I2C ?
Je dis peut-être une bêtise mais si tu utilises une liaison USB sur la carte qui communique avec ton PC, tu as sans doute du émuler de nouveaux ports série pour communiquer avec les autres cartes et ça me semble pas une bonne idée de multiplier ces liaisons alors que l'I2C est justement fait pour communiquer avec de nombreux périphériques
Ah, oui.. 1,5€ pour du compatible, c'est vraiment donné.
Donc, va pour les nano à 2€.
Pour la communication, je ne voie que l'I2C, comme le propose Barsa972.
Un maître et cinq esclaves.
Il te faudra créer un protocole pour les échanges.
Seul le maître peut démarrer une transmission, chaque esclave devant répondre au maître.
Presque tout le boulot reposera sur le maître,
L'inconvénient d'une telle architecture, c'est que pour la programmation, il faudra connecter un seul nano à l'IDE.
A moins que l'on puisse lancer six instances de l'IDE sur un port different, mais ça, c'est secondaire.
Ah, oui.. 1,5€ pour du compatible, c'est vraiment donné.
Bonjour,
l s'agit ici d'un atmega168p, qui n'embarque que la moitié des mémoires d'un arduino nano. Mais c'est suffisant pour nombre d'applications, dont celles-ci
Barsa972:
Tu as essayé d'utiliser le bus I2C ?
Je dis peut-être une bêtise mais si tu utilises une liaison USB sur la carte qui communique avec ton PC, tu as sans doute du émuler de nouveaux ports série pour communiquer avec les autres cartes et ça me semble pas une bonne idée de multiplier ces liaisons alors que l'I2C est justement fait pour communiquer avec de nombreux périphériques
le probleme de l'I2C c'est que celui ci ne comunique que dans un seul sens donc (au depart j'avais tout fait en i2C mais je me suis vire rendu compte que cela ne fonctionais pas comme je le voulais)
bilbo83:
Ok, si j'ai bien compris, tu aimerais, réaliser un BCF2000 lite qui te revient moins cher que celui-ci en occasion (de120€ à 200€).
Par contre, des nano à 2€ ? (la nano 3.0 est aux alentours de 23€).
C'est bien ça?
en réalité je n'ai pas acheter les fader, je les ai récupéré dans une PRO6. en ce qui est des arduino je les ai trouvé sur ebay. ce sont des nano 3 a 2 euros. ca fonctionne très bien et c'est très fiable
dsl j'avais pas vu que tout le monde avais déjà répondu en dessous.
je vais essayer de repenser mon architecture en i2c mais c'est compliqué car beaucoup de modules on besoin d'envoyer ou de recevoir ce qui est impossible en i2c. serais il possible de créer mon propre protocole ??
je la piste du arduino Due est pas ci mal. je vais voir ce que je peut en faire.
pour info, pour le moment mon contrôleur ma couté entre 40 et 50 euros
merci a tous. je veux bien un exemple alors car je ne parvient pas trop a voir comment cela peut étre possible mais avec un master listener, cela m'interese fortement ! j'avais deja fait des esays dasn ce sens la en i2c masi cela n'avais pas fonctionner.
merci
Tu as des exemples dans le dossier de la librairie "Wire".
Bon, ils sont simplistes, mais ça te permettra peut-être de bien comprendre les mécanismes de cette interface.
Ce n'est pas ce qu'on fait de plus simple mais un bus I2C peut recevoir plusieurs maîtres.
C'est pas comme chez les humains un seul peut parler a la fois: celui qui parle en premier prend le contrôle du bus et cloue le bec aux autres.
Pour gérer le multi-maître la fonction Wire.endTransmission possède deux formes :
La forme pour un seul maître : Wire.endTransmission();
La forme pour plusieurs maîtres : Wire.endTransmission(true ou false);
A ce que j'ai compris :
Si on envoi "false" le maître garde le contrôle du bus
Si on envoi "true le maître libère le bus qui peut être pris par un autre maître.
Oui, bien sur 68tjs, un maître peu libérer le bus juste après une transmission, mais la gestion devient plus complexe.
Cela vaut le coup d'y réfléchir.
Vaux-t-il mieux un seul chef d'orchestre ou plusieurs?
Pour l'application proposée, je n'en sais rien.
Personnellement pour une application utilisant plusieurs capteurs en I2C sur le même port, j'utilise cette technique de libérer le bus après avoir, par exemple, pour un capteur de température lancé la conversion.
Pendant ce temps (quelques ms), je peut accéder à un autre capteur du même port, mais c'est toujours le même maître.
Oui, bien sur 68tjs, un maître peu libérer le bus juste après une transmission, mais la gestion devient plus complexe.
Cela vaut le coup d'y réfléchir.
Vaux-t-il mieux un seul chef d'orchestre ou plusieurs?
Je réagissais sur le fait qu'on parle toujours d'un seul maître comme si c'était la règle absolue.
C'était juste pour signaler que la norme I2C est beaucoup plus vaste.
Ma contribution s'arrête à donner l'information, je ne porte pas de jugement de valeur si c'est ou non adapté au projet.