Show Posts
Pages: 1 ... 109 110 [111] 112 113 ... 244
1651  International / Français / Re: Requête get et this. sur arduino on: August 22, 2013, 02:58:12 pm
Voir là l'utilisation de this http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr035.htm
ou là:http://www.siteduzero.com/informatique/tutoriels/programmez-avec-le-langage-c/le-pointeur-this

Quote
Est ce que le simple fait de déclaré une variable private dans le header ( nomDeLaClass.h) la rend réellement private ?
oui
1652  International / Français / Re: [Projet viable ou pas ?] Autoradio + Instrumentation on: August 21, 2013, 07:24:18 am
Quote
le seul doute que je vais émettre c'est est-ce que l'Atmega sera suffisamment performant pour gérer l'ensemble car tout ce qui écran tactile+affichage risque de consommer pas mal de ressources
Pour mettre les choses en perspective, une image 320x240 met plusieurs secondes pour être chargée par l'ATmega.
Donc graphique lourd et Arduino cela ne fait pas bon ménage.
Il faut soit:
     passer à un processeur plus performant
     utiliser un écran avec un coprocesseur intégré (comme les écrans 4D Systems par exemple)

Gérer un autoradio existant ça parait assez problématique sauf à avoir les informations sur l'interface de celui-ci.
1653  International / Français / Re: [Mise sur rails] Laser distance + Arduino UNO on: August 21, 2013, 04:31:51 am
On a déjà donné toutes les infos possibles. Tout est dans la notice que tu as donnée en lien au début (copie de la partie intéressante ci-dessous).
La notice dit qu'il faut une alimentation entre 18 et 30V. 24V c'est standard on en trouve partout.
La notice dit que le capteur consomme au maximum 125mA sans charge. Donc en fonctionnement il consommera dans les 150mA. Tu prends 200mA minimum pour avoir de la marge.
La notice dit que l'alimentation se connecte:
               le plus sur la broche 1 du connecteur du capteur
               le moins sur la broche 3 du connecteur du capteur c'est aussi la masse du capteur
La notice dit que le signal de sortie est disponible sur la broche 5. Que c'est une source de courant et que le retour du courant se fait par la broche 3 (la masse)

Je ne vois pas ce qui te manque encore
1654  International / Le bar / Re: Bonne affaire (matrices RGB) Ki k'en veut ? on: August 20, 2013, 03:01:24 pm
Une sûre pour moi.
Je me tâte toujours pour la deuxième.
Pour ce prix là c'est criminel d'hésiter smiley-mr-green
Marchand de tapis. smiley-lol

Je viens juste de recevoir une Due que j'avais commandée il y a quelques temps et je me dis que la Due et ces matrices devraient faire qq chose de sympa. Mais bon, j'ai aussi des impératifs budgétaires.... donc j'hésite.
En même temps cela m’embêterait de devenir un grand criminel...
1655  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.
1656  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
1657  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..
1658  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
1659  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!!
1660  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.
1661  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?
1662  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.
1663  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
1664  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.
?????????
1665  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'
Pages: 1 ... 109 110 [111] 112 113 ... 244