RaspBerry PI, Arduino et I2C

Bonjour à tous,

Je donne quelques tuyeaux vis à vis de ces cartes electroniques suite à mes nombreux tests et lectures sur le sujet. du tout en un ! je completerait au fur et à mesure...

Il est possible de faire communiquer un RaspBerryPI avec un Arduino via le protocole I2C. Ce protocole permet en autre de disposer d'un maître qui pilote plusieurs esclaves et leur demande de fournir des valeurs (lecture par exemple). Les esclaves peuvent être un arduino, un PC, ou des composants de type mémoire, thermomètre, capteur de pression, etc.

Pour ma part j'utilise la librairie PI4J pour développer en Java sur le RaspBerry, l'IDE Eclipse en remote Debug, et un level shifter fait maison pour la communication RaspBerry<=>Arduino

Bon à savoir - RaspBerryPI / Arduino - Level Shifter obligatoire
les niveaux logiques de l'arduino sont du TTL (5V) et celui du RaspBerry du 3.3V.
Pour pouvoir faire communiquer les deux sans cramer le RaspBerry, il faut placer une convertisseur de niveau logique BIDIRECTIONNEL (contrairement au protocole SPI ou SERIAL). pour ceux qui disposent du mosfet 2N7000, un montage très simple et fonctionnel est disponible ici : http://husstechlabs.com/support/tutorials/...-level-shifter/. Testé en Simu, et validé à l'oscilloscope, il marche très bien pour des communications à 100KBit/s (I2C Standard)

Bon à Savoir - I2C/ARDUINO - Attention aux interruptions => Deadlock !
Lorsque vous utilisez le protocole I2C, et que vous rédigez le programme Arduino, ne faites jamais appelles à des fonctions utilisant des interrruptions lorsque vous êtes dans les routines onRequest ou onReceive => vous créerez un syndrome de DeadLock freezant l'Arduino ou le faisant mal fonctionner. Exemple : faire du DEBUG avec du Serial.Print dans la routine OnReceive ou OnRequest => plantage assuré...

Bon à Savoir - I2C/ARDUINO - N'utilisez pas la fonction Serial.print !
Cette facilité pour débugguer nécessite l'utilisation des interruptions pour envoyer les octets via le bus USB ou via les PIN RX/TX. Utiliser cette facilité avec la librairie Wire c'est potentiellement rencontrer des problèmes aléatoires (problème de reception, emission, deadlock dans les routines onReceive, etc.)

Bon à Savoir - I2C/ARDUINO - N'utilisez pas de DELAY !
La fonction delay entraîne des deadlocks lorsque'utilisée dans les routine OnReceive et onRequest

Bon à Savoir - ARDUINO - Eviter le plus possible les objets String
N'utilisez jamais les objets String ! en effet ceux ci nécessitent l'utilisation de calloc et malloc à outrance ce qui entraîne parfois des bugs d'allocation mémoire dans l'Arduino et fait déconner votre programme. A éviter le plus possible !

Bon à savoir - ARDUINO - Libérer la mémoire vive des Strings statiques
Si vous faites du Debug via le port Serie, placez toutes les écritures statiques entre double quote dans la fonction F(), ce qui permettra de forcer le stockage des strings statiques en flash plutôt qu'en RAM. (La RAM est cruciale pour l'arduino !)
Exemple code Arduino :

Bon à savoir - RaspBerryPI / PI4J - Eviter de perdre la main si les ecritures vers l'arduino sont trop "rapides"
L'utilisation de la librairie PI4J est super top moumoute mais parcontre cette librarie est très sensible au temps d'execution des instructions côté ARDUINO. Afin d'éviter de nombreux BUG côté RaspBerry (Erreur I2C sur Adresse 0xxx. Got -2001) pendant les tests unitaires "StressTest", j'ai du placer les ecritures sur le BUS dans des blocs try..Catch avec un Sleep de 500ms si j'avais une erreure. Celà a permis ainsi de résoudre les BUGS aléatoires de problèmes d'écritures depuis le RaspBerry vers L'arduino. Celà permet également de ne pas prévoir de sleep entre les écritures (comme j'ai pu le voir sur certains forum Arduino, où les gens mettent des SLEEP à tâtons [dans le noir ? ]ce qui ne contourne pas le problème de manière sûre).
Exemple code Java :

