Show Posts
Pages: 1 ... 42 43 [44] 45 46 ... 88
646  International / Français / Re: ordi de bord on: August 09, 2013, 03:31:38 pm
la fatigue prenant le dessus, je te dirais juste que quand tu fais "if (eauPin > vent1_on)", le compilateur traduit en "if (A0 > 92)", ce qui sera toujours faux (A0 = qqchose comme 14 je crois).

il faut donc faire "if (analogRead(eauPin) > vent1_on)" pour déclencher une conversion de eauPin.

ensuite, ";void setup()" ne doit pas trop marcher (le point-virgule)

"vent1Pin = digitalRead(eauPin);" ne peut pas marcher, vent1Pin est un alias, une constante, tu ne peut pas lui assigner une valeur. par contre, digitalWrite(vent1Pin, digitalRead(eauPin)); devrait te rendre un petit service.

Je ne vais pas plus loin, j'aurais plus vite fait de réécrire ton code que de le corriger en t'expliquant.

relis tout et bon courage,

Cinci
647  International / Français / Re: échange ecran lcd on: August 09, 2013, 03:20:31 pm
Je récupère tout ce qui possède un LCD, mais à chaque fois, je tombe sur des écrans à la con, genre celui-là : http://forum.arduino.cc/index.php?topic=124824.0. mais si tu comptes ne rien en faire, il trouvera une petite place dans le tiroir des trésors.

Désolé, en échange, je n'ai pas de diode blourai...
648  International / Français / Re: ordi de bord on: August 09, 2013, 02:08:32 am
Salut,

Pour revenir à la lecture des infos analogiques, je me suis posé pas mal de questions. J'ai constaté que déjà, la référence du CAN, c'est VCC, et que le petit régulateur de l'arduino est vraiment crade, et VCC bouge beaucoup. Donc pour commencer, il faut lui donner une vraie référence bien stable. Il faut peut-être intervenir au niveau du core arduino également, car dans wiring_analog.c, on peut lire :

Code:
uint8_t analog_reference = DEFAULT;

void analogReference(uint8_t mode)
{
// can't actually set the register here because the default setting
// will connect AVCC and the AREF pin, which would cause a short if
// there's something connected to AREF.
analog_reference = mode;
}

L'idée d'un court-circuit n'est pas très engageante...

Pour les capteurs en eux-même, si on peut les déconnecter du circuit 12V, j'utilise un petit générateur de courant à base d'un PNP (genre 2N2905 ou 2N2907). Si on fait passer un courant constant dans une résistance, on obtient alors une tension constante, complètement indépendante de l'alimentation, c'est déjà un grand pas en avant! de plus, la tension obtenue est directement proportionnelle à la valeur de la résistance (mesure linéaire).
Par exemple, si on fait passer 1mA dans une résistance, alors la tension mesurée en mV sera égale à la résistance (utile pour faire des mesures, non?).

Autre exemple, on veut mesurer un capteur qui donne une résistance de 1000 à 3500 ohms, on en déduit que pour un courant de (5/3500) = 1,43mA, on peut alors mesurer une tension de 5V pour 3500ohms et 1,43V pour 1000ohms. La conversion donnera alors une valeur entre 293 pour 1000ohms et 1023 pour 3500ohms, sous une tension de référence AREF de 5V.

hi hi hi...
649  International / Français / Re: [Projet] Un tableau de bord numérisé on: August 09, 2013, 01:50:02 am
Salut la communauté,

Je reviens d'une semaine de vacances où je n'avais rien à faire de mes soirées une fois ma fille couchée. J'ai donc ressorti mon vieux projet (et oui, toujours d'actualité).

Après quelques changements de véhicule, il était temps de s'y remettre et de revoir certaines choses.

Comme je l'avais précisé, la nouvelle receveuse du gadget me simplifie grandement la tâche grâce à son calculateur d'injection qui me fournit en temps réel une trame de 37 octets sur l'état du moteur (température, rotation, capteurs, durée d'injection, avance allumage, défauts...). Il ne me reste donc plus grand chose à traiter : gestion de l'accélérateur (je remplace le câble par un potar et un servomoteur), vitesse en km/h, conso, quelques capteurs. Je me suis donc rabattu sur un MEGA2560.

