Go Down

Topic: Arduino Due et DS1307 (Read 255 times) previous topic - next topic

pilou007

Salut,
Je viens de passer un programme Mega2560 sur un Due, et mon module DS1307 ne fonctionne plus. Toutes les librairies que je teste ne fonctionne pas, enfin les exemple m'écrive des caractères ascii sans doute au lieu d'un beau date & time...
Est-ce que quelqu'un connait ça??
Merci

fdufnews

Le DS1307 connecté comment?
Le DS1307 n'est pas compatible d'une alimentation 3,3V et la Due n'aime pas les signaux en 5V.
Si tu as 2 ou 3$ à dépenser, achète un DS3231. Il est plus précis, "cause" comme le DS1307 et il fonctionne en 3,3V.

dfgh


pilou007

Salut,
Merci poir vos réponses.
Alors c'est vrai qu'avec le DS1307, j'ai perdu une heure en 1 mois de temps, autant dire que c'est de la daube... je vais acheter uns DS3231, pour voir si c'est mieux.
En attendant, il faut que je fasse fonctionner mon DS1307, pour mon proto. Donc je vais essayer la librairie RTCDue, mais hier lors de mes tests, j'ai réussi à tout faire planter le Due, il m'a fallut l'après midi pour réussir à refaire fonctionner mon programme, lol... Même un simple hello world ne marchait plus, à un point que j'ai bien cru que le Due était HS...

Merci, je vous tiens au courant.

_pepe_

#4
Sep 12, 2017, 10:06 pm Last Edit: Sep 12, 2017, 10:07 pm by _pepe_
Alors c'est vrai qu'avec le DS1307, j'ai perdu une heure en 1 mois de temps, autant dire que c'est de la daube...
En fait, ce n'est pas vraiment le DS1307 mais les modules chinois qui le mettent en œuvre qui sont de grosses daubes.

Si la conception et la production de ces modules avaient été correctes, on aurait dû atteindre une précision similaire à celle d'une montre-bracelet classique dans des conditions d'utilisation normales.

ZigZag

C'est juste un module qui porte le nom d`un composant qui lui simple composant a déjà largement fait ses preuves et est très loin d'être de la daube.

Mais c'est un phénomène contemporain que de vouloir du pré digéré, comme ces petits modules qui fonctionnent sur arduino avec les bonnes bib telechargeables toutes prêtes. Presque du plug and play.

Et justement, quand cela ne play pas, le player, au lieu de chercher pourquoi, décrète que c'est de la daube.

Mais finalement, si daube il y a, on peut se demander de qui ou quoi elle vient.

Un mauvais composant, module, usage ou utilisateur ?

pilou007

Tu vois le truc, c'est que quand tu fais un proto, tu vas au plus vite et donc tu fais confiance à ce que tu trouves, mon proto, c'est pour mon boulot, alors pas trop le temps de remettre en question tous les moduels qu'on trouve dans le commerce...

Et oui, je fonctionne avec mon temps et le pré digéré, si t'as encore envie de réinventer la roue, c'est ton problème, mais te t'en prends pas aux gens qui on un mode de fonctionnement différent...

Tes jugements et réflexions, tu peux te les garder, ça ne fais pas avancer le post... Mais si au moins tu me donnais un schéma qui me permette de le mettre en oeuvre sans trop galérer et utilisable avec une lib toute faite, là, je te remercierai et là au moins tu serai d'une grande aide, sinon, abstiens toi, merci.

Si on industrialise, là on verra....

bilbo83

Bonjour,

J'utilise une DS3234 avec une DUE dans un environnement où la température varie de 13° minimum l'hiver à 40° maximum l'été.
En 20 mois de fonctionnement ininterrompu, elle avance de 6s.

pilou007

Salut,
Merci pour ta proposition. Je ne sais pas si ça fonctionne aussi sur un Raspberry, car je vais passer la dessus car même avec un Due, je n'ai pas obtenu le résultat escompter, donc j'arrête Arduino et passe sous Raspberry...

Tep, je viens de regarder, ça ira aussi sous RaspBerry... Bon comme j'ai commandé la 3231 hier soir, si ça ne passe pas, j'essayerai ton module.
merci

_pepe_

#9
Sep 13, 2017, 05:39 pm Last Edit: Sep 13, 2017, 06:15 pm by _pepe_
quand tu fais un proto, tu vas au plus vite et donc tu fais confiance à ce que tu trouves, mon proto, c'est pour mon boulot, alors pas trop le temps de remettre en question tous les moduels qu'on trouve dans le commerce...
Là, je me permets d'intervenir car le propos m'interpelle.