Bon à savoir - I2C - détection des trames sur le bus avec un oscillo
Si vous avez un oscilloscope et souhaitez visualiser les paquets de données (j'ai un RIGOL 1052E), il faut savoir que le BUS I2C fonctionne en idle à l'état haut, et en transmission à l'état bas (donc à l'envers). Il vous faudra donc configurer l'oscilloscope pour qu'il TRIG sur un front descendant pour une valeur inferieure à 5V (côté Arduino) ou 3.3V (côté RaspBerry).

Bon à savoir - ARDUINO - Envoyer un seul Write.write quand on répond au maître

En synthèse : Lors d'une réponse à un maître (Routine RequestEvent) n'utilisez qu'un seul Wire.write() pour éviter les problèmes. Si plus d'un octet doit être transmis, créez un tableau de Byte, stockez les valeurs, puis envoyez le tableau de byte directement

Bon à savoir - ARDUINO - Librairie alternative pour I2C
Une librairie alternative à Wire.h est disponible pour la partie maître uniquement sur ARDUINO. Elle corrige notamment les bugs intempestifs sur le bus I2C qui 'freeze' en certaines circonstances.

Bon à savoir - ARDUINO - Taille du buffer interne pour les transmission
Par défaut l'ARDUINO est configuré pour disposer d'un buffer interne de transmission de 32Octets. Ne pas envoyer plus de 32 Bytes donc sur le BUS sinon celà créera des problèmes.

Bon à savoir - I2C - Byte Arduino vs Byte Java [unsigned vs signed]
Si comme moi vous tentez de lire les valeurs analogiques de l'arduino (range de 0 à 1023), et que vous transmettez le résultat sous forme de 2 octets (donc 2 Bytes) alors vous aurez possiblement le même bug que moi à la réception du résultat côté Java (chez moi RaspBerryPI avec PI4J 1.0 pour gérer l'I2C).
J'ai essayé beaucoup d'astuces, la manipulation de bits, la transformation en int avec le décalage, le masque à 0xFF mais rien n'y fait : je perd toujours le bit de poid fort du premier octet car Java l'utilise pour signer le byte (en effet un byte Arduino est non signé, range de 0 à 255 contrairement au Java qui signe son byte, range de -128 à 127).
Afin de résoudre ce bug après quelques jours d'essais j'ai trouvé un contournement imparable et qui fonctionne à merveille, et toujours sur deux octets.

Côté code Arduino, voici à quoi celà ressemble :

En fait je transmet deux octets, le premier stocke la partie entiere de la division (AnalogValue/127). Le second stocke le modulo, c'est à dire le reste de la division.Ainsi pour une AnalogValue de 419, ou 0x1A3 en hexa, le premier octet aura une valeur de 3, et le second octet une valeur de 38.

Côté RaspBerryPI, sous Java avec PI4J :

Sur la reception des deux octets on reconvertit en multipliant le premier octet (ReadBuffer[0]) par 127 et en y rajoutant le second octet qui correspond au reste (modulo). Ainsi L'on retrouve bien la valeur initialement lue de l'arduino sans être embêté par Java qui s'amuse avec les bits de nos octets unsigned.

Ce message a été modifié par BlueDragon le Lundi 05 Août 2013 à 21h29

Bonsoir,

Merci pour toutes ces infos

Je bosses uniquement sur Arduino pour ma part, et j'ai pas mal de freezes dès que j'utilises des circuits de puissances, et çà bug encore + souvent avec un écran LCD sur I2C.
J'ai beau passer par un optocoupleur + transfo d'impulsions, avec donc deux isolations galvaniques et isolations séparées des alims, çà bug quand même...

J'ai trouvé sur ebay des sortes de clones des arduinos, OLIMEX c'est le nom de la boite je crois.
Ils sont soit disant améliorés et "noise immune", donc immunisés au bruits qui provoquent apparemment des plantages dès qu'on veut driver de la puissance.
Je sais pas trop si ils résoudront mes soucis mais bon, je vais tester et comparer les deux modèles pour voir.

C'est assez pénible car impossible d'utiliser des écrans I2C du coup, surtout que c'est bien plus pratique car cela ne bouffe pas de ports entrées sorties, et possibilité de multiplexage de capteurs et autre du coup.
Peut être que c'est lié au problème de Deadlock dont tu parles...