Presque toutes les mesures seront traitées par interruptions, ce qui veut dire que loop() sera vide (enfin presque). Voici la liste des INTs que j'ai déjà prévues :

ISR (PCINT0_vect) : gestion d'un clavier matriciel 4x5, les touches sont bufferisées dans un FIFO.
ISR (USART3_RX_vect) : réception de la trame de données série du calculateur d'injection, les données remplissent un tableau de 37 bytes.
ISR (TIMER4_OVF_vect) et ISR (TIMER4_ICP_vect) : calcul de la vitesse en km/h et incrément des compteurs kilométriques
ISR (TIMER5_ICP_vect) : calcul de la consommation (xx,x l/100)
ISR (ADC_vect) : numérisation automatique de 8 entrées analogiques renseignant un tableau de 8 word
ISR (WDT_vect) : timer de déclenchement à intervalles réguliers (256ms) pour le régulateur de vitesse

Bref, l'idée est que toutes les variables de données se mettent à jour automatiquement, il suffit alors de les lire quand on en a besoin, c'est tout... De même, j'aurai 3 sorties servomoteur gérées directement par les sorties hard PWM du timer1, genre un simple OCR1A = valeur; suffit à changer la position du servomoteur. Pour les deux écrans du TDB, j'utilise USART 1 et 2 pour leur envoyer les données à afficher.

Tout ça est bien gentil, mais j'ai eu la chance d'ouvrir le wiring.c et d'y découvrir toute une initialisation barbare des timers, ainsi que de l'ADC. j'ai donc viré tout ça, histoire que le core arduino ne me configure pas les ressources de traviol pour rien (de même pour les fonctions delay(), micros()..., je les ai virées). Je configure le tout directement par les registres, en lisant le datasheet de l'AVR. J'ai aussi viré la gestion de l'USART3 pour pouvoir récupérer l'INT correspondante. J'ai aussi vu quelque part (dans le main.c je crois) qu'entre deux exécutions de loop(), il y avait un "doSerialEvents();", ce qui ne me plait pas trop, il faut que je vois ce que c'est et le virer également au besoin.
Ne serait-ce que pour la conversion analogique numérique, analogRead() prend un temps fou, car elle lance une numérisation et attend les 104µs de la conversion pour obtenir le résultat. Il faut savoir que 104µs représentent 1664 instructions (oh le beau nombre!), et que tout ça, c'est perdu dans un while(...){rien;}. sur 8 conversions à la suite, ça nous fait à peu près 13 500 instructions de perdues. Il faut quand même savoir que le CAN est indépendant, et qu'il fait les conversions tout seul dans son coin sans utiliser le CPU. J'utilise donc l'INT du CAN, déclenchée une fois la conversion terminée, et qui relance elle-même une nouvelle conversion puis rend la main au programme. Ca prend à peine 30 instructions contre les 1700 du core arduino. On apprend beaucoup en déchiffrant les datasheets...

Je pense gérer moi-même la gestion des ports série par la suite, car décidément, l'équipe arduino ne s'est pas trop occupée des temps de traitement...

Restera à voir si les interruptions ne se bouffent pas trop les unes-les-autres, que ça me laisse un peu de temps processeur pour le traitement...

A suivre!
650  International / Français / Re: Arduino et les freezes on: May 31, 2013, 11:04:59 am
Salut,

Il y a des tas de raisons pour avoir du freeze, et souvent, comme tu le dis, perturbations extérieures, ou boucles infinies (un while dont la condition ne se vérifie jamais par exemple).

Je ne vois pas d'autres solutions que de relire entièrement ton soft (surtout si tu as pompé des trucs tout faits sur le net).

Pour ton relais, ce n'est pas l'alternatif qui te gêne, mais la bobine elle-même du relais qui doit te renvoyer des saloperies sur l'alim (c'est un gros relais?) à chaque commutation.

tu n'as pas le choix que de bien te prendre la tête, alors bon courage!
651  International / Français / Re: Minitel et Arduino : c'est reparti pour un non-fonctionnement on: April 07, 2013, 02:17:21 am
à la fin de presentation() :

Code:
while(Serial1.available() <= 0) {   
  }
  Serial1.print(hautGaucheEfface);
  inByte = Serial1.read();

