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.
--------------------
gbdivers
@zeqL
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
@SGR-métrage
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)
- 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.
--------------------------
gbdivers
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)
Sur ce, bonne chance à l'OP.
--------------------------
gbdivers
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.
--------------------------
gbdivers
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)
C'est marrant de voir les points de vue informaticien VS. electronicien.
C'est intéressant de voir le workflow de chacun. Souvent en informatique "classique" on fait le code et on optimise plus tard. Alors que du point de vue de l'électronicien, l'optimisation passe dès la phase de conception, pour choisir le matériel.
On manque pas un peu de sensibilisation par rapport à tout ca en école d'ingé ?
(Je dis ca car ayant une formation IUT (élec+info) on était sensibilisé au côté "faite gaffe aux variables" puis plus tard en école d'ingé pure info c'est "instancié, il y a la place !")
En informatique "classique", on programme sur un ordinateur type x86, avec un processeur extrêmement puissant, une grosse capacité de RAM et de stockage (HDD). Et en cas de besoin, une carte graphique permet de faire des calculs graphiques complexes.
Pour faire simple, pour la plupart des programmes et applications, on est rarement limité par le hardware, ou alors c'est que le programme est très mal optimisé. Il reste bien sûr des programmes optimisés qui sont tout de même contraints par le hardware mais on est sur des logiciels qui effectuent souvent des calculs complexe en masse, ce qui ne représente qu'une fraction infime des programmes et applications disponibles.
Tandis qu'en électronique, d'une part au niveau conception de carte, le but est d'utiliser le moins de composants possible pour optimiser les coûts, la consommation, la conception, etc.
C'est là la grande différence : développer un programme informatique, revient pour la plupart du temps seulement au prix du développeur, tandis que pour une carte électronique outre le prix du développeur, il faut ajouter le coût de la carte et des composants.
Je migre maintenant vers les microcontroleurs et l'informatique embarquée, en général on développe sur des cartes spécifiques. Donc au niveau de la conception de la carte, on va essayer de mettre le MCU le plus adapté (et le moins cher) pour réaliser la fonction.
Dans le cas cité plus haut, une RTC coûte souvent quelques dollars à l'unité, presque le prix d'un microcontroleur, et elle consommera en plus. Alors oui ca sera peut-être plus précis et offriera plus de fonctionnalités, mais est-ce un besoin ou un bonus ? Et est-ce que ce bonus vaut le prix à payer en terme de "prix" du composant et de la consommation supplémentaire ?
Ce sont ces questions que l'on se pose en électronique et en informatique embarquée.
Or les MCU deviennent de plus en plus puissants et les contraintes de développement s'estompent.
Tandis qu'en électronique, d'une part au niveau conception de carte, le but est d'utiliser le moins de composants possible pour optimiser les coûts, la consommation, la conception, etc.
C'est là la grande différence : développer un programme informatique, revient pour la plupart du temps seulement au prix du développeur, tandis que pour une carte électronique outre le prix du développeur, il faut ajouter le coût de la carte et des composants.
Je migre maintenant vers les microcontroleurs et l'informatique embarquée, en général on développe sur des cartes spécifiques. Donc au niveau de la conception de la carte, on va essayer de mettre le MCU le plus adapté (et le moins cher) pour réaliser la fonction.
Dans le cas cité plus haut, une RTC coûte souvent quelques dollars à l'unité, presque le prix d'un microcontroleur, et elle consommera en plus. Alors oui ca sera peut-être plus précis et offriera plus de fonctionnalités, mais est-ce un besoin ou un bonus ? Et est-ce que ce bonus vaut le prix à payer en terme de "prix" du composant et de la consommation supplémentaire ?
Ce sont ces questions que l'on se pose en électronique et en informatique embarquée.
Ce sont des contraintes du milieu professionnelle (en C++, on aurait de problème équivalent concernant les optimisations, le temps de développement, les temps de compilation, etc.)
Mais dans le cadre amateur, ça n'a pas d'importance. J'ai plusieurs micro contrôleur, donc certain me servent pas (je les ai juste acheter pour tester). Quelques dollars, ça a une importance quand tu vas vendre ton produit, que tu vas le produire en plusieurs milliers d'exemplaires, qu'il sera en concurrence avec d'autres produits, etc. Mais quand tu en acheté un nombre limité et que tu les réutilises tout le temps ? J'ai acheté un RTC, j'ai vu la différence de prix, je me suis pas embêté : j'ai pris la version avec batterie interne pour 1 euro de plus. J'ai un ATMEGA2560, j'aurais pu prendre un plus petit.
L'argument est valable aussi pour la consommation ou l'encombrement (dans une majorité de cas). C'est également valable pour la RPi. Si tu n'as les 2, quel est le problème de prendre la RPi, même si elle est surdimensionné ? Si tu as une RPi et pas d'Arduino, il faudrait acheter une Arduino parce que la RPi est surdimensionnée ?
Si la personne n'a aucune carte et qu'elle a les moyens, perso je lui conseillerait d'acheter une RPi et une Arduino, c'est deux cas d'applications différents (c'est ce que j'ai fait). Ou une carte qui intègre les avantages des 2 (linux, wifi, pleins de IO). S'il n'a pas les moyens d'acheter les 2... honnêtement, je ne sais pas ce que je conseillerais. J'aime beaucoup la connectivité et la mémoire de RPi. Je ne saurais dire s'il est mieux d'acheter un arduino ou une RPi + GPIO expender + DAC/ADC (le principal argument est le coût de l'option avec RPi)
Ce sont des contraintes du milieu professionnelle (en C++, on aurait de problème équivalent concernant les optimisations, le temps de développement, les temps de compilation, etc.)
Mais dans le cadre amateur, ça n'a pas d'importance. J'ai plusieurs micro contrôleur, donc certain me servent pas (je les ai juste acheter pour tester). Quelques dollars, ça a une importance quand tu vas vendre ton produit, que tu vas le produire en plusieurs milliers d'exemplaires, qu'il sera en concurrence avec d'autres produits, etc. Mais quand tu en acheté un nombre limité et que tu les réutilises tout le temps ? J'ai acheté un RTC, j'ai vu la différence de prix, je me suis pas embêté : j'ai pris la version avec batterie interne pour 1 euro de plus. J'ai un ATMEGA2560, j'aurais pu prendre un plus petit.
L'argument est valable aussi pour la consommation ou l'encombrement (dans une majorité de cas). C'est également valable pour la RPi. Si tu n'as les 2, quel est le problème de prendre la RPi, même si elle est surdimensionné ? Si tu as une RPi et pas d'Arduino, il faudrait acheter une Arduino parce que la RPi est surdimensionnée ?
Si la personne n'a aucune carte et qu'elle a les moyens, perso je lui conseillerait d'acheter une RPi et une Arduino, c'est deux cas d'applications différents (c'est ce que j'ai fait). Ou une carte qui intègre les avantages des 2 (linux, wifi, pleins de IO). S'il n'a pas les moyens d'acheter les 2... honnêtement, je ne sais pas ce que je conseillerais. J'aime beaucoup la connectivité et la mémoire de RPi. Je ne saurais dire s'il est mieux d'acheter un arduino ou une RPi + GPIO expender + DAC/ADC (le principal argument est le coût de l'option avec RPi)
En conception professionnelle, les prix n'ont rien à voir à ceux affichés sur les sites. Les composants "chers" se négocient à plus de 4 ou 5 fois leur prix "public" (oui une boîte qui fait des équipements à gros volume, négocie des FPGA à 25$ à moins de 5$...).
Dans le cas du post avec la RTC, oui 1 euros c'est rien (enfin pour moi je m'en fout), mais donc sous prétexte que 1€ c'est rien, on peut se permettre de l'acheter ? A partir de quel prix fixes-tu la limite ?
Quand je vois des posts où des personnes trouvent limite qu'une Arduino Uno ou une Raspberry Pi est trop chère mais d'autres (ou les même) vont dépenser presqu'une centaine d'euros dans des shields Arduino, plutôt inutiles à mon goût, comme tout ceux qui concernent le Wifi ou l'Ethernet...
Cela ne me dérangerait pas si derrière ces personnes ne s'offusquaient pas d'une carte de développement à plus de 150$ : Beagle Board XM, cartes de dév de FPGA (Terasic, Digilent), etc.
Ce qu'il faut se rendre compte c'est qu'une Arduino c'est plus ou moins une breakout board avec l'oscillateurs et le programmateurs du MCU intégré (c'est déjà pas mal). Mais le marché des shields est vraiment une grosse arnarque.
Pour revenir sur un exemple similaire à la RTC : tu dois stocker des infos (quelques kb) sur une mémoire externe (sauf les cartes SD et consorts) : tu choisis une mémoire Flash ? Une nand ? une nor ? Ou alors une EEPROM ? Une NVSRAM ?
C'est ce qui me dérange dans ta vision : on sacrifie la réflexion sur l'autel de la simplicité.
Je comprend parfaitement que l'on ne peut pas être un expert en électronique, c'est tout à fait normal. Mais essayer de comprendre les principes de fonctionnement des composants, d'ouvrir les datasheets, se dire que l'on peut faire des choses de manières différentes, ca apporte du challenge, non ?
Essayer de comprendre le fonctionne d'un microcontrolleur pour en tirer toute la puissance possible c'est intéressant. C'est pareil pour le soft, je pense, penser optimisation dès le départ c'est quand même plus intéressant que de se lancer tête baisser dans un truc bourrin qu'il faudra optimiser après voire même réécrire.
C'est cet esprit de réflexion sur ce que l'on fait que j'essaie d'apporter. Sinon je peux toujours répondre par des trucs tout fait hyper bourrin, complètement fonctionnel. Mais sur certains problèmes poser ici, proposer de faire des liaisons vidéos sans fil avec des transmetteurs pour caméra professionnelles à 500$ et 1kg facile, qui consomme beaucoup, pour un petit drone, je crois que ca va pas le faire.
Je l'ai dit sur l'autre topic, je ne veux plus discuter du problème de la RTC. J'ai expliqué ma solution dans le détail (lire des datasheets, chercher des infos sur le net, etc.), ca m'a pris du temps et la seule réponse que tu apporte : "Une RTC c'est plus simple".
Enfin je ne suis pas contre la Raspberry Pi en elle-même, je suis contre l'utilisation que les gens en font : c'est un mini-ordinateur personnel. Or plein de personnes veulent faire des robots, des drones, etc. avec. Elle n'est pas la carte la plus adaptée.
Mais bordel, allez sur google, bing, yahoo ou autre moteur de recherche et allez vous renseigner sur les cartes existantes avant d'acheter une p**** de Raspberry.
Ne serait-ce qu'une BeagleBone Balck est 100 fois plus adaptée pour faire de l'électronique, des drones, des robots, etc. Alors, oui, elle ne permettra pas de lire des films, mais sérieux, vous allez utiliser votre robot en même que lui faire lire des films en 1080p ? Non...
Pareil pour les microcontroleurs, pour ceux qui veulent aller plus loins que l'Arduino mais veulent garder un peu de guidage, il y a le programme mbed qui propose des cartes de dév pas trop chère avec des ARM 32 bits (Cortex) et surtout un SDK commun à toutes ces cartes. De plus c'est du C donc ca permet de passertranquillement à la vitesse supérieure sans être trop dépaysé.
Mais bizarrement dès que l'on parle des autres solutions que Arduino et Raspberry Pi, plus personne n'écoute.
En conception professionnelle, les prix n'ont rien à voir à ceux affichés sur les sites. Les composants "chers" se négocient à plus de 4 ou 5 fois leur prix "public" (oui une boîte qui fait des équipements à gros volume, négocie des FPGA à 25$ à moins de 5$...).
Ca, je m'en doute
zeqL a écrit:
Dans le cas du post avec la RTC, oui 1 euros c'est rien (enfin pour moi je m'en fout), mais donc sous prétexte que 1€ c'est rien, on peut se permettre de l'acheter ? A partir de quel prix fixes-tu la limite ?
C'est fixé par mon porte monnaie Après c'est surtout une question de répartition de mes dépenses de loisir, plus je dépense pour l'électronique, moins j'ai d'argent pour d'autres activités
zeqL a écrit:
Quand je vois des posts où des personnes trouvent limite qu'une Arduino Uno ou une Raspberry Pi est trop chère mais d'autres (ou les même) vont dépenser presqu'une centaine d'euros dans des shields Arduino, plutôt inutiles à mon goût, comme tout ceux qui concernent le Wifi ou l'Ethernet...
Tu n'aimes vraiment pas tout ce qui est réseau Je trouve au contraire que c'est assez important
zeqL a écrit:
Pour revenir sur un exemple similaire à la RTC : tu dois stocker des infos (quelques kb) sur une mémoire externe (sauf les cartes SD et consorts) : tu choisis une mémoire Flash ? Une nand ? une nor ? Ou alors une EEPROM ? Une NVSRAM ?
C'est ce qui me dérange dans ta vision : on sacrifie la réflexion sur l'autel de la simplicité.
Si tu as une RPi, la question ne se pose pas, tu mets sur la SD.
C'est ce que tu ne comprends pas : je ne sacrifie pas la réflexion, je choisis sur quelles problématiques je dois passer plus de temps à réfléchir. Si j'ai une carte qui a le wifi et une carte SD, c'est 2 problématiques où je suis tranquille, je peux passer à d'autres choses.
zeqL a écrit:
Je comprend parfaitement que l'on ne peut pas être un expert en électronique, c'est tout à fait normal. Mais essayer de comprendre les principes de fonctionnement des composants, d'ouvrir les datasheets, se dire que l'on peut faire des choses de manières différentes, ca apporte du challenge, non ?
Essayer de comprendre le fonctionne d'un microcontrolleur pour en tirer toute la puissance possible c'est intéressant. C'est pareil pour le soft, je pense, penser optimisation dès le départ c'est quand même plus intéressant que de se lancer tête baisser dans un truc bourrin qu'il faudra optimiser après voire même réécrire.
Si tu allais sur le forum C++ de temps en temps, tu saurais que ma position est très claire : optimiser dès le départ, c'est une erreur (premature optimization is the root of all evil). Ce qui est primordiale avant tout, c'est la robustesse, l'évolutivité, la simplicité (KISS) du code, bref une bonne conception. Et le débutant qui me dit qu'il va aller lire le code source de la bibliothèque standard pour mieux maîtriser son fonctionnement, je lui dis qu'il fait une erreur : les classes proposent un interface, on doit s'intéresser aux contrats qu'elles proposent, pas à leur implémentations (boite noir). On remet en question l'implémentation quand on est beaucoup plus expérimenté.
Et je crois que c'est pareil pour l'électronique (en tout cas, selon ma conception des choses en tant que développeur). Si tu achètes le matériel parfaitement optimisé pour une application donné, la fois suivante où tu auras besoin d'une fonctionnalité en plus, tu devras mettre de côté le matériel que tu as déjà acheté et acheter autre chose (on parle bien de cartes, donc de prototypage ici).
Il me semble bien plus pertinent d'acheter du matériel un peu (ou beaucoup selon les moyens) surdimensionné et être tranquille. C'est beaucoup plus évolutif à terme.
zeqL a écrit:
Je l'ai dit sur l'autre topic, je ne veux plus discuter du problème de la RTC. J'ai expliqué ma solution dans le détail (lire des datasheets, chercher des infos sur le net, etc.), ca m'a pris du temps et la seule réponse que tu apporte : "Une RTC c'est plus simple".
Et pourtant. La simplicité est une qualité primordiale pour moi
zeqL a écrit:
Enfin je ne suis pas contre la Raspberry Pi en elle-même, je suis contre l'utilisation que les gens en font : c'est un mini-ordinateur personnel. Or plein de personnes veulent faire des robots, des drones, etc. avec. Elle n'est pas la carte la plus adaptée.
Mais bordel, allez sur google, bing, yahoo ou autre moteur de recherche et allez vous renseigner sur les cartes existantes avant d'acheter une p**** de Raspberry.
Ne serait-ce qu'une BeagleBone Balck est 100 fois plus adaptée pour faire de l'électronique, des drones, des robots, etc. Alors, oui, elle ne permettra pas de lire des films, mais sérieux, vous allez utiliser votre robot en même que lui faire lire des films en 1080p ? Non...
Pareil pour les microcontroleurs, pour ceux qui veulent aller plus loins que l'Arduino mais veulent garder un peu de guidage, il y a le programme mbed qui propose des cartes de dév pas trop chère avec des ARM 32 bits (Cortex) et surtout un SDK commun à toutes ces cartes. De plus c'est du C donc ca permet de passertranquillement à la vitesse supérieure sans être trop dépaysé.
Mais bizarrement dès que l'on parle des autres solutions que Arduino et Raspberry Pi, plus personne n'écoute.
Ca, je suis en partie d'accord. En relisant mon précédant message, je me suis dit qu'il était idiot de proposer la RPi + composant additionnels alors que c'est plus cher. Comme je l'ai dit dans d'autres discussion, la RPi possède des fonctionnalités (décodeur H264, input audio et vidéo, etc) qui n'ont aucun intérêt pour l'électronique. Dans ce sens, il est largement préférable de passer sur d'autres types de cartes (j'ai acheté ma RPi quand les autres n'existaient pas ou étaient peu développé).
J'avoue sans peine ne pas connaître les autres types de cartes et comme la RPi et Arduino remplissent tous mes besoins, je n'ai pas prévu d'en acheter d'autres. Donc il m'est difficile de les conseiller. Et je crois que c'est le problème de ce type de carte : peu de monde les connaissent.
Et c'est justement un critère important pour ne pas conseiller ces cartes (sans aller jusqu'à les déconseiller). L'un des points forts de toutes ces cartes de prototypage, c'est d'avoir une communauté importante, une très large publication sur le net et beaucoup de projet d'exemple faisable sur breadboard. (au point où la première chose que je fais quand j'ai un nouveau composant, c'est de taper "arduino mon_composant" sur google). Quelqu'un qui débuterait avec ces cartes pourraient rencontrer un problème de manque d'aide. Ou pas, je n'ai pas de recul sur ces cartes. En tout cas, je vois pas beaucoup de monde sur le forum qui vient dire "si, ces cartes sont super, manger en". Il faut mieux une RPi ou une Arduino, qui sont connu, qu'une carte mal connu
Un exemple concret : je n'ai pas cherché, mais saurais tu me donner des tutos en fr sur ces cartes ? Ils sont aussi complet que le tuto sur Arduino ? As tu pensé à créer ce genre de tuto ?
× 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.
Retrouvez moi sur mon blog et ma chaine Youtube !
Discord NaN. Mon site.
Retrouvez moi sur mon blog et ma chaine Youtube !
Discord NaN. Mon site.