J'avais fini par commander et reçevoir mon oscillo : un Rigol 1052E
Je l'ai reçu il y a quelques jours mais pas eu le temps de bien le tester.
J'en ai besoin pour tenter de trouver une résonance avec le circuit que j'ai fais pour le système à la Stanley Meyer.
Il me servira pour bien d'autres choses de toutes façons
Tu as eu du temps pour bien tester le tien?
As tu des conseils peut être?

Cà tombe bien en tous cas, merci pour tout çà

Bonne soirée.

A+

Hello,

de ce que j'ai lu concernant Arduino, il faut que toutes les pins non utilisées soient mises à la masse pour éviter de faire déconner l'ATMega (une habitude visiblement à avoir avec des microcontrolleurs ).

Je l'écrit ici mais l'idée est celle là :

- Les concepteurs recommandent d'alimenter l'Arduino (UNO) avec le powerJack même si le port USB est branché sur le PC, car le port USB ne fournira pas assez de jus pour alimenter correctement l'ATMega + le pilotage par les PIN en mode OUTPUT.
- Si tu n'utilises pas le port USB (parceque en mode 'autonome' dirons-nous), alors il faut t'assurer que l'alim puisse fournir 1A (en fait la carte consomme de mémoire 300mA + 200MA max pour l'ensemble des PIN). Et attention ! c'est bien 200mA Max pour les PIN toutes confondues, au delà l'Arduino commence à déconner / Freezer
- La limite haute en sortie/entrée à respecter pour une PIN en mode output est de 40mA, et recommandée de 20mA environs. Donc sachant que le coeur ne peut fournir que du 200mA max avant de deconner celà fait 5 PIN à 40mA max
- Pour contourner la limite du courant et éviter de faire freezer l'arduino, il vaut mieux tirer le courant depuis la broche VIN (si elle correspond à du 5V par exemple) car c'est une broche reliée directement depuis l'alim (donc sans passer par le régulateur de tension interne de l'arduino).

=> A voir donc si tes freezes de sont pas dûs au fait que tu tire trop d’ampérage sur le cœur de l'arduino (tu t'approche ou dépasse les 200mA pour toutes tes pins par exemple)
=> Alimentes-tu l'arduino via le powerJack ou seulement l'USB ? (l'alimentation via l'USB peut poser problème)
=> pour les Bugs ou freeze, utilises tu l'objet String ? si c'est le cas, ceci peut expliquer des problèmes intempestifs à cause des dépassement de zone mémoire
=> As-tu bien relié toutes les PIN non utilisées à la masse en les passant en mode INPUT_PULLUP ?
=> Utilises tu la librairie Serial et la librairie Wire dans le même Sketch ? Si oui, chez moi celà pose des problèmes aléatoire
=> Quand tu compiles ton sketch dans l'IDE, tu es à combien de % utilisé de RAM ? (indiqué sur la ligne du type Binary sketch size: 3 102 bytes (of a 32 256 byte maximum) - 9% used)

Concernant l'oscilloscope, vois-tu je penses qu'on a le même niveau : je viens de le recevoir et je comprends les fonctions de base. Le truc sympas c'est l'enregistrement des bitmaps et CSV sur une clef USB en FAT32. A et vérifies bien que tes sondes sont bien compensées (voir le manuel, si besoin demande moi).

Voilou c'est tout ^_^
Pour ma part ça fait 2 semaines que je bosse sur l'I2C entre le RaspBerryPI et l'Arduino, et je peux te dire que c'est pas une mince affaire ! j'ai dû réviser 3 fois l'ensemble de mon Sketches pour tout debugguer et le stabiliser. Franchement, je trouve que ce protocole est vraiment limite ! mais c'est sûrement parceque je ne sais pas l'utiliser (en même temps y a pas 36 possibilités sur le bus, donc on peut pas dire que ce soit très compliqué....)
Mon plus gros soucis actuellement avec I2C c'est.....le temps.... et ça, ça marche pas très bien entre le RaspBerryPI et l'Arduino : si l'arduino (l'esclave) met trop de temps à répondre, ça bug ou ça renvoie pas une bonne valeur. d'ou ma refonte trois fois du code pour optimiser les temps de traitements CPU.
Bref, Arduino super top, RaspBerry super top, mais alors I2C.... c'est franchement un peu galère entre un RaspBerry (Maître) et un Arduino (Esclave)

