Bonjour; Je me présente étudiant en Terminale STI2D et notre projet et de réaliser un stylo 3D (Pour plus d'informations faites une recherche c'est vraiment un projet passionnant). Nous sommes dans une phase de recherche de solutions et je suis face à quelques problèmes... Je résume : - Mon premier problème : "Afficher une informations temps de fonctionnement atteint par une led" Je m'explique, à l'aide d'une RTC (DS1302 ou DS1307) nous allons estimer le temps de fonctionnement du stylo pour prévoir la maintenance du stylo en changeant la tète. Nous voulons donc mémoriser ce temps de fonctionnement lorsque l'on arrête le stylo et le cumuler ce temps lorsqu'on le rallume. Imaginons qu'on a fixé un seuil à 100h d'utilisation, le but serait de faire allumer une led qui indiquerais que les 100h sont dépassé. Mais comment réaliser cela ? ce projet est vraiment compliqué pour mon niveau, alors j'aurais besoin d'aide et de conseil. D'après mes recherches il serait plus simple d'utiliser un timer qu'une RTC car en fin de compte nous avons besoin que le nombre d'heures!
- Mon second problème : "Afficher des informations de température (Led fusion et sécurité) " Une bref schéma : On a un capteur de température (qui sort une tension variable, pour cela on va utiliser une Thermistance Pt100, La PT100 en entrée de deux comparateurs, mais avec un seuil différent (Seuil de température atteinte, seuil de sécurité) que l'on règles grâce à un potentiomètre.)-->Arduino(qui transforme la tension en valeur numérique et en déduit la température) --> La température est comparé au seuil et si elle le dépasse la led s'allume (allumée par l'arduino) C'est à peut prèt cela que je veux réaliser.
Pour résumer : - Pour les deux leds de controle température : Je peux utiliser des comparateur style LM311 pour allumé les deux DEL de contrôle de température. - Pour la led du temps de fonctonnement : je peux faire un oscillateur (NE555;CD4060 etc qui sont des timer si j'ai bien bien compris), contrôler par la mise en marche de la tête chauffante qui alimente un compteur qui, quand il atteint la bonne valeur, allume la DEL de temps écoulé.
Voilà pour résumer! Je le répète je ne cherche pas à qu'on me face mon projet non je suis juste dans une phase de recherche de solutions possibles je me renseigne donc. Ce projet est vraiment passionnant mais énorme (pour nous) et nous sommes à vrai dire un peu perdu. Nous n'avons pas beaucoup de notion, et nous sommes lâché comme ça on doit ce débrouillé quoi ce qui est assez nouveau pour nous tous. C'est pourquoi je poste sur ce forum et d'autre d'ailleurs mais c'est un peu la bazar on a du mal à réellement trouver une bonne solution.. Merci à vous
Je ne suis pas spécialiste en électronique, donc c'est juste des avis.
- quand j'ai des infos à traiter ou à conserver, je préfère utiliser un raspberry pi au lieu d'un arduino. Créer une connexion usb PC <-> Arduino n'est pas compiqué, mais une RPi en réseau avec sa propre mémoire, c'est encore plus simple
- pour des mesures de temps qui dure longtemps (à l'échelle d'un processeur), je préfère un RTC plutôt qu'un timer. Et avec une RPi, je fais juste une lecture du RTC et j'écris dans un fichier texte pour créer un tableau au format texte. Ensuite, c'est très simple d'ouvrir ce fichier dans Excel pour faire de traitement (ou faire un programme pour traiter le fichier, mais Excel fait aussi bien le boulot)
J'utilise une M41T00CAP qui contient une batterie interne (je suis fainéant, je préfère enregistrer l'heure réelle plutôt qu'un délai)
Et certain RTC sont équipé de mémoire interne
- Tu as ta thermistance et tes led branchées sur l'Arduino, pourquoi as tu besoin d'un comparateur ou d'un oscillateur ? Tu peux tout faire en dire sur l'Arduino. Idem pour la tête chauffante, non ? (perso, j'utilise un MOSFET tout bête contrôlé par le micro contrôleur pour une tête chauffante)
Voila ce que nous avons tiré comme solutions: - Pour les deux leds de contrôle température : La PT100 en entrée de deux comparateurs style LM311, mais avec un seuil différent (Seuil de température atteinte, seuil de sécurité) que l'on règles grâce à un potentiomètre.-Arduino qui transforme la tension en valeur numérique et en déduit la température --> La température est comparé au seuil et si elle le dépasse la led s'allume (allumée par l'arduino) - Pour la led du temps de fonctionnement : a la place d'un oscillateur nous allons utiliser une RTC style DS1307 ou DS1302 car de toutes façons nous allons devoir stocker le temps de fonctionnement sur la case mémoire de la RTC, elle sera contrôler par la mise en marche de la tête chauffante(le problème sera comment réaliser cela) qui alimente un compteur qui, quand il atteint la bonne valeur, allume la DEL de temps écoulé.
Bonsoir; Nous réfléchissons aussi à d'autre solutions : Si je comprends bien : Dans la carte arduino on a un microcontrôleur type ATMEGA328, et un timer y es intégré. C'est bien cela ou est-ce un module à part ?
Ensuite avec ceci on va pouvoir mesurer une durée. Mais pour la stocker ? On peut faire cela dans l'eeprom interne d'arduino non ?
Pour finir, pour allumer les leds en fonction (du temps pour la première led) j'aurais juste à faire un programme arduino, qui lorsque le temps fixé sera atteint déclenchera une led ? pour les leds de contrôle de température, plutôt que des comparateurs externes il est plus simple d'utiliser une (seule) entrée analogique du contrôleur et d'effectuer la comparaison à des seuils (à l'aide pareille d'un programme).
Tout cela n'est-il pas trop compliqué ? étant donné mon faible niveau en language arduino..
Le kit velleman MK138, qui permet de faire une action (pour moi ce serais d'allumer une led) lorsque l'on est au dessus d'une température, d'après vous serait-ce une bonne solution ?
Merci infiniment pour toutes votre aide, et le temps que vous prenez.
Je ne suis pas spécialiste en électronique, donc c'est juste des avis.
- quand j'ai des infos à traiter ou à conserver, je préfère utiliser un raspberry pi au lieu d'un arduino. Créer une connexion usb PC <-> Arduino n'est pas compiqué, mais une RPi en réseau avec sa propre mémoire, c'est encore plus simple
- pour des mesures de temps qui dure longtemps (à l'échelle d'un processeur), je préfère un RTC plutôt qu'un timer. Et avec une RPi, je fais juste une lecture du RTC et j'écris dans un fichier texte pour créer un tableau au format texte. Ensuite, c'est très simple d'ouvrir ce fichier dans Excel pour faire de traitement (ou faire un programme pour traiter le fichier, mais Excel fait aussi bien le boulot)
Merci mais STOP avec cette P**** de Raspberry Pi quoi. Marre d'en entendre parler à tout va.
Une Raspberry Pi c'est orienté ordinateur personnel pas cher et pas puissant.
Quand tu veux planter une tulipe (donc un bulbe) tu sors un outil adapté : une petite pelle à main ou un plantoir. En proposant une Raspberry c'est comme si tu proposais la pelleteuse de 25 tonnes...
Je suis ravi que tu aide sur le forum électronique, c'est sincère, mais si c'est pour ne proposer que la Raspberry Pi, désolé mais retiens toi un minimum.
Ensuite l'électronique et l'embarqué c'est penser en terme de système : batterie ou secteur -> consommation ? poids/encombrement ? budget ? etc.
Pour l'OP :
Obligé d'utiliser une Arduino Uno ? Combien avez-vous besoin de timers ? Il suffit de prévoir un timer suffisamment long en plus sur votre microcontroleur pour gérer le temps d'utilisation qui sera stocké sur l'EEPROM du MCU et basta. Surtout vous n'êtes pas à la minutes près donc la précision d'une RTC n'est pas nécessaire.
Oui je "obligé" disons d'utiliser une Arduino uno. Nous avons besoin d'un seul timers donc c'est largement suffisant étant donné que la carte arduino en a 3. Oui on est pas du tout à la minute prèt c'est pour cela que je pense que ce n'est pas nécessaire en fin de compte.
Merci pour le conseil, mais je ne vais pas le suivre (pour être poli)
Je connais très bien la différence entre RPi et Arduino. J'ai bien précisé que j'évoquais la RPi pour se capacité de connexion en wifi et son disque SD, fonctionnalités qui sont plus difficiles avec un Arduino. J'utilise sans problème Arduino, voir des micro contrôleurs directement, mais je sais aussi analyser un besoin. Et là, je vois : besoin d'enregistrer des données sur du long terme (quelques jours ? quelques semaines ? quelques mois ?) et de récupérer ces données pour analyse (le besoin de base est d'avoir le temps total d'utilisation de sa tête, pas besoin d'une SD pour ça en effet. Mais on peut imaginer qu'il souhaiterait aussi avoir des stats plus avancées, comme la durée moyenne d'utilisation de sa tête à chaque utilisation, l'évolution des températures, etc. Et là, une SD est adaptée).
J'ai bien précisé le pourquoi je proposais l'utilisation de la RPi dans ce cas. Si tu n'es pas d'accord avec moi, pas de problème, on peut discuter. Mais tu me permettra quand même d'avoir un avis personnel, sur la solution à proposer et sur le fait de la partager ou non.
Par exemple, mon avis sur tes questions (batterie, poids, encombrement, budget), sachant qu'il s'agit d'un stylo 3D qui consomme et coûte beaucoup plus que n'importe quelle carte embarquée, je ne crois pas que c'est des questions pertinentes. Mais peut être que je me trompe. Mais je partage mon avis quand même
Le choix d'une d'une RTC (avec une RPi bien sûr, pour faire plaisir à zeqL) n'est pas sans intérêt par rapport à un timer. Lorsque tu fais un timer pour allumer une LED toutes les secondes, une erreur de quelques milli secondes ne pose absolument aucun problème. Par contre, comme ton but est de calculer un temps total d'utilisation (donc plusieurs centaines d'heures ? Milliers d'heures ?) tu devras accumuler plusieurs milliers ou millions de fois ton timer. Une erreur systématique sur le temps va donc s'accumuler et les erreurs de mesure aléatoires s'accumulent selon sqrt(n) (de mémoire, à vérifier).
Avec une RTC, tu n'auras pas d'erreur de mesure systématique et l'erreur finale sera bien inférieure à ce que tu auras avec un timer.
Par contre, se pose la question de savoir si cette erreur de mesure est importante et intéressante à mesurer. En toute honnêteté, je n'en sais rien (mais cela pourrait être intéressant pour toi d'implémenter les 2 méthodes et voir les résultats de la mesure des erreurs)
Oui je suis bien conscient de cela, j'en ai parlé à mon prof et il m'a dit que le changement de la tète ce fera peut ètre (c'est un exemple) au bout de 100h une erreur de 10/15min ne sera pas grave, on pourrait prévoir par "sécurité" un seuil à 98h au lieu de 100h pour combler ces erreurs.
- L'OP demande un discret pour indiquer un temps de fonctionnement dépassé, ici 100h. Toi tu lui répond Raspberry Pi + RTC, statistique, graph, etc... Je ne dis pas que c'est de la merde pour faire des stats et tout, mais pour allumer une led, désolé c'est sortir le char d'assaut pour rien.
- Mes questions de consommation, poids, encombrement sont des questions générales pas spécifiques à ce topic.
Et oui le stylo est sur secteur, est-ce pour autant qu'il faut lui mettre un outil de contrôle qui consomme 5W là où tu peux en mettre un qui consomme 500mW ? Et de toute façon même s'il a besoin de la puissance de calcul d'une Raspberry Pi je conseillerai plutôt une BBB pour son projet, mais on s'écarte du sujet.
- Statistiques ? Faut des données, donc des capteurs, vu le peu de ports de la Raspberry... Ensuite en quoi une carte SD est adaptée ?
Si tu fais une carte dédiée pour le bouzin, de l'EEPROM ou de la Flash peut aussi être adaptée, tout dépend de ton interface de sortie : écran directement relié à la carte, un écran plat ou un petit afficheur 2 lignes ? Par réseau Ethernet ? Par liaison RS232 ou USB ? Par une carte mémoire ?
- Concernant la RTC, lal quoi. 1 milliseconde sur 1h -> 1 sur 3.6 million (la chance au loto est d'environ 1 pour 13 millions et je bosse sur un problème hard/soft dont l'occurence a été de 4 sur 66 millions).
Si on ne sait pas ce qu'on doit "mesurer", effectivement 1 ms ca peut être dérangeant. Si on remet dans le contexte du stylo 3D bah 1 ms de plus ou de moins par heure pour un embout bah c'est invisible. Une erreur de 1% est acceptable (1h pour 100h). L'embout ne va pas exploser non plus. Et comme dit par SGR-métrage tu met ta limite à 98-99h et basta.
Les révisions constructeurs d'une voiture c'est pris avec de la marge, si tu fais 30 001km ta voiture ne va pas s'arrêter et exploser parce que tu n'a pas fait la révision.
En revanche sur un avion qui atterrit, si les roues avant ne sont pas parfaitement droite et ont ne serait-ce qu'un pouillème de degré de désaxage, à 200-300 km/h et sur une piste large de quoi, 10 mètre, bah on risque de sortir de la piste.
Enfin concernant les timers, merci de lire la doc Atmel sur le fonctionnement des timers, prescalers et comparateurs. Tu peux très bien faire une interruption toutes les secondes (1Hz) à partir de la fréquence de 16 Mhz de l'Arduino Uno et même 0.5Hz.
Petit calcul : 100h = 3600 * 100 = 360 000
Log(360 000) / log(2) = ~18.5 -> 19 bits d'information, sachant que est sur des registres 8 bits, il faudrait 3 registres 8 bits pour stocker le temps à la seconde près.
L'EEPROM de l'ATMega328 fait minimum 256 bytes (octets)... Et on a une utilisation de 100 000 cycles. En étant pessimiste, on va dire que l'on fait 10 cycles pour utilisation du stylo, donc ca nous ferait 10 000 allumages/exctinction du stylo. En prenant 10 allumages/exctinction par jour, on arrive à 1000/360 = 2,7. Donc l'EEPROM du microcontroleur serait problématique au bout de 2 ans et demi.
Sachant que j'ai pris des valeurs larges, on peut tabler minimum sur une utilisation de 3 ans minimum voire jusqu'à plus de 10 ans au niveau de l'EEPROM.
Tout ca avec une Arduino et sans composant externe et avec une précision de quelques secondes inhérentes au temps d'interruption et de traitement des données.
Car l'erreur de mesure avec le timer ou la RTC sera la même en utilisation finale : on ne prend pas en compte le temps de chauffe et de refroidissement exact de l'embout. Donc vouloir du 10-9 en précision sur une mesure qui de base ne peut pas être précise, c'est complexifier les choses pour rien.
@gbdivers : ce n'est pas contre toi en particulier, mais c'est juste que depuis la Raspberry Pi, dès qu'un projet devient un petit peu complexe pour une Arduino, bam on sort la grosse artillerie aka Raspberry Pi.
Non désolé l'électronique et l'embarqué c'est pas juste du Lego avec des trucs préfait, c'est aussi se creuser les méninges pour répondre à des contraintes.
Mon métier c'est en autre de concevoir des cartes électronique ou de faire du débug hard/soft de calculateurs. Dans ce dernier cas je travaille sur du matériel vieux de plus de 10 ans et au design totalement spécifique au besoin.
Y a 10, 20 ou même 30 ans y avait par d'Arduino ni de Raspberry Pi et on s'en sortait quand même pour faire voler des avions. Oui des fonctions critiques d'avions sont basées sur des processeurs vieux de 30 ans (Intel 286). Avec des putains de reflexion sur l'optimisation de bus, de mémoire, etc. (et aussi des bugs à la con, tout n'est pas parfait).
Alors quand je vois aujourd'hui Arduino Uno par là et Raspberry Pi ici ca m'énerve un peu que les gens ne fasse pas marcher un peu leurs méninges.
L'électronique, faire ses propres cartes, ca coûte cher, ca demande des connaissances, des outils que tout le monde n'a pas. Et je dis bravo au projet Arduino pour avoir pu démocratiser les cartes de dév et simplifier la programmation des microcontroleurs.
Sauf que revers de la médaille, si on trouve des projets vraiment intéressants, on se retrouve aussi avec des personnes totalements passives qui n'attendent qu'un manuel de Lego pour assembler leurs "briques" (enfin shields) et qui n'ont probablement jamais regarder la datasheet de l'ATMega328 qui compose l'Arduino.
Donc voilà d'où vient un peu mon énervement, qui n'était pas contre toi en particulier, mais de manière générale.
Copié/collé de mon édit qui n'a pas dû être lu par gbdivers :
@gbdivers : ce n'est pas contre toi en particulier, mais c'est juste que depuis la Raspberry Pi, dès qu'un projet devient un petit peu complexe pour une Arduino, bam on sort la grosse artillerie aka Raspberry Pi. Non désolé l'électronique et l'embarqué c'est pas juste du Lego avec des trucs préfait, c'est aussi se creuser les méninges pour répondre à des contraintes.
Mon métier c'est en autre de concevoir des cartes électronique ou de faire du débug hard/soft de calculateurs. Dans ce dernier cas je travaille sur du matériel vieux de plus de 10 ans et au design totalement spécifique au besoin.
Y a 10, 20 ou même 30 ans y avait par d'Arduino ni de Raspberry Pi et on s'en sortait quand même pour faire voler des avions. Oui des fonctions critiques d'avions sont basées sur des processeurs vieux de 30 ans (Intel 286). Avec des putains de reflexion sur l'optimisation de bus, de mémoire, etc. (et aussi des bugs à la con, tout n'est pas parfait).
Alors quand je vois aujourd'hui Arduino Uno par là et Raspberry Pi ici ca m'énerve un peu que les gens ne fasse pas marcher un peu leurs méninges.
L'électronique, faire ses propres cartes, ca coûte cher, ca demande des connaissances, des outils que tout le monde n'a pas. Et je dis bravo au projet Arduino pour avoir pu démocratiser les cartes de dév et simplifier la programmation des microcontroleurs.
Sauf que revers de la médaille, si on trouve des projets vraiment intéressants, on se retrouve aussi avec des personnes totalements passives qui n'attendent qu'un manuel de Lego pour assembler leurs "briques" (enfin shields) et qui n'ont probablement jamais regarder la datasheet de l'ATMega328 qui compose l'Arduino. Donc voilà d'où vient un peu mon énervement, qui n'était pas contre toi en particulier, mais de manière générale.
J'aime bien les legos. Plus que les playmobiles en tout cas. Mais je préférais quand même les meccanos.
Je peux comprendre ton agacement sur le fait de voir de plus en plus de personnes choisir la facilité et le résultat immédiat plutôt que comprendre les choses correctement. J'ai le même problème sur le forum C++.
Mais le problème n'est pas l'utilisation de boites noires en général, mais le fait de ne pas prendre le temps de faire les choses correctement. J'ai un RPi et un Arduino Uno pour le prototypage et honnêtement, je n'ai pas regardé les specs des contrôleurs. Parce que je m'en moque. C'est conçu pour servir de boite noire, on branche, on programme et ça marche. Et pourtant, j'ai pris le temps de faire les choses correctement, en commençant par apprendre à allumer un led et détecter un bouton poussoir.
J'ai un cerveau un peu limité, je n'arrive pas à faire trop de choses en même temps. Quand j'étudie le fonctionnement d'un capteur, d'un bus I2C ou à contrôler un moteur pas à pas, je n'ai pas envie de m'occuper des problématique de fonctionnement interne du contrôleur. Ou à essayer d'optimiser la consommation, l'encombrement, ou n'importe quel autre détail qui ne concerne pas ma problématique immédiate. Utiliser une carte surdimensionnée peut faciliter les choses, avoir un système linux complet, un SD de 16 Go et une connexion wifi aussi.
Je ne pense pas être non plus un idiot profond en électronique. J'en faisais il y a très longtemps, dans une galaxie lointaine...J'ai étudié les bases, kirkoff, équa diff des RLC, j'ai programmé en assembleur différents types de proc (6809, Z80, 68000, etc). Pour autant, je n'ai pas envie de passer des heures à faire des calculs de résistance, tension, puissance, etc. J'ai envie de passer mon temps sur autre chose.
Donc le principe des boites noires me convient très bien et ce n'est pas prêt de changer. Parce que c'est simple et rapide. Le projet du PO, il me faudrait 5 minutes à concevoir sur un breadbord avec une RPi. Ou avec une Arduino, mais avec moins de fonctionnalité. Et sans avoir à lire le datasheet de l'ATmega328. J'ai déconseillé l'utilisation d'un RPi pour un projet de robot récemment sur le forum, où il fallait contrôler plusieurs moteurs et capteurs. Mais quand la RPi fait le boulot, pas de raison de ne pas la proposer, même si elle est sur-dimensionné pour la problématique (je n'ai pas dit "conseillé" ou dit que c'était la solution la plus adapté. J'ai expliqué comment on peut l'utiliser et quelles fonctionnalités cela permettait d'avoir. Libre au PO de voir si cela correspond à ses besoins et moyens).
Je ne vais pas m'embêter à faire de l'électronique comme il y a 30 ans alors qu'on a des moyens plus simple aujourd'hui (et vu comment je galérais lorsque je faisais un peu d'électronique il a 30 ans - avec un kit Electronique 2000 et des composants récupérés - je suis très content des boites noires).
Enfin bref, tu risques de me voir encore parler de la RPi
Je ne suis pas hardcore dans le sens où il faut connaître par coeur les datasheet de tout ce qu'on utilise et faire des calculs de derating sur les résistances.
Il y a des choses qui relèvent du monde professionnel et dont il n'y a pas forcément besoin en tant qu'amateur. Je n'ai jamais dit que lorsque tu utilise un module I2C tu devais te farcir la norme I2C, non si c'est normé c'est pour simplifier l'utilisation et heureusement, ca me saoulerait de devoir créer des bus maison à chaque nouvelle carte et faire en sorte que ce soit compatible avec les composants que j'utilise.
La Raspberry Pi et l'Arduino Uno ne sont pas des boites noires, car tu peux les programmer. Une "boite noire" c'est un élément à qui tu rentre des données et paramètres en entrée et en sortie tu reçois un résultat. Résultat que tu peux connaître grâce à une simplification du fonctionnement de la boite.
A partir du moment où c'est toi qui programme ce qu'il y a à l'intérieur de la boite noire, ce n'est plus une boite noire.
Un shield en revanche peut être considéré comme une boite noire, il a des entrées et sorties et réalise une fonction (ou plusieurs).
Et lire une datasheet ne fait pas de mal, aux dernières nouvelles l'explication du fonctionnement des timers de "l'Arduino" est dans la datasheet de l'ATMega328.
Concernant l'électronique d'il y a 30 ans, ce n'était pas pour dire qu'il faut utiliser des 286 aujourd'hui, non on est à l'époque des ARM 32 bits, l'USB, PCIexpress, etc. Soyons modernes, mais restons intelligents aussi.
Enfin, on ne sera jamais d'accord, donc pas la peine de continuer pour ma part. Tu fais du soft (C++ et Qt), je fais de l'électronique contrainte, on a des visions des choses totalement différentes et le débat sera totalement stérile, surtout quand je prend 1h de mon temps personnel (et de mon sommeil) pour expliquer ma "vision" et que finalement tu te contente de dire que tu te casse pas la tête et que tu es là pour proposer des choses et que ce n'est pas de ta faute si ce n'est pas adapté.
Désolé mais j'ai autre chose à faire que de passer 1h à tenter de montrer un raisonnement d'électronicien, démonté en 2 minutes par un argument de facilité. Donc plutôt que de continuer à polluer ce topic, je préfère en rester là. (Tu peux toujours me contacter par MP)
On est d'accord sur un point, on n'a pas la même vision. Effectivement, je pense en premier lieu en tant que dév C++ (on connecte tout et on gère côté code).
Un point sur lequel on n'est pas d'accord, c'est que je crois que ma solution est adaptée. Elle ne propose pas les mêmes avantages et inconvénients qu'une Arduino ou un circuit imprimé home-made, mais cela reste une solution à envisager.
Et je pense que l'on peut considérer que le RPi ou Arduino comme des boites noires : on peut appeler d'un côté une fonction digitalWrite et brancher une led+résistance directement sur une sortie et ignorer tout ce qu'il y a entre 2. Idem pour le timer, on appelle une fonction delay, pas besoin de savoir comment c'est géré en interne par le ATmega ou le BCM.
Bref, des visions différentes, mais le boulot est fait dans les 2 cas
Idem pour le timer, on appelle une fonction delay, pas besoin de savoir comment c'est géré en interne par le ATmega ou le BCM.
Désolé je ne peux pas laisser passer ca. La fonction hardware timer est totalement différente d'un delay.
Un delay va "bloquer" le CPU pendant le temps spécifier, en gros c'est comme si tu faisait faire des 'nop' pendant la durée du delay.
La fonction hardware timer c'est un bloc hardware que tu configure et que tu lance. Une fois qu'il arrive au résultat (la fin du compteur, une comparaison vraie, etc.), il émet un signal d'interruption (et tu peux donc appeler une fonction d'interruption). Et pendant qu'il compte tu peux faire autre chose, il se débrouille tout seul.
Concernant la Raspberry Pi, la plupart des utilisateurs utilisent un OS (Linux) qui permet de s'affranchir des spécificités du hardware grâce au kernel et aux drivers. Sur une Arduino il n'y a pas d'OS tu programme donc en fonction du hardware. Et tu peux aussi programmer sans OS ton SoC broadcom et tu sera aussi obligé de prendre en compte les spécificités du hardware.
Enfin concernant les boites noires, oui on peut toujours descendre en niveau, évidemment tu peux t'en foutre royalement de savoir le chemin que prend le signal électrique dans les transistors du die lorsque tu fais une digitalWrite.
Merci pour la précision sur les timers hardware, pour les autres lecteurs.
En pratique, regarde les codes utilisant le timer sur Arduino (par exemple ceux du tuto Arduino), la fonction delay est synchrone, on lance et on attend. Savoir si cela lance un boucle en interne ou un timer hardware, on s'en moque complètement pour ces codes d'exemple, on ne fait rien pendant ce temps. Je ne suis même pas sur qu'il soit possible de gérer les timers hardware avec le SDK Arduino.
Même s'il n'y a pas d'OS sur Arduino, il y a un SDK, qui est utilisé je crois par la majorité des utilisateurs. Et on n'a pas besoin de connaître le hardware pour utiliser une Arduino. D'ailleurs, le tuto Arduino passe très rapidement sur la partie hardware et ne donne que des généralités qui sont applicables sur la majorité des contrôleurs.
Je crois que la majorité des utilisateurs de Arduino cherchent avant tout la simplicité d'utilisation, pas à obtenir le maximum des contrôleurs ATmega.
Mais je me trompe peut être sur le public visé par Arduino
(on est complètement HS, si un modo veut faire un split de la discussion, merci)
Dites les copains ca vous tenterait de copier/coller vos réponses respectives dans un nouveau thread, histoire de faire un débat à côté plutôt qu'ici ?
Bonjour, Je vous remercie pour votre conversation j'ai appris beaucoup de chose Après de multiple débats avec notre professeur nous avons été obligé de prendre une RTC plutôt qu'un Timer. Pour allumer une led au bout d'un certain temps de fonctionnement voila ce que j'ai compris :
Avec la RTC (Grove ou DS1307) contrôler par la mise en marche de la tête chauffante qui alimente un compteur qui, quand il atteint la bonne valeur, allume la DEL de temps écoulé.
Nous allons mesurer le temps avec la RTC, ce temps sera stocké dans la mémoire internet de la RTC. Dans le principe est-ce cela ? Mais je ne comprends pas vraiment comment allumer une led au bout d'un certain temps à l'aide d'une rtc... merci de votre aide.
Tu as compris ce qu'était une RTC ?
Une RTC c'est un peu comme une montre, ca te donne l'heure... et c'est tout. Tu ne stockes rien dedans (à part l'heure).
Oui, mais sur une rtc on trouve une mémoire RAM de 56 octets non volatile, donc on peut stocker dessus. Je m'exprime peut ètre mal, lorsque je parle de "stocker" c'est stocker l'heure en cas de panne de courant par exemple, la mémoriser.
La RTC est une montre, et justement j'aimerais allumer une led au bout d'un temps donné (ex : 100h) mais je ne fais que de faire des recherches dessus... et je ne trouve que des solutions si on utilisait un timer.
- Edité par SGR-métrage 11 février 2014 à 20:22:59
Non les 56 octets sont de la RAM, c'est donc volatile. Simplement tu peux mettre une tension de backup sur la RTC pour qu'elle consomme très peu (500nA) et garder ses données. Si tu ne prévois pas de pile, supercapa ou autre source de tension, les données seront perdues.
D'autre, oui c'est une sorte de montre, ca te donne l'heure à un instant T, si tu veux le temps écoulé avec entre 2 instants, tu devra faire le calcul au niveau du microcontroleur.
Donc en plus d'acheter une puce en plus qu'il faudra gérer, si tu veux garder les infos, il faut prévoir une source de secours.
J'ai décris plutôt dans le détail la solution du timer, plutôt bien adapté à ton cas. Tout n'a pas été réfléchis et il faut donc travailler un peu la solution pour aboutir à un truc à peu près correct.
Maintenant ton prof t'as dit d'utiliser une RTC, soit.
Je suis totalement d'accord avec vous, je suis conscient que le timer est une meilleure solution... mais voila mon prof m'impose la RTC je n'ai vraiment pas le choix. Cette après midi je lui en est encore parlé il m'a envoyé bouler... Je n'ai plus le choixNos solutions concernant les parties de notre projet sont à présenter dans deux jours(le projet compte coefficient 12 au bac) , j'ai bosser sur toutes mes autres solutions mais celle-ci je bloque et il faut vraiment que je m'y mette.... mème si je suis conscient que la RTC n'est pas la bonne solution. Je dois faire avec et je suis totalement perdu à ce sujet..
Je ne fais parcourir que forum sur forum... je n'arrive pas à trouver de solutions. Beaucoup vienne ici en attendant qu'on leur donne la réponse mais moi ce n'est pas de mon cas. J'ai de grosse lacune en électronique, c'est d'ailleurs le cas de tout le monde dans notre classe mais nous devons faire avec et nous avons ce projet coefficient 12 au bac! Je passe des heures et des heures à bosser chaque soir dessus... je sais que beaucoup pense que je dois le faire exprès car je n'y comprends rien mais ce n'est vraiment pas voulu.
Si je requiert votre aide c'est que je suis vraiment perdu à ce sujet, je ne sais pas si c'est possible à mettre en place... et comment le faire..
merci de votre patience..
ps : Je tiens à préciser pour zeqL que si effectivement nous prévoyons une pile qui devrait faire tenir la RTC de nombreuses années sans alimentation au cas ou il y a une coupure
- Edité par SGR-métrage 11 février 2014 à 20:57:22
Et donc c'est quoi le problème ? Comment tu vas faire pour calculer tes 100 heures ?
Fais abstraction du microcontrolleur, si je te donne une montre et un cahier et que je te demande combien de temps tu es resté éveillé pendant un mois, tu feras comment ?
Mon problème ? C'est d'allumer une led lorsque ces 100h (c'est un exemple) sont écoulé à l'aide de la RTC.
Je dis surement des bêtises mais mais on détecte l'allumage et l'extinction et à l'allumage et à l'extinction, on lis les valeurs dans le DS1307. On soustrait et on accumules en mémoire. Dans ma tète ça donne ça mais après si c'est réalisable c'est autre chose...
- Edité par SGR-métrage 11 février 2014 à 21:06:31
Bah tu vois quand tu veux !
Après faut le faire... L'allumage c'est pas vraiment un problème, par contre l'extinction se sera plus délicat puisqu'il faut détecter l'extinction et lancer une procédure pour sauvegarder le temps écoulé
En fait je comprends dans la "théorie" mais lorsqu'il faut mettre les choses en place comme le matériel à utiliser, la procédure etc.. je suis directement paumé.
Pour sauvegarder le temps écoulé je pensais me servir de ce bout de code :
#define DS1307_ADDRESS 0x68
typedef struct {
uint8_t secondes;
uint8_t minutes;
uint8_t heures; // format 24h
uint8_t jourDeLaSemaine; // 0~7 = lundi, mardi, ...
uint8_t jour;
uint8_t mois;
uint8_t annee; // format yy (ex 2012 -> 12)
} Date;
// Ps uint8_t est un synonyme de byte, byte ne pouvant etre utilise dans un structure contenu dans un .h externe
// Fonction configurant le DS1307 avec la date/heure fourni
void ecrire(Date *date) {
Wire.beginTransmission(DS1307_ADDRESS); // Début de transaction I2C
Wire.send(0); // Arrête l'oscillateur du DS1307
Wire.send(dec2bcd(date->secondes)); // Envoi des données
Wire.send(dec2bcd(date->minutes));
Wire.send(dec2bcd(date->heures));
Wire.send(dec2bcd(date->jourDeLaSemaine));
Wire.send(dec2bcd(date->jour));
Wire.send(dec2bcd(date->mois));
Wire.send(dec2bcd(date->annee));
Wire.send(0); // Redémarre l'oscillateur du DS1307
Wire.endTransmission(); // Fin de transaction I2C
}
// Fonction récupérant l'heure et la date courante à partir du DS1307
void lire(Date *date) {
Wire.beginTransmission(DS1307_ADDRESS); // Début de transaction I2C
Wire.send(0); // Demande les info à partir de l'adresse 0 (soit toutes les info)
Wire.endTransmission(); // Fin de transaction I2C
Wire.requestFrom(DS1307_ADDRESS, 7); // Récupère les info (7 octets = 7 valeurs correspondant à l'heure et à la date courante)
date->secondes = bcd2dec(Wire.receive()); // stockage et conversion des données reçu
date->minutes = bcd2dec(Wire.receive());
date->heures = bcd2dec(Wire.receive() & 0b111111);
date->jourDeLaSemaine = bcd2dec(Wire.receive());
date->jour = bcd2dec(Wire.receive());
date->mois = bcd2dec(Wire.receive());
date->annee = bcd2dec(Wire.receive());
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Retrouvez moi sur mon blog et ma chaine Youtube !
Retrouvez moi sur mon blog et ma chaine Youtube !
Retrouvez moi sur mon blog et ma chaine Youtube !
Retrouvez moi sur mon blog et ma chaine Youtube !
Retrouvez moi sur mon blog et ma chaine Youtube !
Retrouvez moi sur mon blog et ma chaine Youtube !