je ne suis pas sûr que ton test soit bon dans le while, j'ai l'habitude d'écrire while(!Serial1.available()){}.

Reste aussi que le minitel peut envoyer des choses, donc avant de faire ton while, fais un flush du tampon série.

Mais si tu as aussi un bug dans ta liaison USB... ?
652  International / Français / Re: 1er schema : on se moque pas on: February 09, 2013, 03:34:00 pm
étonnant, l'image est pourtant bien là et très parlante pour ton schéma. En fait, tu as fait trois circuits qui n'ont de commun que la masse, et même au niveau capteur, pourquoi utiliser un thyristor? j'imagine que c'est pour biper tant qu'on n'appuie pas sur le bouton?
653  International / Français / Re: TIMER1 on: February 09, 2013, 02:25:57 pm
Salut,

du fait que les timers ont trois comparateurs sur le mega, et deux seulement sur le uno, le mega a des registres en plus, et les bits ne sont pas au même endroit. mais le datasheet de atmel est vraiment très bien fait je trouve, et si tu connais déjà la bidouille de registres, alors tu t'en sortiras très bien!

Les arduinos sont assez polyvalents, donc l'utilisation des registres est longuement documentée (et c'est très bien)!
654  International / Français / Re: 1er schema : on se moque pas on: February 09, 2013, 07:49:52 am
aïe...

l'électronique de détection, c'est une spécialisation d'un métier, ne s'y frotte pas qui veut!

Je ne vois pas l’intérêt d'utiliser un montage où l'ampli-op est alimenté par le capteur, sauf si on maîtrise parfaitement la chose, ce qui je crois n'est pas le cas.

dans le montage de Fred, la sortie étant reliée à la masse, ça donnera toujours un zéro.

