Raspberry Pi en maître et arduino en esclave

Bonjour

Je débute avec arduino et je m'éclate bien avec même si malheureusement je n'ai que très peu de temps à y consacrer.
J'en suis encore à faire des blingbling sur mes LCD. Pas encore eu le temps de tester le shield ethernet + SD, ni le SPI, I2C.

Peut on utiliser le Rpi en maître et utiliser le arduino (mega2560 par exemple) que pour les I/O en mode esclave ? Je sais que c'est possible avec la console USB, mais il faut interpréter ce qui passe pas la console et le débit n'est pas aussi important que en PSI/i2c
L'idéale étant que le Rpi gère directement les pins. Mais je sais pas si c'est possible et si c'est aussi facile que ça à mettre en place.

Je sais pas si je suis assez clair.

L’intérêt est de profiter de la "puissance et flexibilité" du Rpi et des I/O du mega2560.
Le Rpi :

  • serveur web facile à mettre en place sur un OS sécurisé
  • programmation en python ou autre langage
  • SSH
  • Multitâche
  • supervision de plusieurs arduino.
  • Pas de limitation en matière de mémoire
  • Pas plus cher puisqu'on économise sur le shield ethernet, RTC, etc
  • gère l'audiovisuel (stream, enregistrement, etc)

Le arduino :

  • remonte les états des entrée et applique les consigne du Rpi sur les sorties
  • Peut être programmé pour gérer des consignes prioritaires sur certains I/O en cas de défaillance du Rpi

Voilà.

Merci et bon week end.

Yop Yop,
C'est tout à fais possible et c'est ce que je compte faire, mais bon en espérant avoir une dispo sans latence et dans l'année ... :grin:

Ça rejoint ce poste ci http://arduino.cc/forum/index.php/topic,111191.0.html

osaka:
Yop Yop,
C'est tout à fais possible et c'est ce que je compte faire, mais bon en espérant avoir une dispo sans latence et dans l'année ... :grin:

Ça rejoint ce poste ci http://arduino.cc/forum/index.php/topic,111191.0.html

Toi tu passes par l'usb ?
Moi j'aimerai éviter le serial à cause du débit.
L'idéal étant le SPI, il me semble que c'est freq/2, soit environ 8000000 pour le 16mhz du mega2560

A moins qu'il y ai des inconvénients auxquels je n'ai pas pensé.

OLIVIERC67:
Toi tu passes par l'usb ?
Moi j'aimerai éviter le serial à cause du débit.
L'idéal étant le SPI, il me semble que c'est freq/2, soit environ 8000000 pour le 16mhz du mega2560

A moins qu'il y ai des inconvénients auxquels je n'ai pas pensé.

Oui je passe par usb/serie pour l'instant a partir d'un ordinateur "classique", le raspberry étant pourvu d'un port serie je ne devrais pas passer par l'usb intermédiaire ...
Maintenant concernant les débits tout dépend du type et de la taille des données à échanger, par exemple moi ce serait des trame de données binaire de maximum 32 octet grand grand maximum.
Ça dépend également du traitement à effectuer derrière, par exemple si tu transmets un packet de 200 octet de type chaine de caractères sur spi et que ça te prend 10 millis sec et que moi j'envoie un packet de 10 octet de données binaires pour un même but sur port serie et que j’atteins également 10 millis sec ou même le double 20 millis seconde, la différence ce verra plus sur le traitement à effectuer après que sur le débit des différents moyen de transport des données ...
Donc il faut voir si on a réellement besoin d'un débit important selon la taille des données (au plus elle sera courte au moin il y aura une différence entre les deux), a t'il réellement un impact si au final c'est le traitement des données qui accapare le temps et les ressources, ...

salut
pour votre info voir : RPi Low-level peripherals - eLinux.org

A+
chabot380

chabot380:
salut
pour votre info voir : RPi Low-level peripherals - eLinux.org

A+
chabot380

Je vais commander le Rpi et me baser sur ton lien ainsi que des tuto concernant les arduino communicant en SPI en maitre-esclave :
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1294596127

Un article intéressant sur l'utilisation conjointe d'un RPi et d'une Arduino

barbudor:
Un article intéressant sur l'utilisation conjointe d'un RPi et d'une Arduino
Raspberry Pi avec Node.js et Arduino - Doc’ Alex

intéressant mais utilise l USB.

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

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

La liaison série, c'est bien quand on a pas de GPIO à disposition sur l'un des 2 appareils.

