Projet domotique

[.:!SEB!:.]

Bonjour à tous,

Je lance ce sujet qui risque d'être assez long pour vous présenter et avoir vos conseils concernant mon projet de domotique.
Pour rentrer directement dans le vif du sujet, j'envisage de me créer un système domotique. Je pars sur une logique centralisée avec un maximum d'éléments regroupés dans le tableau électrique (donc mise en boitier et fixation sur rail DIN) et des liaisons filaires (sauf quelques rares cas exceptionnels). Le système devra être en mesure de piloter l'éclairage (tous les luminaires seront dimmables), les volets roulants, les radiateurs avec fil pilote, le cumulus, le système hi-fi / vidéo, l'alarme et d'autres qui viendront par la suite. Il servira également de station de mesure et devra notamment acquérir les informations de température, d'humidité, et de luminosité de chaque pièce. Il effectuera aussi diverses mesures de consommation d'énergie.

Le but serait donc de commencer par créer un module "maître" qui superviserait l'ensemble de l'installation (et donc les modules esclaves).
Pour celui-ci je comptais à la base partir sur un microcontrôleur, mais étant donné mes attentes, j'ai bien peur qu'il ne suffise pas. C'est pourquoi j'envisage à présent plus une solution basée Linux. Le maître devra en effet disposer / gérer les éléments suivants:
- quelques entrées (~6) / sorties (~4) TOR
- un port ethernet pour la liaison au réseau (local pour commencer)
- serveur web embarqué pour la supervision
- bus de communication vers les modules esclaves dans le tableau
- bus de communication vers les modules esclaves distribués dans le logement
- communication téléinformation avec le compteur EDF