Pour faire un schéma, il faut toujours que les courants descendent (ce qui implique de savoir dans quel sens ils circulent, donc d'avoir un minimum de notions) du haut vers le bas.

C'est en faisant qu'on devient faiseur... je vais te refaire ton schéma dans une logique d'électronicien, on y verra tous un peu plus clair...



voilà, c'est TON schéma. mais qu'attends tu réellement de ton capteur?
655  International / Français / Re: Composant pouvant foudroyer un rat on: January 22, 2013, 04:21:32 pm
je peux te prêter mon chat, elle m'en a avalé 3 comme ça sous mon bureau en une semaine



(la "minette" fait 8Kg, pour donner un ordre d'idée de la taille du rat)
656  International / Français / Re: Composant pouvant foudroyer un rat on: January 22, 2013, 03:46:11 pm
Alors ça, le rat va comprendre vite, il évitera tout ce qui ressemble à une gamelle en inox (sauf s'il est fan de space mountain), mais qu'est-ce que je me suis marré! (il fat savoir qu'en Amérique, les écureuils sont aussi nuisibles et nombreux que les rats).

c'est depuis ce genre d'invention que se sont développés les écureuils volants  smiley-lol
657  International / Français / Re: Composant pouvant foudroyer un rat on: January 22, 2013, 05:11:04 am
l'idée du ratator est pas mal! si ça ne le tue pas, ça l'envoie au moins chez le voisin. et un ratator à tir automatique, c'est pas bien compliqué à faire.
658  International / Français / Re: Composant pouvant foudroyer un rat on: January 21, 2013, 03:47:50 pm
Quote
ca fait la 5eme que je balance par la fenêtre avec mes filles
eh tu ne balances pas tes filles par la fenêtre quand même !
Va savoir, à défaut de pécho des rats...

Retour aux électrons... Si le grillage à mouche marche très bien, pourquoi pas avec un rat? simplement parce qu'une mouche, c'est tout sec, et ce n'est pas le courant qui la tue, mais l'étincelle qu'elle provoque. L'étincelle est assez grande pour la griller, et comme elle est sèche, ben l'intérieur se réduit en poudre illico. Pour le rat, il est très mouillé à l'intérieur (comme nous, 80% d'eau autour de 20% de carbone). L'eau est conductrice mais permet d'évacuer (du moins répartir) la chaleur, donc un simple tac ne fera pas grand chose. L'électrocution demande un certain temps pour paralyser le coeur et l'arrêter... peutêtre qu'un courant alternatif serait plus efficace, mais j'en doute, je crois que les muscles se contractent quelle que soit la polarité du courant.

J'ai vu une solution pas mal sur le net, un sceau avec un rouleau : lerat monte sur le rouleau et tombe au fond du sceau. Bon, c'est purement mécanique, il faut rajouter des trucs pour automatiser, mais le coup de la détection de la bestiole, je ne suis pas sûr que ça marche vraiment... il faut des actionneurs très rapides derrière.
659  International / Français / Re: Composant pouvant foudroyer un rat on: January 21, 2013, 11:40:02 am
Ce qui va te permettre de tuer un rat, c'est une quantité d'énergie. la bobine d'allumage fournit de la haute tension, certes, mais peu d'énergie. De plus, elle t'obligera à déclencher au bon moment.

Je partirais sur un truc plus simple. générer un signal carré avec un simple astable et un transistor que tu envoies dans le primaire d'un transfo. Ensuite, tu redresses le secondaire, pour avoir environ 500V continus. Les condensateurs de quelque centaines de µF 600V sont courants. Avec assez de condensateurs, tu te crées une bonne réserve d'énergie, et tu t'arranges pour que le rat se coince assez longtemps entre les deux pôles pour décharger les condensateurs. Dès qu'il va toucher les deux pôles, son réflexe sera de reculer, donc prévoir peut-être un système "dents de requin" qui se ressère sur lui s'il recule.

Il faut trouver le bon couple puissance instantanée (U(t) x I(t)) et Energie (t x intégrale(P)) pour P(t) > Pmin. En gros, ton rat va rigoler si P est insuffisant, il faut donc lui envoyer un ampérage maximum pendant un certain temps, et c'est le rôle du condensateur.

500V, ça devrait aller, surtout qu'un rat est généralement humide, ça aide. si ton rat a une impédance de 70Kohms (à la louche), alors il se prendra 7mA (3,5W, pas terrible en fait...). Deux transfos pourraient te donner 1000V, soit 4x plus de puissance... Il faut ensuite calculer C en fonction du temps pendant lequel tu veux faire trembler la bête...

Là où ton arduino peut être utile, c'est pour entretenir la charge du condensateur (en utilisant la PWM pour faire une charge lente, ça évitera au transfo de fournir toute la charge au premier coup), être sûr que le transfo n'est pas alimenté pendant la mise à mort (il peut ne pas être assez costaud pour supporter un rat (quoique vu le calcul précédent...)), mais aussi évacuer le rat une fois la sentence appliquée (un poussoir qui le fait tomber dans une boîte...), sinon, les autres vont vite comprendre la supercherie, comme tu le dis, c'est futé, un rat... pis surtout que tant que tu ne seras pas intervenu, le piège sera inutile...

L'autre solution, côté élec plus simple, côté méca plus dur, c'est la guillotine, un moteur remonte la lame (pis l'aide à descendre aussi pour bien finir le boulot), un autre pousse le reste du rat dans la fosse commune... Tu n'as qu'à faire passer ton rat par un tuyau de PVC de 50mm avec le miam assez loin pour qu'il allonge bien le cou, et dès que le miam bouge, tchac... il va de soi que le rat ne peut pas accéder au miam sans passer par le tunnel de la mort...
660  International / Français / Re: PCB on: January 19, 2013, 11:30:05 am
Salut,

De mon côté, Proteus 4.1, au dessus, ça devient plus compliqué.
J'ai démarré avec isis et ares 1 (1992, proteus n'existait pas), et si je suis passé aux versions supérieures, c'est juste parce que l'interface DOS ne permettait pas de basculer facilement du typon au schéma et inversement à volonté.

Pour ton idée de modularité, j'ai voulu le faire en audio (assez simple : +VCC, -VCC, GND, gauche, droite, soit 5 fils). même connecteur en entrée qu'en sortie, on pouvait ainsi mettre les modules à la suite les uns des autres. malheureusement, je n'ai jamais utilisé ça car il y a toujours un moment où ça coince. Alors pour arduino, si tu fais un module qui utilise les pin 5 et 6 par exemple dans un projet, comment feras-tu pour un autre projet où tu dois utiliser les pins 3 et 8 car un autre module utilise déjà les pins 5 et 6?
Pages: 1 ... 42 43 [44] 45 46 ... 88