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
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, ...
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.
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);
@+
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
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.
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...
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...
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
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.
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.
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.
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.