Genial ce rapsberry ! Je ne connaissait pas ...Merci les Gars !!

SG

Oui il est super, et tu peux gérer les PIN du GPIO grâce à la librairie WiringPI (https://projects.drogon.net/raspberry-pi/wiringpi/) en langage C ou via le framework PI4J qui est une abstraction Java de WiringPI http://pi4j.com/ (et basé sur WiringPI).

En somme le RaspBerry est plus puissant et dispose de plus de RAM que l'arduino (model B contient 512Mo de RAM).
Je conseille l'utilisation de la distribution RASPBIAN pour le RaspBerry (celà m'a permis d'installer entre autre Apache, Mysql, RaspControl, phpMyAdmin, le JDK 8 EA) pour mon projet.
Il peut servir également de media center qui lit très bien les Divx MKV et x264 (1080p supporté). Pour le prix faut pas s'en priver , la distribution à installer dans ce cas là est OpenElec (voir http://openelec.tv/forum/124-raspberry-pi).

Alors pourquoi s'embeter avec un Arduino alors que RaspBerry fait (presque) pareil grâce à la librairie WiringPI ? Ben tout simplement parceque son architecture n'est pas orientée microcontrôleur mais application. Laissons tout ce qui est gestion logique aux Microcontrolleurs et gestion applicatif aux processeurs applicatifs.

En gros : Le RaspBerry le cerveau (programmation, base de données, serveur de présentation HTTP) et l'Arduino les mains (Microcontrolleur), et l'électronique les doigts des mains

A bientôt !

Bonjour,

Voici quelques tests que j'ai mené sur la communication entre le RaspBerry et l'arduino. On peut voir des echec de lecture (je reçoit 0 alors que je devrais recevoir un 1) et le nombre d'attente (l'attente est enclenchée lorsque le RaspBerry n'arrive plus à écrire sur le bus I2C et provoque une Exception).

Je fais une loop de 10 execution qui englobe 5000 execution des instructions suivantes (RPI pour Rasbpberry et ARD pour arduino) :

RPI vers ARD : Ecrire 3 Octets (ecriture registre, allumer PIN 8 )
RPI vers ARD : Ecrire 3 Octets (ecriture registre, demande lecture PIN 8 )
RPI vers ARD : Demande à lire 1 Octet
RPI vers ARD : Ecrire 3 Octets (ecriture registre, Eteindre PIN 8 )
RPI vers ARD : Ecrire 3 Octets (ecriture registre, demande lecture PIN 8 )
RPI vers ARD : Demande à lire 1 Octet

Le BUS I2C est en 100K.
Note importante : il n'y a aucune attente entre les instructions, l'attente est engagée uniquement lorsqu'il y a un problème d'écriture de la part du RaspBerry.
Note : ce n'est pas 20.000 ecritures/lectures mais 20.000 ecritures et 10.000 lectures)

===Temps d'attente : 2000 millisecondes, TWBR=12 (400K)
Execution de 20.000 ecritures/lectures en 26057 Millisecondes
Nombre echec lecture : 3 | Nb Attente : 7
Execution de 20.000 ecritures/lectures en 37994 Millisecondes
Nombre echec lecture : 4 | Nb Attente : 13
Execution de 20.000 ecritures/lectures en 56036 Millisecondes
Nombre echec lecture : 15 | Nb Attente : 22
Execution de 20.000 ecritures/lectures en 40003 Millisecondes
Nombre echec lecture : 6 | Nb Attente : 14
Execution de 20.000 ecritures/lectures en 58016 Millisecondes
Nombre echec lecture : 10 | Nb Attente : 23
Execution de 20.000 ecritures/lectures en 41836 Millisecondes
Nombre echec lecture : 8 | Nb Attente : 15
Execution de 20.000 ecritures/lectures en 35791 Millisecondes
Nombre echec lecture : 3 | Nb Attente : 12
Execution de 20.000 ecritures/lectures en 33784 Millisecondes
Nombre echec lecture : 3 | Nb Attente : 11
Execution de 20.000 ecritures/lectures en 49801 Millisecondes
Nombre echec lecture : 12 | Nb Attente : 19
Execution de 20.000 ecritures/lectures en 29780 Millisecondes
Nombre echec lecture : 4 | Nb Attente : 9

===Temps d'attente : 200 millisecondes, TWBR=12 (400K)
Execution de 20.000 ecritures/lectures en 15062 Millisecondes
Nombre echec lecture : 6 | Nb Attente : 15
Execution de 20.000 ecritures/lectures en 15419 Millisecondes
Nombre echec lecture : 8 | Nb Attente : 17
Execution de 20.000 ecritures/lectures en 16852 Millisecondes
Nombre echec lecture : 12 | Nb Attente : 24
Execution de 20.000 ecritures/lectures en 15210 Millisecondes
Nombre echec lecture : 5 | Nb Attente : 16
Execution de 20.000 ecritures/lectures en 15396 Millisecondes
Nombre echec lecture : 10 | Nb Attente : 17
Execution de 20.000 ecritures/lectures en 14825 Millisecondes
Nombre echec lecture : 7 | Nb Attente : 15
Execution de 20.000 ecritures/lectures en 14179 Millisecondes
Nombre echec lecture : 4 | Nb Attente : 12
Execution de 20.000 ecritures/lectures en 13965 Millisecondes
Nombre echec lecture : 5 | Nb Attente : 11
Execution de 20.000 ecritures/lectures en 14784 Millisecondes
Nombre echec lecture : 7 | Nb Attente : 15
Execution de 20.000 ecritures/lectures en 15179 Millisecondes
Nombre echec lecture : 4 | Nb Attente : 17

===Temps d'attente : 100 millisecondes, TWBR=12 (400K)
Execution de 20.000 ecritures/lectures en 13046 Millisecondes
Nombre echec lecture : 9 | Nb Attente : 19
Execution de 20.000 ecritures/lectures en 13299 Millisecondes
Nombre echec lecture : 19 | Nb Attente : 28
Execution de 20.000 ecritures/lectures en 13078 Millisecondes
Nombre echec lecture : 13 | Nb Attente : 23
Execution de 20.000 ecritures/lectures en 12452 Millisecondes
Nombre echec lecture : 8 | Nb Attente : 12
Execution de 20.000 ecritures/lectures en 12497 Millisecondes
Nombre echec lecture : 6 | Nb Attente : 13
Execution de 20.000 ecritures/lectures en 12249 Millisecondes
Nombre echec lecture : 3 | Nb Attente : 8
Execution de 20.000 ecritures/lectures en 12602 Millisecondes
Nombre echec lecture : 7 | Nb Attente : 15
Execution de 20.000 ecritures/lectures en 12553 Millisecondes
Nombre echec lecture : 9 | Nb Attente : 14
Execution de 20.000 ecritures/lectures en 12857 Millisecondes
Nombre echec lecture : 10 | Nb Attente : 20
Execution de 20.000 ecritures/lectures en 12439 Millisecondes
Nombre echec lecture : 5 | Nb Attente : 12

===Temps d'attente : 20 millisecondes, TWBR=12 (400K)
Execution de 20.000 ecritures/lectures en 12444 Millisecondes
Nombre echec lecture : 8 | Nb Attente : 19
Execution de 20.000 ecritures/lectures en 12326 Millisecondes
Nombre echec lecture : 7 | Nb Attente : 17
Execution de 20.000 ecritures/lectures en 12349 Millisecondes
Nombre echec lecture : 10 | Nb Attente : 16
Execution de 20.000 ecritures/lectures en 12360 Millisecondes
Nombre echec lecture : 6 | Nb Attente : 19
Exception : java.io.IOException: Error writing to /dev/i2c-1 at address 0x3. Got -20001.



Reexecution du protocole avec 100ms d'attente lorsque une exception io.IOException apparait
===Temps d'attente : 100 millisecondes, TWBR=12 (400K)
Execution de 20.000 ecritures/lectures en 12879 Millisecondes
Nombre echec lecture : 14 | Nb Attente : 19
Execution de 20.000 ecritures/lectures en 12422 Millisecondes
Nombre echec lecture : 3 | Nb Attente : 11
Execution de 20.000 ecritures/lectures en 12773 Millisecondes
Nombre echec lecture : 10 | Nb Attente : 17
Execution de 20.000 ecritures/lectures en 12678 Millisecondes
Nombre echec lecture : 10 | Nb Attente : 16
Execution de 20.000 ecritures/lectures en 12786 Millisecondes
Nombre echec lecture : 8 | Nb Attente : 18
Execution de 20.000 ecritures/lectures en 12160 Millisecondes
Nombre echec lecture : 6 | Nb Attente : 9
Execution de 20.000 ecritures/lectures en 12113 Millisecondes
Nombre echec lecture : 4 | Nb Attente : 9
Execution de 20.000 ecritures/lectures en 12486 Millisecondes
Nombre echec lecture : 12 | Nb Attente : 16
Execution de 20.000 ecritures/lectures en 12891 Millisecondes
Nombre echec lecture : 15 | Nb Attente : 24
Execution de 20.000 ecritures/lectures en 12484 Millisecondes
Nombre echec lecture : 7 | Nb Attente : 16

On peut donc voir qu'une ecriture massive (ie : trop rapide) implique une saturation du bus I2C (raison inconnue, repérée par le nb d'attente) et des problèmes de synchronisation entre le RaspBerry et l'Arduino (repéré par l'echec du nombre de lecture).

