Discussion :

[electroremy]

Bonjour,

Le titre de mon sujet peut faire peur mais ça n'a rien de compliqué

J'ai un serveur Arduino qui communique avec des clients Arduino en TCP/IP grâce aux shield Ethernet

Tout cela fonctionne très bien, les clients ont un écran tactile TFT et se comportent comme des "terminaux" vis à vis du serveur.

les client possèdent quelques broches I/O libres, et j'ai prévu dans mon serveur la possibilité de les lire et de les écrire.

Cela permet de "câbler" des capteurs sur les clients, de cette façon le serveur à accès à des capteurs déportés à proximité de chaque client.

Le but final de ce système est de créer un réseau domotique :
- le serveur est la "centrale"
- les clients sont des "interfaces homme machine" ; il y a un client dans chaque pièce de la maison

Avoir des capteurs sur les clients permet, par exemple, au serveur de mesurer la température dans chaque pièce.

Pour le moment, je ne fait que des opérations "directes" de lecture analogique des broches.

J'ai commencé à utiliser des capteurs I2C.
C'est mieux et cela permet de faire plus de choses.
Et justement, les broches I2C sont celles qui sont "libres" sur mes clients.

D'ou mon idée de permettre à mon serveur de lire des capteurs I2C branchés sur les clients.

Là, c'est un petit plus compliqué...
... en effet, chaque capteur I2C utilise I2C d'une façon différente, et en pratique, il faut, en plus d'inclure "wire.h", inclure une bibliothèque spécifique au capteur.

Je n'ai pas envie de faire comme ça.

Je souhaite que mes clients restent "des terminaux universels" et qu'ils soient capables de communiquer de façon universelle avec tout périphérique I2C, le code spécifique au périphérique I2C étant géré par le serveur.

En effet, j'ai réussit à avoir, pour la gestion de l'écran TFT, cet aspect "terminal universel", concrètement cela veut dire que pour modifier l'application domotique, je n'ai juste qu'à modifier le code du serveur, je n'ai pas besoin de modifier le code des clients.
Pour résumer, on peut dire que mes clients sont en quelque sorte des écrans TFT tactiles avec interface Ethernet.
C'est ce principe et cette philosophie qui fait tout l'intérêt de mon système et je souhaite le mettre en oeuvre pour la lecture de capteurs I2C.

Cela vous semble-t-il possible ?

Mon idée est d'ajouter dans mon protocole d'échange client/serveur des "instructions I2C" maison, exactement comme mes "instructions" d'affichages et de lecture de la dalle tactile

Par exemple, le serveur dit au client dans sa réponse
"demande au périphérique I2C avec l'adresse ZZ de faire XX"
ensuite le client le fait
puis enfin le client refait une requête au serveur avec dans sa requête les données envoyées par le capteur.

D'ailleurs rien ne m'empêche de mettre autre chose que des capteurs I2C, tout périphérique I2C pourrait être piloté.

Cela répond à une autre problématique : la limite la distance des connections entre les capteurs I2C et le serveur.

A bientôt

[f-leb]

Salut,

Le titre de mon sujet peut faire peur mais ça n'a rien de compliqué

Ils disent tous ça

C'est un peu comme dans un terminal I2C (realterm par exemple)...

Par exemple avec la commande S4241P, S= Start et P=Stop
A l'adresse 0x42, envoi de la commande 0x41 (opération Write)

Avec S4241R02P : adresse 0x42, envoi de la commande 0x41, réclamer 2 octets en retour

etc.
voir https://os.mbed.com/users/4180_1/not...-for-realterm/

[electroremy]

Ils disent tous ça

C'était pour vous préparer psychologiquement

Il y a un an, quand je débutais en Arduino et que j'ai expliqué mon projet domitique client/serveur avec écrans tactiles, beaucoup doutaient de la faisabilité.
J'ai tout de même réussi à atteindre et même à dépasser ce que je voulais faire.
Certes les Arduinos sont exploités à fond mais justement c'est ça qui est bien, il n'y a pas de gâchis.

voir https://os.mbed.com/users/4180_1/not...-for-realterm/

Ca correspond un peu à ce que j'aimerais faire

Je me rends compte que j'ai peut être pas posé la bonne question...

Mon idée fonctionnera bien avec les dispositifs I2C qui dialoguent avec un seul "aller-retour", typiquement la réception d'une salve de commande et la réception d'un bloc de données