Sinon, c'est jouable en SPI (RPi<->Arduino) en adaptant un truc comme ça ?
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1294596127

Pourquoi pas.
Mais l'article fait référence au framework Node.js qui sait interagir avec une liaison série (ou une liaison série virtuelle sur USB).
Interfacer Node.js (ou n'importe quel serveur web) avec une liaison SPI sera plus difficile.
Idem avec Apache+PHP, il y a des modules PHP-Serial qui permettront de discuter avec l'Arduino au niveau série, que ce soit une vrai série ou une série virtuelle sur USB.

Pourquoi ne pas utiliser l'USB ?
Bon d'accord il faut mettre un hub parce que le RPi n'en a qu'une mais c'est un moindre mal.

barbudor:
Pourquoi pas.
Mais l'article fait référence au framework Node.js qui sait interagir avec une liaison série (ou une liaison série virtuelle sur USB).
Interfacer Node.js (ou n'importe quel serveur web) avec une liaison SPI sera plus difficile.
Idem avec Apache+PHP, il y a des modules PHP-Serial qui permettront de discuter avec l'Arduino au niveau série, que ce soit une vrai série ou une série virtuelle sur USB.

Pourquoi ne pas utiliser l'USB ?
Bon d'accord il faut mettre un hub parce que le RPi n'en a qu'une mais c'est un moindre mal.

Le débit full-duplex plus important par rapport au série donc réactivitée plus importante.
En SPI, la possibilité d'avoir beaucoup plus de slave avec le Rpi (ou arduino).

Les inconvenants existent, mais on peut les contourner :

  • Pas d'adressage -> se compense par la mise en place de chaîne ayant un pseudo adressage. Ex : "SLAVE1@PIN1=ON@PIN2=OFF"
  • Pas d’acquittement -> Le slave retourne une chaîne avec les status. Ex "SLAVE1@PIN1=ON@PIN2=ON" <- Problème sur PIN2.

Bon, je suis loin de tout maîtriser, il y a probablement des choses qui m'échappent et je fais fausse route.

Yep!

Le plus simple reste l'utilisation de l'UART.

A savoir, que le datasheet du 328 (page 203) précise qu'avec un oscillateur à 16 Mhz on peut atteindre 1 Mbps ou 2 Mbps (U2Xn à 0 ou 1). La limite de transfert asynchrone sur bus série n'est donc pas limité à 115.2 Kbps comme on pourrait le croire.
Il faudra en l'occurence gérer les marges d'erreur au plus le vitesse de transfert augmente (tableau du datasheet)

115.2 Kbps ~= 78 µS/byte

Serial.begin(1000000); :wink:

@+

Zoroastre.

EDIT1 : Le gros inconvénient du SPI est que beaucoup de shield utilise ce protocole pour communiquer avec l'arduino, ainsi, si tu persistes sur le SPI, tu tues en quelques sortes ce qui fait l'essence du Wiring et par conséquent la modularité de ton arduino...Du moins, c'est un avis perso :grin:

De plus le débit pur ne sert à rien si le processeur doit passer tout son temps à transférer les données.
Compte tenu du temps de monté en interruption, on va prendre facilement 20% de la puissance CPU pour çà à 115kbps
Un SPI à 2 Mbps c'est un octet toute les 5µs. Le micro est donc pris à pratiquement 100%.
Ca va pour gérer un burst mais pas pour des données continues.

C'est pourquoi sur les micro un peu évolué qui utilisent des liaisons rapides (les DSP par exemple) il y a des contrôleurs de DMA (Direct Memory Access) qui effectuent les transfert des données en arrière plan sans perturber (ou peu) l'exécution du programme.

Yep!

C'est sur, le processeur va souffrir. En plus, de ce point de vue là, le cahier des charges est pauvres : Quel est le volume de données à transiter ??? Le rapport vitesse/débit est-il critique ???

Pour faire tourner, un UART à 1 Mbps faut un prescaler de /2 :: En théorie, le µC est chargé à 50% par la communication série, et on sait tous que cette valeur est illusoire, cela va bien au dela...

Que l'on décide de booster son débit à 200 ou 300 Kbps, je dis ok. Au delà, comme l'a si bien remarqué Barbudor, ce type de communication rapide n'est pas trop fait pour nos arduino.

Perso, aucun gain dans cette reflexion qui courre ici...

@+

Zoroastre.

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...

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 :grin:

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.

zoroastre:
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 :grin:

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.

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.

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

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. :grin:
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.