j'envisage un circuit avec un arduino nano et une série de capteurs (lumière température, peut-être d'autres) qui devrait idéalement tourner H24, faire des mesures et les envoyer via usb à un raspberry.
Je me pose la question de la fiabilité à long terme (jours/mois... années ?) d'un tel dispositif... côté arduino (pour le RPi, j'ai des solutions)
Est-ce que je peux y aller sans souci, fiabilité assurée les yeux fermé ?
Est-ce qu'il y a des précautions à prendre niveau code et alors lesquels ?
Est-ce que je me fout le doigt dans l'œil et il faut que je prévois un plantage régulier de mon arduino/capteurs et une solution pour rattraper le problème (mais lequel)
Merci de vos avis
edit : dans les bidouilles envisageable, un reboot complet programmé du RPi est possible.
Bon sans tergiverser, si le code est robuste et que le materiel est correctement dimensionné, un montage Arduino peut durer longtemps. Et pour correctement dimensionné, il ne s'agit pas de mettre une resistance de telle ou telle valeur parce qu'on l'as vu marcher une fois sur une video. La valeur de chaque composant se calcule
Là j'ai les poils qui se dressent, si le code est bien pensé et bien écrit, un reboot programmé ne doit jamais être une option. C'est faire un pansement sur un tas de pus. Si le programme plante au point d'avoir à faire un reboot, c'est qu'il y a un bug et du coup il faut débugger.
A la conception, il faut envisager tout les cas de figure possible et les défaillances probables. Bien plus facile à dire qu'à faire, j'en conviens.
Désolé pour ta pilosité, j'ai évoqué ça parce que j'avais commis cette hérésie avec un RPi + Apache qui bizarrement plantait au bout d'une 30aine de jours d'uptime. Un reboot par cron tous les 15j avait réglé le pb (jamais élucidé d'ailleurs). Mais c'est crade, c'est vrai...
Certains te diront qu'une distance de 3m est tout à fait acceptable pour de l'I2C.
Pour ma part je dirais oui, à condition de pouvoir câbler tout ça de manière extrêmement fiable, car un bus I2C rompu peut occasionner des temps de réponse importants, voire infinis si la librairie ne prévoit pas de timeout.
la gaine prévue, les emplacements imposés font que le cheminement passe à côté de la moitié des circuits électriques et info de la maison. Le risque de perturbations EM n'est pas (estimation au doigt mouillé) négligeable (bon tous les câbles info sont en cat6a double blindage)
Cela dit, je ne sais pas non plus comment va réagir un câble USB dans les même conditions
Dans ce cas là, tu mets un Arduino (Arduino pro micro, mini, voir même un ATTiny) par capteur et tu utilises une interface RS485 pour échanger entre les capteurs et le RasPi.
Comme ça, si un capteur flanche, il ne plante pas les autres.
Son interface différentielle rend le bus RS485 relativement immune aux perturbations .
En électronique la fiabilité décroit avec la complexité des circuits donc plus c'est simple plus la fiabilité sera élevée pour autant que les composants soient bien choisis évidemment. Donc les petites cartes Arduino les plus minimalistes, sans liaison USB feront très bien l'affaire.
Il y a quelque chose que je ne comprends pas : pourquoi il n'est jamais proposé de baisser la fréquence de l'horloge I2C ?
C'est prévu dans la bibliothèque Wire, c'est juste que la fonction est mal foutue et qu'il faut demander une fréquence que le micro est capable de fournir => consultation de la datasheet obligatoire => mon dieu quelle horreur !
Parlons technique :
Qu'est-ce qui empêche l'I2C de fonctionner : la capacité sur la ligne qui écroule les fronts des signaux.
Si les fronts sont écroulés, les systèmes logiques du micro n'arrivent plus à retrouver leurs petits.
Le seul conseil que l'on trouve est de diminuer la valeur de la résistance de charge pour accélérer la charge des capacités et donc redresser les fronts.
Sauf s'il y a des notions impérieuses de rapidité, quelle est la différence fonctionnelle entre diviser par deux le front de montée en divisant par deux la résistance équivalente de l'I2C ou doubler la période en passant la fréquence de 100 kHz à 50 kHz ?
J'ai vu plusieurs fois la valeur de 10 kHz en valeur minimale
Il est vrai qu'une norme a tendance à normaliser afin d'éviter trop de n'importe quoi, n'importe comment. La fréquence obligatoire est 100 k, la fréquence recommandée est 400k. Mais cela va jusqu'à 5 MHz en mode NON bidirectionnel.
Contrairement au vénérable protocole RS232, où émetteur et récepteur doivent chacun avoir une fréquence d'horloge bien connue et précise, dans l'I2C et le SPI c'est le maitre qui fourni l'horloge aux esclaves ce qui laisse plus de marge de manœuvre.
Le travail du CI esclave est de synchroniser les signaux entrant sur sa propre horloge interne => ça dans le métier, ils savent faire.
Il est vrai que je n'ai jamais tenté le 10 kHz, toutefois je ne vois pas ce qui pourrait empêcher le fonctionnement.
Cela mériterait d'être vérifié, je l'accorde, mais comme tu vas le voir, j'ai fait fonctionner de l'I2C en dehors des fréquences "conseillées"
J'ai plutôt regardé dans l'autre sens et j'ai pu constater que deux nanos pouvaient communiquer (l'une maître, l'autre esclave) jusqu'à environ 560 kHz/1 m de distance (je n'ai plus la valeur exacte en tête, il faut reprendre le calcul d'après la datasheet).
Avec des registres 8 bits la première valeur supérieure suivante était à plus de 800 kHz et là cela ne fonctionnait plus.
afin d'éviter trop de n'importe quoi, n'importe comment. La fréquence obligatoire est 100 k, la fréquence recommandée est 400k. Mais cela va jusqu'à 5 MHz en mode NON bidirectionnel.