En revanche, si le dispositif I2C a besoin de beaucoup d'échanges (plein de cycles lectures / écriture) ça sera plus difficile

Mon idée tiens la route si le serveur peut fait une demande uniquement et le client renvoyer toutes les données.

Cependant, il est toujours possible pour moi de prévoir dans mon code que le serveur demande "une salve" de commandes

Mon expérience en I2C se limite à :
- la mise et à l'heure et la lecture d'un RTC
- la lecture d'un capteur Adafruit température et humidité

A bientôt

[Delias]

Bonjour Rémy

L'I2C est relativement simple et devrait permettre cela. Les problèmes seront au niveau du timing, mais pour la majorité des modules cela devrait fonctionner car l'écriture ou la lecture sont bloquante dans le code et il n'y a aucune obligation de temps entre deux accès consécutifs.
En effet une communication I2C c'est uniquement l'envoi d'une adresse (de 7 bits + un bit R/W), puis l'écriture ou "exclusif" la lecture d'un certain nombre d'octets. C'est le comportement du signal de clk qui va marquer la fin d'une transmission. Et cela justifie le format de message indiqué par F-Leb

Au niveau Arduino, il doit être possible de dériver la bibliothèque wire pour qu'elle envoie les requêtes par Ethernet vers un autre Arduino. Idéalement il faudrait dériver d'une interface, sauf que là j'ai bien peur qu'il faille hériter de la classe wire. (Je ne suis, et de loin, pas un spécialiste sur ce domaine, à voir si d'autres peuvent mieux clarifier cela).

Sur les esclaves il faut un code qui reçoit et exécute les demandes provenant du maître et qui va utiliser wire pour la communication sur les esclaves. Là c'est le projet que F-Leb a indiqué qui peut faire l'affaire si tu utilises ce format.

Par contre le maître va vite saturer en RAM et Flash nécessaire, surtout si tu commences à aligner les modules esclaves. Un AVR a peu de ressource.

Bonnes recherches

Delias

[electroremy]

Merci pour ces précisions

Par contre le maître va vite saturer en RAM et Flash nécessaire, surtout si tu commences à aligner les modules esclaves. Un AVR a peu de ressource.

Je ne suis pas trop inquiet par rapport à ça.

De façon très paradoxale, dans mon système domotique, le serveur qui gère de nombreux clients Arduino mais aussi des clients "HTML" classiques (navigateurs web) utilise bien moins de RAM que les clients Arduino qui gèrent l'afficheur TFT.

La raison est la suivante : les requêtes sont traitées "au fil de l'eau" les unes après les autres.

La seule chose qu'on doit conserver en RAM en permanence pour chaque client c'est son état interne, typiquement une ou deux variables indiquant dans quel "menu" il se trouve pour la navigation. Il faut aussi stocker son adresse IP (juste le dernier octet, car c'est du réseau local). Cela fait 2 à 3 octets de RAM par client.

Cela veut dire qu'on a à stocker en RAM que les données correspondant au client qu'on est en train de traiter.
Hormis l'état interne, tout est effacé lorsqu'on passe au client suivant.
Les données persistantes que doivent mémoriser le client sont dans la mémoire du client, pas du serveur.

En fait, c'est pareil avec internet et les "vrais" serveurs web.
Un serveur web qui héberge un site web classique (HTML / CSS) va juste envoyer au fil de l'eau à chaque client les données qu'il demande, sans avoir besoin de conserver en mémoire beaucoup d'informations pour chaque client.

De plus, j'utilise les buffers du W5500 qui font 2ko en émission et 2ko en réception pour chaque Socket. Le W5500 a ainsi au total 32ko de RAM, 16 fois plus que l'Arduino UNO

Concrètement je lis les données au fil de l'eau dans le buffer sans avoir besoin de stocker toute la requête en RAM.
Pour l'écriture, je fais des write par paquets, et je demande au W5500 de tout envoyer ensuite.
Cela évite d'avoir un gros buffer en RAM pour stocker l'intégralité du contenu des requêtes et des réponses.

Pour I2C, là aussi, je ne lirais les capteurs que les uns après les autres, au fil de l'eau.

De toutes façon l'Arduino n'est pas multitâche et c'est un avantage.

Pour être universel, chaque client devra juste être capable de faire les opérations de lecture et d'écriture I2C, sans avoir besoin de savoir à quoi ça correspond.

C'est le serveur qui va interpréter les données.
Le serveur aura le code d'interpretation des données en fonction de l'application à laquelle il est destiné.
Le serveur peut potentiellement utiliser n'importe quel périphérique I2C mais en pratique on va se limiter à ceux requis pour l'application.

A bientôt

[Jay M]

En revanche, si le dispositif I2C a besoin de beaucoup d'échanges (plein de cycles lectures / écriture) ça sera plus difficile

le protocole I2C est très bien défini par une succession des états logiques possibles sur SDA et SCL, et la façon dont doivent réagir les circuits en cas de conflit

Par exemple, pour prendre le contrôle du bus, il faut que celui-ci soit au repos ( SDA et SCL à 'HIGH').
Pour transmettre des données sur le bus, on surveille:
- La condition de départ: SDA passe à 'GND' alors que SCL reste à 'HIGH'
- La condition d'arrêt: SDA passe à 'HIGH' alors que SCL reste à 'HIGH'

Lorsqu'un circuit prend le contrôle du bus (après avoir vérifié que le bus était libre) il est le maître et c'est lui qui génère le signal d'horloge.

De la même manière, la transmission d'un octet, d'une adresse, la gestion des conflits (plusieurs maîtres, gestion de la prise de parole simultanée) tout cela est bien défini.


vous pourriez donc avoir un bout de code sur les terminaux qui d'un côté offre une interface IP au serveur et traduit cela en devenant maître du bus et effectuant la communication nécessaire. Vous pourriez éventuellement utiliser les Wire.beginTransmission() et Wire.endTransmission() pour encapsuler une communication et passer false à endTransmission() pour rester maître du bus si d'aventure il y avait plusieurs paquets à échanger.

[electroremy]

le protocole I2C est très bien défini par une succession des états logiques possibles sur SDA et SCL, et la façon dont doivent réagir les circuits en cas de conflit

Je n'avais pas vu ta réponse

Je vais éplucher / éclater la bibliothèque wire.h, ce sera plus simple.
De plus, l'Arduino a du hardware spécifique I2C ce qui devrait rendre les choses plus simples.

Vous pourriez éventuellement utiliser les Wire.beginTransmission() et Wire.endTransmission() pour encapsuler une communication et passer false à endTransmission() pour rester maître du bus si d'aventure il y avait plusieurs paquets à échanger.

Le plus simple c'est de faire en sorte que tous les échanges soient faits en une fois.

Concrètement :

- le serveur fait un "ping" au client pour demander au client de lui faire une requête
- le serveur demande dans la réponse HTTP une opération I2C au client
- le client va faire exécuter toutes les étapes de cette "opération" I2C en une fois
- le client envoi une nouvelle requête au serveur avec en paramètre les données I2C lues

J'en saurais plus en expérimentant

Petite question : quels sont les capteurs / équipements I2C les plus "populaires" ?

Histoire que je regardes ce qu'ils échangent comme données pour avoir une idée des besoins.

A bientôt

[Jay M]

Pas de souci!

Petite question : quels sont les capteurs / équipements I2C les plus "populaires" ?

ce qu'on voit le plus souvent:
- capteurs divers (T°, humidité, courant, tension, gaz, pression, eau, lumière, poussière, couleur, touch, ..)
- convertisseur (ADC/DAC)
- IMU 3,6,9 axes (Gyroscope, Accéléromètre, Magnétomètre, ...)
- expansion de ports ou expansion mémoire

EDIT: Vous trouverez une liste de composants courants ici (enfin les adresses I2C de ces composants).

Le plus simple c'est de faire en sorte que tous les échanges soient faits en une fois

OK faudra peu-être jongler un peu car la bibliothèque Wire a un buffer de 32 octets donc c'est tout ce qui est couramment traité dans une transaction et parfois il y a donc nécessité de faire plusieurs transactions

[electroremy]

Bonjour,

Je pense que mon idée n'aboutira pas, car certains capteurs demandent :
- une initialisation
- une calibration, avec des timings à respecter
- de vérifier un status avant de continuer ou de lire les données

Bref la complexité rend difficile voire impossible la création d'un protocole universel qui ne soit pas lourdingue.

Example ici : https://www.developpez.net/forums/d2.../#post11705861

Après ce n'est pas trop grave, mon interface a déjà un capteur de lumière pour gérer le rétroéclairage, je vais lui ajouter d'office un capteur température et hygrométrie, c'est déjà suffisant pour de la domotique et il restera encore une entrée analogique de libre.

A bientôt