Raspberry Pi en maître et arduino en esclave

Yep!

Une erreur souvent commune est de penser que l'arduino doit absolument envoyer quelque chose quelque part. Tu peux trés bien demander au Pi de solliciter ton µC pour qu'il lui envoie les bonnes infos au bon moment.

Il y a plusieurs solutions à ton problème :

  1. L'arduino envoie tout
    a) Soit tout en même temps, on remplie le buffer.
    b) Soit une mesure à la fois, buffer plus vite remplis plus vite vidé.

  2. Le Pi sollicite le µC
    a) Je suis à la page 1, j'ai besoin "tout de suite" de x, y et z avec un rafraichissement de 5 ms.
    b) Je suis à la page 2, envoies moi toutes les infos à jour que tu as en stock.

etc...

C'est à titre d'exemple, une manière de solliciter soit l'un soit l'autre (avec des avantages et des inconvenients dans tous les cas). Cela dépendra essentiellement de l'IHM ou de comment tu veux que tes valeurs apparaissent.

Mais l'un comme l'autre, tu auras forcement une latence à gérer quel que soit la vitesse de transfert ou la manière dont tu remplis les buffers, c'est inhérent à tout sytsème, même ceux soit disant "temps réel".

C'est d'ailleurs, ces raisons qui me font penser que ton cahier des charges est assez pauvres pour l'instant et que tu es encore dans la théorie. Autrement, le port série est suffisant, dispo et non bloquant :wink:
De plus, en tant que linuxien averti (je suis sous Debian Squeeze :wink: ), tu sais avec quelle facilité tu peux maitriser ce fameux port série.

Alors GO ! GO ! GO ! Raspberry Pi + arduino + UART XD

@+

Zoroastre.

zoroastre:
Yep!

Une erreur souvent commune est de penser que l'arduino doit absolument envoyer quelque chose quelque part. Tu peux trés bien demander au Pi de solliciter ton µC pour qu'il lui envoie les bonnes infos au bon moment.

Il y a plusieurs solutions à ton problème :

  1. L'arduino envoie tout
    a) Soit tout en même temps, on remplie le buffer.
    b) Soit une mesure à la fois, buffer plus vite remplis plus vite vidé.

  2. Le Pi sollicite le µC
    a) Je suis à la page 1, j'ai besoin "tout de suite" de x, y et z avec un rafraichissement de 5 ms.
    b) Je suis à la page 2, envoies moi toutes les infos à jour que tu as en stock.

etc...