Je tenterai de rajouter un delais entre les instructions pour voir si j'ai toujours des echecs de lectures. Pour infos, une erreur de lecture peut survenir à la 30ième instruction, comme à la 1700ième, il s'agit donc d'un BUG aléatoire (du à mon convertisseur logique ? je n'y crois pas j'ai vérifié l'état des signaux).

Edit du 05/08/2013 :
L'ajout de la ligne
TWBR = 12; //BUS I2C à 400Khz
En dessous de Wire.Begin() semble stabiliser les bugs aléatoires sans toutefois les supprimer.

Ce message a été modifié par BlueDragon le Lundi 05 Août 2013 à 21h32

Modification du premier post pour y rajouter le transfert de la valeur analogique de l'arduino via le bus Wire. Problème contourné : les bytes arduino sont non signés contrairement aux bytes Java, qui eux le sont.

Bonjour,

Merci encore pour tout çà

Je passes par des drivers pour la partie puissance, et çà bug uniquement quand je branche l'alim de puissance, qui est isolée galvaniquement de toute la partie commande.
Toute la partie commande avec l'écran fonctionne nikel jusqu'au branchement de cette autre alim.
Du coup c'est plutôt à cause d'un parasite, mais je comprends pas qu'il remonte jusqu'à là.

Les pullup c'est pour une mise au +5V, pas à la masse
Mais merci pour çà, j'avais même pas vu qu'on pouvait le faire, je mettais des résistances partout quand j'en avais besoin...
Ralala j'en apprend tous les jours avec ces arduinos
Je vais suivre tes conseils et activer cette fonction sur toutes les broches non utilisées.