Les modules "esclaves" quand à eux seront des "extensions" d'entrées sorties disposés en tableau également (rail DIN). Ils seront chacun basé sur un microcontrôleur qui assurera la liaison entre les E/S et le bus de communication. Ils auront, entre autres, les fonctions suivantes:
- modules d'entrées TOR supplémentaires
- modules de sorties TOR supplémentaires (relais)
- modules de sorties dimmées supplémentaires (12V et 230V)
- entrées analogiques supplémentaires (PT100, 4-20mA, 0-1A (pour les mesures d'énergie)


Donc, je vais à présent me concentrer sur le module maître.
Je compte le baser sur une Raspberry PI 3 couplée à une carte homemade pour le module d'alimentation et la gestion des éléments environnants.
Mon premier blocage apparaît sur le choix des bus de communication à employer.

Pour la communication à l'intérieur même tu tableau électrique, j'avais pensé à un bus I²C qui se prête assez bien à mes besoins et est facile à mettre en oeuvre, que ce soit coté soft avec du code simple, ou coté hard avec très peu de composants supplémentaires requis (et donc un gain de place!! ). En revanche, chaque module disposera d'un bornier à vis pour le cablage du bus. Le cable de bus va donc se promener dans le tableau électrique de module en module. Et j'ai peur de l'I²C soit trop sensible aux perturbations électromagnétiques des courants forts environnants. Quelqu'un pour m'éclaircir sur ce point svp?

Pour la communication distribuée (modules externes au tableau élec se trouvant dans le logement, ex: sondes d'humidité, de température, interrupteurs communicants, etc.) c'est encore plus problématique étant donné les longues distances à parcourir. L'idéal serait que je ne soit pas contraint de câbler tous mes éléments en série ou en étoile mais que je puisse faire comme je veux. Bien sûr, ça, c'est dans l'idéal (à moins que qqn me trouve une solution ! ). Je par donc pour le moment sur le fait que je câblerai tout en série. Je cherche à présent quel type de bus utiliser, car là par contre, je suis un peu dans le flou... Voici mes "contraintes":
- grandes longueurs de bus (>150m)
- nombre de fils minimum (2 en tout serait le top, sinon je pensais à 2 fils d'alimentation (5 ou 12V) + 2 fils de données)
- facile à mettre en oeuvre (principalement au niveau du circuit électronique qui doit être le plus réduit possible, mais également au niveau de la programmation (je veux utiliser un microcontôleur pour les modules déportés, pas un XEON E7 ! )
- le plus fiable possible
J'envisage une base RS485 qui permet de grandes longueurs de cable, bien que nécessitant le mise en place de composants supplémentaires. Je serai bien parti sur des protocoles plus "industriels" tels que du Modbus ou du CAN, mais il est vrai qu'utiliser un vrai protocole domotique (knx par exemple) serait plus fun Je suis donc preneur de tout avis sur la question
La communication radio est dores et déjà prévue en enOcean et/ou Z-Wave

Merci à tous ceux qui suivront ce projet

Je suis en train de travailler sur un synoptique de mon installation depuis quelques jours, je vous le ferai parvenir ça dès que c'est prêt

Bonne journée
-----

[PIXEL]

je ne vois que du CPL dans ce cas , je ne parle pas du CPL informatique , bien sur. bien trop performant
pour cette application, mais plutôt d'un truc genre X10

[.:!SEB!:.]

Bonjour PIXEL, et merci pour ta réponse.
J'étais en effet au courant de l'existence du X10, mais ne souhaite pas partir dessus. Je voudrais que toute la partie "commande/data" soit sur du courant faible. En effet, si je coupe une prise pilotée depuis le tableau électrique, le X10 raccordé dessus ne fonctionnera plus. De même lorsque je vais dimmer mon éclairage.
Le principe étant de centraliser un maximum de commandes dans le tableau électrique, seuls quelques irréductibles équipements seront déportés Et il s'agira bien souvent de capteurs environnementaux ou modules d'entrée (boutons poussoirs, potentiomètres, etc.) qui n'auront donc aucun intérêt à être alimentés en 230V.
De plus l'utilisation du X10 nécessite quelques composants relativement volumineux, ce qui sort donc de mes contraintes :/

Merci en tout cas pour cette proposition, et je reste ouvert aux autres

[bobflux]

La lecture du site de Bigonoff et son projet DomoCan me semblent incontournables.

https://www.abcelectronique.com/bigo....php?par=f089a

Cependant, et malheureusement, la majorité du travail (de titan) effectué par Bigonoff présentent quelques ... inconvénients.

- La plupart des cartes utilisent des PIC16/18, le tout codé en ... pur assembleur ... et non en C, donc obligation d'apprendre l'asm d'une architecture obsolète...
- Le soft PC n'est pas portable : au début c'était du VB6, maintenant du C#, peut-être que ça tournerait sur mono ? Si ça oblige à utiliser un PC Windows comme centrale, alors aucun intérêt pour moi.

Donc, à toi de voir. Si je devais faire un système comme ça :

- J'utiliserais un bus CAN, qui s'impose quasiment comme une évidence (robustesse, transmission longue distance, etc)
- J'utiliserais le plus possible de DomoCan (Protocole de Bigonoff, son soft, etc)
- Je changerais uniquement les trucs que j'ai envie de changer.

Par exemple, pour développer des cartes sur bus CAN, tu as un LPC11C24 pour 3,50€ (par 10 chez mouser, 3,93€ l'unité) qui intègre le transceiver CAN, un Cortex-M0 50 MHz, 32k de flash et 8k de RAM plus un tas de périphériques, super facile à programmer en C/C++, debuggable dans le circuit en live, etc.

En gros, tu rajoutes un quartz, un LDO et quelques capas et tu as un noeud CAN pour une poignée d'euros, avec des tonnes d'IO, PWM, etc.

[A voir en vidéo sur Futura]

[PIXEL]

Bonjour PIXEL, et merci pour ta réponse.
J'étais en effet au courant de l'existence du X10, mais ne souhaite pas partir dessus. Je voudrais que toute la partie "commande/data" soit sur du courant faible. En effet, si je coupe une prise pilotée depuis le tableau électrique, le X10 raccordé dessus ne fonctionnera plus. De même lorsque je vais dimmer mon éclairage.
Le principe étant de centraliser un maximum de commandes dans le tableau électrique, seuls quelques irréductibles équipements seront déportés Et il s'agira bien souvent de capteurs environnementaux ou modules d'entrée (boutons poussoirs, potentiomètres, etc.) qui n'auront donc aucun intérêt à être alimentés en 230V.
De plus l'utilisation du X10 nécessite quelques composants relativement volumineux, ce qui sort donc de mes contraintes :/

Merci en tout cas pour cette proposition, et je reste ouvert aux autres

ça fait donc un double câblage !

[.:!SEB!:.]

Merci Bobfuck (haha! vive le pseudo ! ) très interressant. Il confirme bien ma thèse du CAN qui est assez solide et simple à mettre en oeuvre. Je vais finir de feuilleter la "doc" de Bigonoff et vous fais un retour. Il y a en effet de fortes chances pour que je parte là dessus, mais suis toujours ouvert aux autres idées.
En effet, je comptais utiliser de micro de type PIC programmés en C pour ces jolis petit modules

PIXEL, ca ne fait pas de double câblage étant donné qu'il s'agit de modules "autonomes", qui servent uniquement à l'acquisition de données ambiantes (température, luminosité, bouton poussoir, etc.) Il n'y a donc que le bus qui vient sur ces modules ils n'ont besoin d'aucun autre câblage (réseau 230V). Je pense que j'ai pas du bien décrire le système au départ, je me dépèche de finir le schéma pour vous éclaircir tout ca

[bobflux]

En effet, tu peux aussi mettre une alim dans le câble avec le bus CAN pour alimenter tes modules.

Pour ne pas trop perdre à cause de la chute de tension dans les petits fils de ton cếble, suivant le courant consommé, un petit +24V avec un DC-DC (acheté tout fait) dans le module pour convertir en 5V...

[.:!SEB!:.]

En effet Bobfuck, c'est bien ce que je comptais faire.
Je vais tirer un câble 2 paires blindées en 0.6mm². Une paire servant pour les datas, l'autre pour l'alimentation.
En revanche, je voyais plus l'alimentation en 12V car j'aurai une bonne alim 12V qui m'alimentera également de l'éclairage et certains autres éléments. Chaque départ 12V sera bien entendu protégé comme il se doit
Tous les modules disposeront donc d'un petit convertisseur 12V->5V (ou 3,3V, à voir...).

[bobflux]

OK parfait.
Tu mets quoi comme protection ? Des polyswitch ?

[.:!SEB!:.]

Je compte en effet équiper chaque appareil de polyswitch PTC. Mais en plus de ça, une protection générale protégera les départs éclairage, alarme, centrale domotique, équipements déportés, etc. J'utiliserai pour ça des disjoncteurs électroniques (des Murr Elektronik pour ne pas les citer, car j'en ai quelques un en stock ^^).

[Bigonoff]

Salut
-----
Je passe par hasard (ça fait 4 ans que je ne suis pas venu sur ce forum).
Je me permets de vous apporter mon point de vue, vu qu'on parle de Domocan (que je connais bien, LOL).
Si mon intervention vous fatigue, n'en tenez pas compte

Je pars sur une logique centralisée avec un maximum d'éléments regroupés dans le tableau électrique (donc mise en boitier et fixation sur rail DIN) et des liaisons filaires

Attention de ne pas confondre "centralisée" avec "localisée".

- La différence entre centralisé et décentralisé c'est que dans le premier cas l'intelligence du système se trouve localisée dans un seul logiciel tournant en général sur une seule carte, les autres cartes n'étant que des périphériques obéissant à la centrale, alors que dans le second chaque carte dispose de fonctions "intelligentes" et peuvent communiquer directement entre elles sans passer par une centrale. Domocan est décentralisé en mode natif.

- La différence entre localisé et délocalisé, c'est que dans le premier cas toutes les cartes se trouvent en un même lieu et dans le second on place les cartes au plus près de l'endroit d'application.

On peut donc avoir un système centralisé localisé, centralisé délocalisé, décentralisé localisé et décentralisé délocalisé.
Au niveau de la localisation, Domocan autorise les deux: Ainsi, chez moi, les cartes gradateurs sont au niveau de l'armoire électrique alors que les cartes à touches sensitives sont évidemment aux endroits des touches sensitives (blochets dans chaque pièce). Au niveau de la centralisation, Domocan autorise également les deux, le mode est commutable. Cependant, j'attire ton attention sur le fait qu'il est plus simple (beaucoup plus simple) d'écrire des logiciels pour le mode centralisé que pour le mode décentralisé: Inutile donc de se casser inutilement la tête si c'est pour ajouter des cartes qui ne fonctionnent qu'en mode centralisé, et donc inutile d'implémenter toutes les fonctionnalités Domocan. Évidemment le principal inconvénient de la centralisation est qu'on perd la robustesse de l'ensemble aux pannes totales: Mais bon, les cartes actuelles ne tombent pas souvent en panne et on peut prévoir une carte de réserve, vu le prix.
Si j'avais à refaire Domocan aujourd'hui, je ferais une version centralisée, plus simple. Mais bon, les softs sont déjà écrits et ça fonctionne, donc je ne pense pas changer prochainement.

Le but serait donc de commencer par créer un module "maître" qui superviserait l'ensemble de l'installation (et donc les modules esclaves).

Domocan n'est pas un système centralisé à l'origine, il n'y a pas de module maître imposé. Par contre certains ont ajouté des fonctions avancées à base d'une Raspberry et toutes les cartes Domocan disposent d'un mode de commutation centralisé/décentralisé accessible à l'aide de l'envoi d'une simple commande.
Donc, avec Domocan, on peut
- Travailler en pur décentralisé (mode natif)
- Travailler en décentralisé en ajoutant une carte de fonctions "centralisées" avancées: On conserve l'impossibilité de panne totale, on ne perd que les fonctions de la carte en panne.
- Travailler en centralisé en commutant toutes les cartes en mode centralisé et en ajoutant une centrale. Dans ce cas il faut écrire le soft de la centrale. Les logiciels sont beaucoup plus simples mais on doit penser à la panne de centrale.

Attention également avec les Raspberry et autres cartes travaillant sous OS: Ne pas oublier que nativement Windows ou Linux ne sont pas des OS temps réel: Il faut donc prendre très attention aux délais éventuels introduits lors des actions utilisateur, paramétrer très finement l'ensemble, penser à la latence, et, au besoin, installer un vrai OS temps réel, ce qui complique l'écriture des logiciels et augmente le coût si on choisit un RTOS payant. Mon avis est qu'il faut tout chiffrer dans un cahier des charges avant de choisir sa centrale.

Les modules "esclaves" quand à eux seront des "extensions" d'entrées sorties disposés en tableau également (rail DIN).

Ceci correspond à ma toute première installation domotique, qui utilisait un automate programmable Siemens ST-216 avec un bus RS485 pour ajouter des modules d'extension personnels.
Note que si tu travailles sans bus et sans cartes délocalisées, alors tu t'interdis plusieurs possibilités, comme les touches sensitives ou les écrans tactiles distants, l'ajout de cartes sur zone sans tirer des câbles supplémentaires à partir du tableau électrique, etc. Je pense qu'il faut concevoir un système domotique comme le plus ouvert possible, car tu ignores quels seront tes besoins et tes envies dans 10 ans.
Note également qu'un automate programmable travaille en temps réel et que tous les temps de latence sont connus.

Pour la communication à l'intérieur même tu tableau électrique, j'avais pensé à un bus I²C

Attention, l'I2C est pensé pour communiquer entre plusieurs périphériques sur une même carte, ce n'est pas le bus idéal pour communiquer entre plusieurs cartes, surtout si leur nombre augmente. En outre, I²C est faussement simple car, vu qu'il n'inclut aucun mécanisme de vérification, il faut tout créer par soft, ce qui consomme du temps CPU, au contraire de CAN (par exemple). En outre les distances sont fortement limitées, les vitesses décroissent très vite si le bus s'allonge.

Le cable de bus va donc se promener dans le tableau électrique de module en module. Et j'ai peur de l'I²C soit trop sensible aux perturbations électromagnétiques des courants forts environnants. Quelqu'un pour m'éclaircir sur ce point svp?

En ce qui me concerne je n'ai mis aucun bus dans mon armoire électrique: Mes cartes de commande gradateur sont placées à l'extérieur de l'armoire et les cartes de puissance à l'intérieur. Entre les deux je fais passer des câbles multipaires (genre câbles // d'imprimante) avec liaison optique au niveau des cartes de puissance. Bref, aucun micro dans l'armoire électrique, aucun bus, et une liaison en boucle de courant avec isolation galvanique entre extérieur et intérieur de l'armoire électrique.
Maintenant on peut toujours mettre de la BT dans l'armoire électrique mais il faut bien blinder et correctement tout référencer à la masse.

La plupart des cartes utilisent des PIC16/18

En fait il n'y a pas de 16F, rien que des 18F. Tous les softs ont été portés sur la dernière version des 18F CAN, qui sont fiables.

le tout codé en ... pur assembleur ... et non en C, donc obligation d'apprendre l'asm

Pas du tout.
J'ai codé les softs de mes propres cartes en langage d'assemblage, j'ai publié mes sources et réalisé des fichiers de base prêts à l'emploi pour faciliter la vie de ceux qui veulent ajouter leurs propres cartes en utilisant ce langage.
Mais Domocan se moque éperdument du langage que vous utilisez, vous programmez en ce que vous voulez. C'est juste que:
- Si vous utilisez mes cartes, ben vous n'avez rien à programmer du tout, c'est déjà fait.
- Si vous voulez réaliser vos propres cartes en programmant en langage d'assemblage alors vous pouvez (pas devez) utiliser mes fichiers maquettes pour vous faciliter la vie.
- Si vous voulez utiliser un autre langage, il vous suffit de lire les documents de Domocan pour savoir comment réaliser un soft compatible avec le reste de l'installation.

d'une architecture obsolète.

Honnêtement, je vois mal en quoi les PIC 18F sont obsolètes? Ils sont utilisés partout et Microchip sort sans arrêt de nouveaux modèles.
Ce n'est pas parce que maintenant il est plus facile pour l'amateur de trouver des cartes ARM 32 bits déjà montées et à bas prix que les PIC deviennent obsolètes: Les domaines d'application sont différents, et moi-même j'utilise plusieurs technologies en fonction des besoins. Je ne m'amuse pas à utiliser un PIC 8 bits pour réaliser une carte avec port USB Host + lecteur SD + écran tactile couleur, je prends une carte ARM dédiée. Par contre je ne m'amuse pas à utiliser une carte ARM 32 bits pour réaliser un gradateur de lumière. Les PIC 8 bits présentent l'avantage d'être dans des formats simples pour l'amateur qui doit souder ses composants.
Moi je suis pragmatique: Domocan est un système décentralisé: Si je prends une carte utilisant un timing critique, genre carte gradateur, je vois qu'avec un seul PIC18F j'arrive à gérer 16 sorties sur 51 niveaux linéarisés, ou 16 sorties sur 256 niveaux "équidistants". C'est suffisant et on peut même encore faire mieux.

Maintenant, je vois mal ce qui empêche, à partir du moment où on veut créer ses propres cartes, d'utiliser n'importe quoi d'autre. On peut utiliser des cartes PIC24H,PIC32, Atmel,ARM, n'importe quoi d'autre, à partir du moment où on respecte les conventions Domocan: Le type de micro n'est pas imposé, même si à la base j'ai décidé d'utiliser des PIC18F. Le seul "obstacle" est la fonction de mise à jour du firmware à distance: Sur Domogest 3 c'est codé pour des 18F et donc il faut modifier la routine. Sur Domogest CE4 c'est un plugin qui gère ça: J'ai écrit le plugin pour permettre n'importe quels paramètres de bootloader: On peut donc ajouter n'importe quoi.

Le soft PC n'est pas portable : au début c'était du VB6, maintenant du C#, peut-être que ça tournerait sur mono ?

Oui et non, parce que la portabilité est un faux problème, j'en reparle plus bas.
Personne ne m'a reporté de tests sur Mono, bien qu'un certain nombre d'utilisateurs tournent sous Linux par exemple, c'est lié au fait que c'est un faux problème dans la pratique.
Sinon les sources C# sont fournies, on peut adapter à ce qu'on veut... mais ça nécessite du boulot. Ou compiler pour Mono, il n'y a que quelques modifs à faire avec une compilation conditionnelle pour supprimer les interactions des contrôles personnalisés avec Visual Studio (snaplines etc), qui n'impactent qu'au moment du dessin des fenêtres lors de la conception (aucun impact en utilisation).

La dernière version de Domogest CE4 en C# est opérationnelle. Avec ce programme on peut créer ses plugins pour ajouter ses propres cartes. Le problème est que:
- Les utilisateurs ont hurlé lorsque j'ai voulu créer une version centralisée de Domocan, ils ont fait le forcing pour que je conserve la version décentralisée.
- Or, c'est beaucoup beaucoup beaucoup plus difficile de créer les logiciels de paramétrage (Domogest) pour configurer une installation décentralisée qu'une installation centralisée. J'avais prévenu, ils n'ont rien voulu entendre.
- Du coup, j'ai réalisé (il m'a fallu des mois) une version intégralement plugin de Domogest pour que chacun puisse ajouter ses propres cartes: J'ai écrit la doc concernant la création de plugins, des outils de migration automatique etc. MAIS strictement personne n'a écrit de plugin, et donc j'ai fait tout ça pour rien. Je compte donc réaliser pour moi une version centralisée avec logiciel dédié, que je rendrais publique mais qui ne sera pas à plugins: On ne m'aura pas deux fois, la programmation par plugins étant beaucoup plus complexe à réaliser au niveau du programme principal. Bref je vais faire une version centralisée "figée" et celui qui voudra ajouter ses cartes devrai modifier le soft de configuration.

Notez que les plugins peuvent être écris en n'importe quel langage dotnet (java#,C#, Python.net, VBNet etc.).

Si ça oblige à utiliser un PC Windows comme centrale, alors aucun intérêt pour moi.

Pas du tout.
Domocan n'utilise aucune centrale, c'est un système décentralisé. Du coup, ça n'oblige personne à utiliser un PC windows comme centrale, puisqu'il n'y a pas de centrale.
J'ai conçu ce système justement parce qu'à l'époque il n'existait pas de candidats susceptibles de faire office de centrale et que justement, imposer de laisser un PC tourner était hors de question (encombrement, consommation, prix, pannes, plantages...).

Aujourd'hui il existe des candidats pertinents, comme la Raspberry, Pandaboard et autres: Certains ont même "mélangé les genres" en conservant Domocan décentralisé et en ajoutant des fonctions centralisées à base de Raspberry (connexion internet, pilotage à distance etc): C'est publié sur le forum Domocan. C'est pourquoi j'ai voulu refaire une version compatible hardware mais avec de nouveaux softs pour travailler en mode centralisé, mais les utilisateurs semblent tenir au mode décentralisé pour raison de fiabilité.

Bref, le PC ne sert que pour configurer le système ou pour modifier des paramètres (ajout d'une carte, modification de la durée d'une temporisation etc.). Je dois en gros utiliser Domogest une fois tous les 6 mois. Ceci explique que je n'ai jamais reçu de rapports d'utilisateurs Linux sur Mono: En fait, ils font tourner un Windows virtuel dans leur OS Linux pour lancer Domogest lorsqu'ils en ont besoin. De toute façon, 90% des utilisateurs Linux ont Windows installé dans une machine virtuelle, ça ne dérange donc personne, Domogest étant surtout utilisé en phase d'installation ou de modifications.

Niveau fiabilité, j'ai subit la foudre deux fois (avec destruction de PC, d'électroménagers etc): La domotique n'a pas eu de problème. J'ai eu deux pannes en 11 ans: Un halogène qui a claqué et s'est mis en court-circuit, ce qui a entraîné la fusion d'un fusible sur la carte de commande, et une carte de puissance qui a brûlé à cause d'une mauvaise soudure au niveau d'un triac. Bref, deux pannes qui ne sont pas le fait de Domocan. Le système ne plante jamais, puisque décentralisé (jamais aucun besoin de reset du système).

J'ai plus de 100 halogènes dans la maison, et ils commencent seulement maintenant à claquer: Tenir plus de 10 ans des halogènes c'est dû au fait que l'allumage est temporisé sur 500ms au lien d'être brutal (paramétrable dans Domogest)
Maintenant je viens de faire mes premiers essais avec des LED GU10 COB dimmables; Ca fonctionne parfaitement: Je vais donc tout remplacer puis faire une mise à jour des tables des gradateurs, la courbe de réponse d'une LED étant différente de celle d'une incandescente, autant fignoler le rendu. Tout ceci sera publié en début d'année prochaine.

Ah oui, dernière chose: Tout est public sur Domocan, et donc tu peux copier tout ce que tu veux pour ton propre système, ou pomper des idées, ou te faire un système à la carte

Bonne réalisation,
A+
Bigonoff

[antek]

Salut
. . .
Bonne réalisation,
Bigonoff

On ne se connait pas, mais c'est toujours un plaisir de te lire !

[invite03481543]

Il confirme bien ma thèse du CAN qui est assez solide et simple à mettre en oeuvre.

Bonjour,

le CAN est une bonne idée, par contre si tu n'es pas un minimum initié à ce bus tu vas vite te rendre compte que ça n'est pas aussi simple que ça.

[invite03481543]

Je partage l'avis de Bigonoff sur les PIC18, ces µC sont tout à fait performants et suffisants pour faire du CAN.
Perso j'utilise le PIC18F66K80 depuis des années pour le CAN et ils sont loin d'être limités en quoi que ce soit.

[Bigonoff]

Salut
------

On ne se connait pas, mais c'est toujours un plaisir de te lire !

Merci

le CAN est une bonne idée, par contre si tu n'es pas un minimum initié à ce bus tu vas vite te rendre compte que ça n'est pas aussi simple que ça.

C'est tout à fait exact, mais dans mes docs il y a la façon de procéder, et mes sources constituent un exemple pratique.

J'ai également oublié de préciser que l'I²C n'est pas sur paire différentielle mais en série synchrone sur 2 fils, c'est un bus qui est donc fortement sensible aux perturbations électro-magnétiques avec couplage en mode commun (les "parasites"). Can sous ISO-11898 ne présente pas cet inconvénient, RS485 non plus. Si on accepte le câblage en étoile, Ethernet n'a pas non plus ce problème. Pour ce genre d'application je recommande quand même d'essayer de s'immuniser au maximum contre le couplage en mode commun.

A+
Bigonoff