Go Down

Topic: Raspberry Pi en maître et arduino en esclave (Read 16627 times) previous topic - next topic

barbudor

Pas d'accord avec ta dernière réflexion.

Je suis à 100% sur l'idée qu'il est plus efficace de confier à un RPi tout ce qui est serveur Web, pourquoi pas mini serveur SQL, etc ...
Et de laisser tout ce qui est interface avec le hard et le temps-réel à un arduino.
A voir lequel est le co-pro duquel, ca dépend d'où on se place...

zoroastre

#16
Jun 25, 2012, 09:18 pm Last Edit: Jun 25, 2012, 09:32 pm by zoroastre Reason: 1
Yep!

Non non  XD

L'idée me plait beaucoup...sauf l'utilisation du SPI alors qu'il y a un jolie port série sur le Pi.

Je me suis juste focalisé sur une utilisation outrancièrement outrageuse du port SPI  :smiley-mr-green:

Pour ma part, je suis moyennement convaincu par le Pi, cela semble être une bonne machine mais il y en a tant et tant d'autre (Il suffit d'aller jeter un oeil chez mouser.com, j'acheterais plutôt çà  http://fr.mouser.com/ProductDetail/STMicroelectronics/STM32F4DISCOVERY/?qs=J2qbEwLrpCFMptdjNAVzZeZDfltJ6JKw1GLhrq7db5E= ) Merdum!!! Je me suis planté de lien  :.

@+

Zoroastre.
Gné! ;)

OLIVIERC67

#17
Jun 25, 2012, 09:32 pm Last Edit: Jun 25, 2012, 09:36 pm by OLIVIERC67 Reason: 1

Yep!

Non non  XD

L'idée me plait beaucoup...sauf l'utilisation du SPI alors qu'il y a un jolie port série sur le Pi.

Je me suis juste focalisé sur une utilisation outrancièrement outrageuse du port SPI  :smiley-mr-green:


Je reconnais que moi aussi. Je dois juste vérifier si les ports série de mes PC (tour, portable, et prochainement Rpi) supportent sans problème le débit plus élevé.

Je fais peut être fausse route, mais le "haut débit" n'est pas pour grande quantité de données, mais plutôt pour me rapprocher le plus possible du temps réel lors d'un évènement hard sur les pins par exemple.

Quote

Pour ma part, je suis moyennement convaincu par le Pi, cela semble être une bonne machine mais il y en a tant et tant d'autre (Il suffit d'aller jeter un oeil chez mouser.com, j'acheterais plutôt çà  http://fr.mouser.com/ProductDetail/STMicroelectronics/STM32F4DISCOVERY/?qs=J2qbEwLrpCFMptdjNAVzZeZDfltJ6JKw1GLhrq7db5E= )

@+

Zoroastre.


Si j'ai choisi le Rpi c'est avant tout parce qu'il tourne sur linux et que c'est l'OS que j'utilise chez moi. Il est flexible, consomme peu, contrôlable à distance, etc
Il a aussi les capacités pour héberger un serveur pour faire tourner un équivalent de ce qu'on trouve dans une blissbox ou autre système proprio cher.

Je constate que mes questions ne sont pas si idiotes que ça et me font avancer grâce à votre aide. Et j'espère un jour avoir suffisamment de connaissance pour donner un coup de mains.

barbudor

En attendant d'avoir un RPi, je regarde si je vais pas me prendre un TP-Link 703/MR3020 à hacker sous OpenWRT
- Wifi
- Ethernet
- 1 USB pour Arduino => En prenant un Atmega32U8/Leonardo pour simplifier

osaka

Yop Yop,
Comme Barbu et Zoro l'ont si bien dit, il n'y a pas que le débit dans qui compte dans la vie.  :smiley-mr-green:
Sinon pour le rôle de chacun, le rpi serais là évidement pour gérer les partie où l'arduino est limité (à chacun son travail et spécialités), interface (web, client lourd) et data (SQL, xml, etc).
Le gros avantage pour le rpi par rapport aux autres solutions à mon avis ce situe plus aux niveau du support de par sa popularité et communauté, c'est la raison principale du succès de l'arduino également je pense.

zoroastre

#20
Jun 25, 2012, 10:00 pm Last Edit: Jun 25, 2012, 10:24 pm by zoroastre Reason: 1
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 ;)
De plus, en tant que linuxien averti (je suis sous Debian Squeeze ;) ), tu sais avec quelle facilité tu peux maitriser ce fameux port série.

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

@+

Zoroastre.
Gné! ;)

OLIVIERC67

#21
Jun 25, 2012, 10:39 pm Last Edit: Jun 26, 2012, 07:33 am by OLIVIERC67 Reason: 1

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.

zoroastre

#22
Jun 25, 2012, 11:09 pm Last Edit: Jun 25, 2012, 11:39 pm by zoroastre Reason: 1
Yep!

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

Architecture : <arduino mega><usb 57600 bps><pc portable><hub ethernet 10 Mbits><router><Mon pc>

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  :smiley-mr-green: )

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 ;)

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.  :smiley-yell:

@+

Zoroastre.
Gné! ;)

OLIVIERC67

#23
Jun 26, 2012, 10:53 am Last Edit: Jun 26, 2012, 03:10 pm by OLIVIERC67 Reason: 1

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

barbudor

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.

Artouste

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

Go Up