Super pour le raspberry, je m'en suis commandé un aussi pour voir ce que çà vaut.
Il parait que c'est super aussi pour faire un boitier lecteur multimédia réseau avec une faible conso.

Pour son alimentation je passes direct par sa broche d'entrée, avec régulateur 8 ou 9V en amont pour limiter la chauffe de celui intégré.
Avec bien sur des condos de lissages

Je penses que j'utilises le wire et serial en même temps oui, c'est super pratique le serial, mais je peux tenter de le virer temporairement.
Ce qui est bizarre c'est que c'est juste en branchant la puissance que çà bug.
Je n'ai pas regardé le reste des infos, je verrais ce week end si j'ai un peu de temps.

Pour l'oscillo je le trouves merdique si on utilise pas les sondes.
Les signaux partent dans tous les sens même sans brancher de géné en entrée, juste avec les fils.
Donc je dirais que les sondes sont obligatoires, ce qui est un peu dommage mais bon.
Sinon il me plait bien
Je n'ai pas besoin d'une grande précision, je vais surtout m'en servir pour vérifier des signaux numériques, et voir si la tension augmente ou diminue, donc pas de mesure analogique précise

Pour ma part j'aimes pas trop l'I2C, je préfères le SPI.
Cela demande + de broches si on a beaucoup d'appareils c'est sur, mais certains circuits n'ont pas d'adresse réglable, du coup on peut en mettre qu'un en I2C...
Les liaisons séries de l'arduino mega sont super, çà permet de bosser en asynchrone grâce au buffers, comme çà pas d'interruptions.
Apres c'est au choix de chacun , en + je ne connais pas tout dans l'arduino bien sur donc bon, j'apprend de + en + au fil du temps

Merci encore pour tout çà

A+ bonne aprem !