En principe (c'est-à-dire à moins que tu sois ton propre patron payé sur tes fonds propres, ou que ton patron accepte en connaissance de cause les risques que tu lui fais prendre), ton boulot devrait t'obliger à utiliser des produits parfaitement documentés et spécifiés par leurs fabricants. Les modules choisis devraient donc déjà répondre à tes besoins sur le papier bien avant de commencer le montage du premier prototype.

Si tu trouves aussi tardivement que tes modules à base de DS1307 sont de la daube c'est :

- soit parce que ces caractéristiques ayant été fournies (elles sont alors considérées comme contractuelles), tu as été trompé sur leur valeur réelle, auquel cas je t'invite à changer de fabricant ou de fournisseur (selon qui est responsable de ce problème ou de cette fraude) ;

- soit parce que tu n'avais pas d'indication sur les caractéristiques qui te sont nécessaires, auquel cas tu devrais remettre en cause ta méthode de travail et adopter une démarche plus professionnelle et conforme aux règles de l'art.


Bricoler, c'est bien pour découvrir, apprendre, s'amuser ou monter pour soi-même des bidules dont l'usage est sans conséquence. Et c'est d'ailleurs là que réside le cœur de cible du projet Arduino.

Mais professionnellement parlant (i.e. dans un environnement concurrentiel où la rentabilité et les conséquences financières de tout travail, y compris de R&D, sont pris en compte), la conception d'un produit n'est possible qu'après avoir pris connaissance de l'existence, des caractéristiques et des contraintes de mise en œuvre d'un nombre suffisant de solutions susceptibles de répondre aux besoins exprimés, puis les avoir évaluées et appris à les maîtriser. Il est parfaitement contreproductif de sauter sur les premières solutions apparentes venues pour les mettre immédiatement en application... et découvrir trop tard qu'en fait elles ne conviennent pas.

D'autre part, avant toute autre phase de développement pouvant entraîner des frais et/ou des délais, la conception d'un produit nécessite d'être complètement terminée puis validée du point de vue théorique, d'où l'importance du travail sur les spécifications. La phase de réalisation d'un prototype ne vient qu'après, et sert à valider matériellement le résultat afin de parer autant que faire se peut les éventuels oublis et erreurs dans les phases précédentes, dont la découverte tardive implique de revoir la conception, de la revalider puis de refaire un nouveau prototype.

Généralement, toute tentative pour prendre un raccourci dans cette démarche aboutit au mieux à une perte de temps et d'argent pour l'entreprise, au pire à la réalisation d'un produit peu fiable avec potentiellement des conséquences désastreuses durant son utilisation et/ou sa commercialisation. Et pour un ingénieur, c'est le plus souvent synonyme d'un licenciement sec, parfois même de poursuites au civil ou au pénal si ça se passe très mal.

Pour te donner un ordre de grandeur, s'agissant de la réalisation d'un appareil du type de celui que tu sembles développer (bridge RS485-RS232 avec enregistrement sur mémoire de masse) par chez moi le temps imparti à la recherche documentaire, la rédaction du cahier des charges, la conception fonctionnelle, la conception technique, l'organisation des tests, le codage et la réalisation d'un prototype utilisable ne dépasserait pas cinq homme×jour (et en ce qui me concerne, ce travail plus la gestion du projet correspondante me prendraient certainement moins de trois jour). Autant dire qu'une méthode de travail inadaptée entraînant des délais de développement beaucoup plus longs serait jugée inacceptable.


pilou007

#10
Sep 13, 2017, 11:18 pm Last Edit: Sep 13, 2017, 11:29 pm by pilou007
Et sérieux faut se détendre et ne pas en faire tout un plat....
Lorsque tu fait une recherche sur un module RTC, pour un proto et qui ne te sert qu'à horodater les fichiers, tout t'amène vers un module DS1307 ou autre de ce genre, alosr faire une recherche complète pour un proto ne me semble pas utile...
Maintenant, les régles de l'art sont tout a fait respecter sur une étude de preuve de concept ou proto... En plus comme tu dis, tu cherche un module RTC et toutes les doc te dises que tout va bien, il fonctionne à merveille et c'est quand tu le testes, dans la phase proto que tu t'apperçois que c'est pas bon, donc on change et on vérifie que le prochain sera mieux.... idem poir mon problème de RS 485, pas évident de deviner que le système avec Arduino ne fera pas l'affaire, d'ou le passage au DUE puis à raspberry...
Le passage à l'industrialisation c'est autre chose.

_pepe_

#11
Sep 14, 2017, 12:47 pm Last Edit: Sep 14, 2017, 12:49 pm by _pepe_
Je n'en fais pas tout un plat, j'essaye juste de te sensibiliser à la nécessité de recourir aux bonnes méthodes de travail, surtout si c'est dans un environnement professionnel car cela peut avoir une incidence sur ta carrière et/ou sur la qualité des produits et services fournis aux clients (dont je pourrais éventuellement faire partie un jour).

Ce que je constate, c'est que cela fait déjà plusieurs mois que tu poses des questions sur le forum tournant autour de ce type de sujet. Compte tenu du temps passé, tu aurais déjà dû te poser des questions sur l'efficacité et la pertinence de ta méthode d'investigation et de développement, surtout s'agissant de problèmes déjà connus, traités et documentés publiquement, et non pas de nouveaux sujets de recherche et d'innovation.

En principe, en partant de zéro et en utilisant seulement la documentation disponible, tu aurais pu te rendre compte qu'un Arduino AVR ne pourrait pas faire l'affaire dès la première journée. Encore eût-il fallu entreprendre la bonne démarche. Une remise en cause de ta méthode me semble donc appropriée.

Go Up