Disons que dans l'ideal, le mega2560 ne gère que le hard en tant qu'esclave :

  • I/O
  • serial
  • alarme principale
    et le soft par le Rpi (ou PC portable, ou matos openwrt telque ma neufbox4) en tant que maître :
  • que doit faire l'arduino en fonction des scénarios
  • alarme secondaire
  • gestion réseau
  • interface web
  • stockage des log, données
  • courbes
  • possibilité de clickodrome IHM (domogik par exemple) pour une vue de la maison et des objets actif (volets/vannes qui s'ouvrent ou ferment, lumières allumées, etc)
    -...

L'avantage est que l'arduino est facile à maintenir et leger. Qu'il ne doit être reflasher que s'il y a un bug à corriger, ou modification de l'installation (I<->O, ToR<->PWM,..), moins de shield (ethernet, RTC,..)

Le Rpi est facilement modifiable et ne nécessite pas de reboot suite à modification.

Et surtout, le Rpi, peut être programmé dans n'importe quel langage et multitâche. Le C/C++ étant un peu indigeste pour moi

Édit : linux avec le rpi permet d'utiliser les conteneurs linux (openvz, lcd). l'avantage est d'isolerla partie serveurs web et la gestion des i/o. Il y a aussi les quotas pour la prioriser un conteneur par rapport à l'autre. Ca permet aussi de cloner un conteneur pour le modifier/tester tout en gardant l'original en fonction et de basculer sur le nouveau quand tout est ok.

Yep!

A titre d'exemple, prenons quelque chose de concret.

Architecture : <usb 57600 bps><hub ethernet 10 Mbits>

J'ai développé une application python+Qt pour gérer une partie de mon installation domotique.

Sur cette image, un évenement indique à l'arduino qu'il y a un client et que les informations relatives à la page 2 sont demandées. La trame est donc limitée à 10 élements.

Sur celle-ci, un nouvel évenement demande des informations sur la configuration actuelle. La trame comprend 7 élements (cadre de droite).
Si j'ai besoin de modifier un paramètre, je n'envoie que les modifications et complète le reste de la trame avec un caractère qui sera ignoré par l'arduino.

De cette manière, j'ai relativement optimisé le traitement des envoies/réception. D'ailleurs, tant qu'il n'y a pas de client, aucune information ne transite sur le port série (57600 bps) hors une série de logs à un intervalle de 10 mn (pour des graphs et debuggage).

L'ecran d'acceuil

Il faudra donc penser aux fréquences et rafraichissement des données ainsi que des capteurs afin que les cartes soient sollicitée en toute productivité.

Il est clair que dans l'exemple précité, il est tout à fait possible d'optimiser les rafraichissements (tt les 10 secondes) et l'envoi des logs (tt les 10 mn). Mais pour mon application, j'avais jugé que cela était satisfaisant à l'époque (2010/2011).
(Si je me rappèle bien, mes sondes de température se rafraichissent tt les minutes :grin: )

Pour les logs : (24*60)/10 = 144 logs / jour (çà fait déjà une bonne base de donnée)
etc...

Aujourd'hui, j'envisage de réércrire complètement mon programme avec une api beaucoup plus performante, python ayant été le choix de la facilité, je m'oriente de plus en plus vers le c++ (Je suis en train de potasser la SDL)

Comme le titre du sujet l'indique, l'arduino est un esclave au service du Pi et en l'occurence, un esclave est toujours assujetie à son maître.

N'ayant qu'une relative connaissance du php (du moins dans l'écriture), je ne sais pas et je présume qu'il est possible d'invoquer des évenements "reveillant" l'arduino aux besoins. Sinon, quelques scripts bien placés feront allégrement le travail :wink:

Aprés, il est tout à fait possible d'envoyer les trames en continu, cependant, il faudra déterminer une plage de fonctionnement acceptable entre l'arduino et ses traitements, la sérialisation et le traitement php+sql de Pi.

Temps réel = impossible, 1 ms = trés peu probable, 10 ms = peu réaliste, 100 ms pourquoi pas, 500 ms confortable, etc. :stuck_out_tongue_closed_eyes:

@+

Zoroastre.

barbudor:
Oui pour la connexion entre RPi et Arduino. Et le principe peut être utilisé avec la liaison série.

Comment éviter le reset de arduino quand on établi une liaison serial ?
Parce qu'en production, ça va pas le faire

Sur une Arduino classique (2009, Uno, ...) utilisant un chip FTDI ou un ATmega pour faire l'interface USB, le reset est fait une une capa entre la broche DTR de la liaison série et le reset de l'Arduino.

  1. Si tu fait un produit, tu ne vas pas utiliser un RPi et une Arduino retail. Tu fais un produit avec son propre schémas. Donc tu ne met pas cette capa.

  2. En prototypage, certaines cartes permettent de désactiver cette capa. Sinon tu la dessoudes.

  3. Pourquoi est-ce un problème ? Au moment ou tu établis la connexion avec l'Arduino tu garantie ainsi que l'Arduino démarre proprement. Normalement cela n'arrive qu'une fois au démarrage de l'appli coté RPi.

bonjour
Comme de toute façons , il faudra bien un jour ou l'autre jouer avec un Rpi :grin:
j'ai passé une resa chez RS pour un modele B , ça arrivera... quand ça arrivera 8)