Show Posts
Pages: 1 ... 103 104 [105] 106 107 ... 238
1561  International / Le bar / Re: Bonne affaire (matrices RGB) Ki k'en veut ? on: August 20, 2013, 09:10:49 am
Une sûre pour moi.
Je me tâte toujours pour la deuxième.
1562  International / Français / Re: Nouveau materiel ! on: August 20, 2013, 02:44:44 am
Salut , je compte faire une mini voiture téléguidé via Xbee et ma commande vien d'arriver , voici les explications  :
Partie emettrice : Arduino Uno ou Leonardo + Xbee Shield + Xbee + Manette PS2
Partie receptrice : MBoard  + Xbee + 2 Moteur

Ce que je comprend pas :
1. La MBoard est sorte d'arduino ( http://www.exp-tech.de/Mainboards/Arduino/MBoard-Arduino-with-L298P-motor-driver.html ) , donc elle a les meme pin sauf que dans cella je trouve pas les pin 1 , 2 ,3 ... En plus , dans le code je sais pas quoi metre comme pin pour les sortie moteur (OUT1,2,3 et 4)

2. Quel port serie doit je utiliser dans le code , serial ou serial1 ?

3. J'ai également achété "Foca V2.2 FT232RL Tiny Breakout USB to Serial UART Interface" (http://www.exp-tech.de/Shields/Foca-V2-1-FT232RL-Tiny-Breakout-USB-to-Serial-UART-Interface.html ) , un programmeur d'Xbee via X-CTU , le probléme la c'est que je ne sais pas que voltage mettre car il y'a le 3V et le 5V , et si l'Xbee s'alimente en 3V et que je mais accidentellement 5V elle s'endomagera ?
Moi ce que je ne comprends pas c'est que l'on puisse acheter une carte sans avoir regardé au préalable comment elle fonctionne et s'être assuré qu'elle pourra faire ce que l'on veut avec !
Mais bon...

Pour répondre à tes questions c'est facile regarde dans la bas de la page que tu as mise en lien. Il y a le schéma de la carte et surtout sa datasheet dans laquelle tu trouvera le brochage des connecteurs et l'équivalence du nom des broches entre le monde Arduino et le monde MBoard.

Si l'XBee fonctionne en 3V le mieux c'est peut être de lui donner du 3V tu ne crois pas ?
Et oui si tu mets du 5V tu vas certainement endommager ta carte XBee
1563  International / Français / Re: [Conseil] Pilotage d'un réseau de trains miniatures on: August 20, 2013, 02:27:38 am
Bonsoir,

Merci à fdufnews pour cette réponse. Elle me plaît bien, je souhaitais et j'espérais un peu une réponse dans ce sens, mettre un carte Arduino par bloc est intéressante et souple et cela ne me pose pas de problèmes.
Quote from: fdufnews
Les blocs sont ainsi indépendants les uns des autres. Le code peut être commun par contre.
Est-ce que cela veut dire qu'il doit y avoir obligatoirement un carte maître pour que le code soit commun ou le même code est chargé dans chaque carte?

Pour que le code soit commun il faut que tout les blocs aient le même comportement. Ou du moins que la logique de gestion des blocs soit la même pour tout les blocs.
Après s'il y a des exceptions on peut toujours imaginer des paramètres en EEPROM qui activent/désactivent des options du logiciel.
L’intérêt d'avoir un logiciel commun c'est de ne faire qu'un développement et qu'une mise au point.

Mon idée étant plutôt ce que tu expliques ici :
Quote
Sans maitre
   - un bus RS485 multi-maitres les cartes parlant à tour de rôle avec leurs voisines et s'autogérant.  Le système n'ayant pas de maitre est normalement plus fiable mais le problème des carambolages sur le bus peut être pénalisant avec de nombreux acteurs sur le bus.
   - le RX d'une carte sur le TX de sa voisine et ainsi de suite pour faire une espèce de daisy-chain. Sans doute pas très efficace.
Ces problèmes de carambolages peuvent ou vont-ils se produire systématiquement et perturber le fonctionnement ?

Lorsque plusieurs intervenant sont susceptibles de parler sur un même bus il peut y avoir des carambolages. Il faut utiliser/développer un protocole de communication qui soit insensible aux carambolages et qui garantisse l'intégrité des échanges.
Le protocole de communication peut être très simple.
Chaque carte est identifiée par un numéro. La carte avec le numéro le plus bas commence à questionner ses voisines. Lorsqu'elle a fini elle passe la main au numéro suivant et ainsi de suite jusqu'à la dernière.
Ou bien la carte avec le numéro le plus bas commence a publier sont état sur le bus (celle qui sont intéressées le capture au passage). Lorsqu'elle a fini la suivante prend le relais et ainsi de suite jusqu'à la dernière.
Il faut bien sur prévoir des sécurités, si une carte ne parle pas dans un temps imparti, on la déclare en panne et la suivante prend son tour.
Ou alors il faut un maître qui synchronise tout le monde.

En imaginant que je choisisse cette configuration avec des cartes MINI, il faudrait acheter également un module de conversion avec port USB pour charger le programme car il me semble que les mini ne possède pas de port USB ou il y a une autre manière de faire (sans se compliquer) ?
Les cartes NANO sont plus chères mais possèdent un port USB, qu'en penses-tu ?
Pour programmer les cartes Mini il faut effectivement un câble de téléchargement qui doit coûter une quinzaine d'euros.
A toi de faire tes comptes.
Autres avantages de la nano:
  - 2 I/O supplémentaires
  - toutes les broches sont au pas de 2,54mm alors que sur la Mini il y a des broches qui sont décalées.

Je me pose une autre question, tu dis :
Quote
le RX d'une carte sur le TX de sa voisine et ainsi de suite pour faire une espèce de daisy-chain. Sans doute pas très efficace.
Dans mon cas, une carte X a besoin d'informations provenant de son propre bloc (entrées) et des sorties d'une carte Y (autres entrées de la carte X) pour savoir ce que le bloc doit faire ou comment la carte X doit se comporter pour mettre ses sorties dans le bon état (1 ou 0). Pourquoi aurai-t-on besoin des signaux RX et TX ? Doivent-elles obligatoirement être connectées ainsi pour accepter des entrées provenant de sorties d'une autre carte (j'espère avoir été suffisamment clair) ?
C'était juste un exemple d'architecture de communication. Mais comme je l'ai dit elle n'est pas très efficace.
Il vaut mieux privilégier les architectures qui permettent à une carte d'interroger ces voisines ou alors une architecture centralisée avec une carte maître qui interroge tout le monde et qui ensuite distribue un état du système à toutes les cartes.
Ma préférence allant plutôt vers un système distribué (c'est à dire sans maître) car c'est généralement plus robuste aux pannes matérielles. Si une carte tombe en panne le reste du système peut rester fonctionnel pour autant que cela ait été pris en compte à la conception..
1564  International / Français / Re: Recherche un Wiki pour y mettre mes tutoriels en français. on: August 20, 2013, 01:40:29 am

P.-S. : Est-ce que « http://arduino.cc/fr », pourrait ajouter une section Wiki francophone à son site ?
Une section existe déjà sur le playground : http://playground.arduino.cc/French/HomePage
1565  International / Le bar / Re: Bonne affaire (matrices RGB) Ki k'en veut ? on: August 19, 2013, 02:08:21 pm
Ps pour san41 : tu peut donner le prix des frais de port "classique" st'plé smiley
Et faudrait aussi décider d'une date butoir ...

cependant concernant le financement, tu as prévu quoi ? On pourra payer par chèque ? (banque française évidemment  smiley-razz)
Faut voir avec san41, c'est lui qui gére ça smiley-wink

Donc il ne manque plus que les infos de san41 pour donner le coup d'envoi!!
1566  International / Français / Re: [Mise sur rails] Laser distance + Arduino UNO on: August 19, 2013, 11:27:28 am
La boucle 4-20mA se fait entre la sortie signal et la masse.
Donc la résistance doit être placée entre signal et masse.
La broche de masse du capteur doit être réunie à la masse de l'arduino.
La broche signal du capteur doit être réunie à une entrée analogique de l'arduino.
La résistance doit être au plus près de l'arduino.
1567  International / Français / Re: [Conseil] Pilotage d'un réseau de trains miniatures on: August 19, 2013, 11:09:32 am
Quote
Il faudrait que l'application soit souple et évolutive pour ajouter des blocs par la suite si nécessaire
Je serais tenté de proposer une arduino mini par bloc. Une arduino c'est 13 entrées sorties logiques + 6 entrées analogiques qui peuvent aussi être utilisées en entrées/sorties logiques soit au maximum 19 entrées/sorties logiques auxquelles ils faut retirer quelques broches pour la communication (voir plus loin). Cela couvre ton besoin de 10 entrées et 5 sorties pour un bloc. Ces cartes ne sont pas particulièrement chères une dizaine d'euros sur le net surtout si tu en prends plusieurs. Les blocs sont ainsi indépendants les uns des autres. Le code peut être commun par contre.

Après pour les faire parler ensemble, il y a du choix:
Avec un maitre:
   - un bus RS485 avec un maitre qui interroge les cartes esclaves. Sans doute le plus simple d'un point de vue hard et soft.
   - un bus SPI avec un maitre qui interroge les cartes esclaves. Le problème du SPI c'est le chip select vers les prériphériques.
Sans maitre
   - un bus RS485 multi-maitres les cartes parlant à tour de rôle avec leurs voisines et s'autogérant.  Le système n'ayant pas de maitre est normalement plus fiable mais le problème des carambolages sur le bus peut être pénalisant avec de nombreux acteurs sur le bus.
   - le RX d'une carte sur le TX de sa voisine et ainsi de suite pour faire une espèce de daisy-chain. Sans doute pas très efficace.

Quote
D'autre part, est-ce compliqué à réaliser si plusieurs cartes Arduino devaient être reliées entre elles ?
Si l'architecture que tu retiens colle bien à ton besoin tu ne devrais normalement pas avoir de grosses difficultés.
Par contre cela nécessite un bon travail en amont pour identifier les besoins aussi matériels que logiciels:
  - quelles sont les informations à échanger entre qui et qui.
  - faut-il centraliser le traitement ou peut-il être morcelé et déporté localement (architecture sans maitre)
  - quel niveau d'évolutivité veux-tu?
1568  International / Français / Re: Conversion ASCII on: August 19, 2013, 04:10:49 am
Dans le cadre d'un projet, j'ai besoin de lire des valeurs sur une carte SD. Le problème c'est que, avec la fonction file.read() les données sont récupérés en ASCII Dec (Un "1" dans mon fichier texte va devenir un "49"...).
En utilisant la fonction Serial.write j'ai bien le "1" qui s'affiche.
Pour compléter les propos de skywodd:
Les méthodes .read() et .write ne modifient pas les valeurs qu'elles manipulent, elle ne rajoutent pas non plus de caractères de séparation. C'est d'ailleurs leur raison d'être, manipuler des octets sans se préoccuper de ce qu'ils représentent. Ainsi:
  - Si write "écrit"  1 (la valeur numérique) alors read "lira" 1(la valeur numérique). Pour rappel, 0b00000001 ou 0x01 ou 1 c'est pareil.
  - Si write "écrit"  '1' (le caractère codé ASCII) alors read "lira" '1'(le caractère codé ASCII). Pour rappel, 0b00111001 ou 0x31 ou 49 ou '1' c'est pareil.

Il faut faire très attention au type des données que l'on manipulent. Si file.read() lit "1" alors c'est que tu avais écrit "1" dans ton fichier et non pas 1.
Maintenant, il y a des fonctions qui permettent de passer d'un type à l'autre. Ainsi atoi() permet de convertir une chaine de caractères en entier.
Code:
int toto = atoi("123");
ce code convertira la chaîne "123" et placera dans toto la valeur 123.
1569  International / Français / Re: Existe t il un moyen de simuler un écran oled/LCD? on: August 16, 2013, 01:41:48 pm
High tech: paint, Photoshop, the Gimp
Low tech: papier et crayon

la dernière solution et rapide à mettre en oeuvre et les coût de développement proche de zéro
1570  International / Français / Re: uno vs nano on: August 16, 2013, 08:51:47 am
Celles qui n'ont pas l'USB c'est des arduino mini ou arduino pro mini. L'avantage c'est que comme elles n'ont pas le circuit d'interface USB, elles consomment moins.
En contre partie pour les programmer, il faut un câble de programmation (type câble FTDI 232 http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm) On en trouve un peu partout pour pas très cher. L'autre solution c'est d'utiliser une carte arduino comme programmateur.
Les arduino mini existent en 2 versions:
   - une version 5V, 16MHz
   - une version 3V, 8MHz. Pratique pour faire des engins portables qui fonctionnent sur batterie ou piles. Au détriment des performances évidemment puisqu'elle tourne 2 fois moins vite.

L'arduino namo, ce n'est ni plus ni moins qu'une arduino classique mais de plus petite taille

Pour la nano comme pour la mini, les sorties se font sur des barrettes de picots sur les cotés. A noter que sur la mini les entrées analogiques A4 et A5 sont souvent (mais pas systématiquement) non pas sur le bord mais  l'intérieur de la carte et les points ne sont pas alignés sur la grille au pas de 2,54mm ce qui fait qu'on ne peut pas les raccorder directement sur une plaque d'essai par exemple. On voit d'ailleurs très bien ces broches décalées sur la photo que tu as mise en pièce jointe dans ton post.

Quote
Les compatibilités HS, S9, TR, tout ca c'est du chinois.
?????????
1571  International / Français / Re: envoyer variable float sur xbee on: August 15, 2013, 04:08:12 pm
Quote
Savez-vous sous quelle forme on reçois les données sur le port série une fois passé l'OS? Char? Hex? bits ?
On les reçoit comme on les a envoyées. Le support utilisé pour le transfert est transparent pour l'utilisateur et il ne modifie pas les données. Si tu envoies des char tu reçois des char.
De toutes les façons char hex et bits c'est la même chose.
C'est juste la manière de les afficher qui les présente différemment.
65d= 0x41 = 0b01000001 = 'A'
1572  International / Français / Re: envoyer variable float sur xbee on: August 15, 2013, 11:42:52 am
Quote
J'ai essayé avec un union ( http://streylab.com/blog/2012/10/14/sending-humidity-and-temperature-data-with-zigbee.html ) mais il semble mal convertir les données. Par exemple quand j'envoie 19.4 il me le convertie en  33 33 B3 41 se qui correspond pas du tous à la data de départ d'après la table ASCII.
La valeur qui te semble bizarre c'est ton float qui est codé. La valeur d'un flottant n’apparaît pas en clair lorsqu'on regarde les octets qui le composent.

Quote
Bon, je suis arrivé à mes fin mais avec un code sale ... si vous avez mieux à proposer je suis ouvert :
L'union fonctionne dans les 2 sens.
A l'émission, tu mets un float dans l'union et tu ressors 4 uint8_t que tu émets.
A la réception, tu entres 4 uint8_t dans l'union et tu ressors un float.

En théorie c'est bon. En pratique si les 2 équipements ne codent pas les float de la même manière cela pourrait ne pas fonctionner.
1573  International / Français / Re: Compréhension code on: August 15, 2013, 11:35:26 am
On dirait bien une erreur et elle se répète 2 fois
Code:
void PCF8574::pullUp(int pin){
if((pin >= 0) && (pin < 8)){
PCFPULL[pin] == 1;
i2cRead();
bitWrite(PCFPORTA,pin,1);
i2cSend(PCFPORTA);
}
}

void PCF8574::pullDown(int pin){
if((pin >= 0) && (pin < 8)){
PCFPULL[pin] == 2;
i2cRead();
bitWrite(PCFPORTA,pin,0);
i2cSend(PCFPORTA);
}
}

D'ailleurs plus loin ce tableau est utilisé dans un test (pour de vrai cette fois)
Code:
void PCF8574::i2cSend(){
PCFBUFFER = i2cRead(0x00);
for(int i=0;i<8;i++){
if(bitRead(PCFTRISA,i) == INPUT)
bitWrite(PCFPORTA,i,bitRead(PCFBUFFER,i));
if(PCFPULL[i] == 1) bitWrite(PCFPORTA,i,1); // Required for unblock pull level
if(PCFPULL[i] == 2) bitWrite(PCFPORTA,i,0); // Required for unblock pull level
}
Wire.beginTransmission(PCFaddress);
Wire.write(PCFPORTA);
Wire.endTransmission();
}


Quand on voit cette dernière fonction on s'aperçoit que le tableau sert à mémoriser l'état des pullup en sortie. Donc il faut bien renseigner le tableau lorsque leur état change.
A mon sens les 2 premières fonctions devraient être écrite comme ça:
Code:
void PCF8574::pullUp(int pin){
if((pin >= 0) && (pin < 8)){
PCFPULL[pin] = 1;
i2cRead();
bitWrite(PCFPORTA,pin,1);
i2cSend(PCFPORTA);
}
}

void PCF8574::pullDown(int pin){
if((pin >= 0) && (pin < 8)){
PCFPULL[pin] = 2;
i2cRead();
bitWrite(PCFPORTA,pin,0);
i2cSend(PCFPORTA);
}
}

1574  International / Français / Re: Compréhension code on: August 15, 2013, 10:01:17 am
En l'état cette ligne ne fait rien.
Il faudrait quand même savoir ce qu'est ce PCFPULL pour mieux comprendre
1575  Using Arduino / Project Guidance / Re: Strange behavior on: August 14, 2013, 01:41:02 pm

Produces a correct diode connection, jumps into capactance measurement, C=, then jumps to Menu and into PWM 100 Hz and cycles until 0% is displayed.  Double-press does not return to Menu.
Edit: After a minute or so, double-press will return to Menu!


I have no small signal diode but made the test with the emitter-base jonction of a transistor
I have not that behavior with a duemilanove. But sometime the capacitance measurement returns a very high value 76µF for example. But as my assembly is made on a testboard and the contacts are not very reliable I can't make any assumption concerning the software. I really must do a good board for a usable tool.
Pages: 1 ... 103 104 [105] 106 107 ... 238