Dialogues entre plusieurs 16F877 et carte mère

[invite7f975a56]

Salut vous tous,
Sur un nouveau projet, je dois communiquer entre 6 PIC 16f877 et une carte mère ( mini carte PC industriel )

Je dispose en connection sur la carte : I2C, 2* USB, RJ45 10/100, port parallèle, 2 sorties COM ( RS232 ou RS485 > j'attend reponse du fabricant car rien n'est mentioné dans le manuel!!! ), Je souhaite épargner le PORT RS485 si il existe car je dois l'utiliser impérativement pour communiquer vers l'extérieur.

Je me suis alors pencher pour une liaison en I2C,mais avec un gros doute sur la rapidité de communication, éventuellement le USB, je dispose de deux sorties mais sans aucune connaisance technique. Bref je but sur le choix et je me pose aussi la question de savoir si je ne doit pas placer aussi un autre pic comme un espèce de buffer par exemple et quand il recoit une info de la carte mère, il se met en dialogue avec le pic concerné puisque chacun d'eux aura sa propre adresse de participant, et vis-versa si le pic exclave doit renvoyer une info suita à un changement d'état sur le périphérique, il prend la ligne en s'annoncant comme le pic n°x et envoit le paquet d'info au pic intermédiaire qui le retransmet à la carte mère. J'ai pensé que cette solution éviterait un crache de communication,un peu comme l'I2C quand la ligne est occupé les autres IC se place en écoute.

Ceci n'est qu'une idée et je souhaiterais avoir l'avis de ceux qui ont déjà été confrotté à ce même genre de problème.

Un ami me parlait d'un simple buffer,mais je trouve la chose assé complexe puisque le buffer ne saurait pas reconnaittre pour qui l'info est depuis la carte mère et aussi vis-versa.

Par ailleur, si je passe du RS232 vers le RS485 par un montage , je suppose qu'il n'existe pas un IC qui pourrait bouster la vitesse pour avoir un RS485 à la bonne vitesse, il me semble que je doit rester limité par la vitesse du 232 qui l'IC d'envois des info?

Merci des infos que vous sauriez me donner, Fabrice
-----

[freepicbasic]

Les Pics n'ont qu'un seul USART , cela implique 2 types de gestion;

soit on met tous les périphériques sur une ligne, cela impose une gestion de protocole assez complexe , car chaque périphérique doit avoir une adresse ou une identité, comme l'I2C.

soit on commute les voies une à une et le master interroge chaque pic, l'avantage est que le programme de réponse est totalement identique sur chaque périphérique et assez simple puisqu'il envoie ses données , dès qu'il recçois une demande , et l'adressage se fait par le µc master grâce au hard.
On peut utiliser se système pour 6 voies avec 2 x 4052 et 6 max232.


Pour l'i2C 100khz max soit environ 10 000 bauds, avec le protocole on tombe a moins de la moitié.


Après il faut tenir compte de la distance master / slave

[Jack]

Je me suis alors pencher pour une liaison en I2C,mais avec un gros doute sur la rapidité de communication

De quelle vitesse as-tu besoin?

Sinon, il reste encore la spi, en chaînant les pic, qui a l'avantage de sa simplicité de mise en œuvre.

A+

[Moezzz]

Salut,
si vous avez besoin de plus de vitesse vous avez la possibilité d'utiliser le mode PSP. dans ce cas le transfert sera en parallèle en non pas en série.
l'I2C peut être configurer pour une vitesse de 400 kHz si le 100 kHz ne suffit pas
@+

[A voir en vidéo sur Futura]

[RISC]

Salut,

Il existe un mode interessant sur les USART qui est peu connu et qui permet d'utiliser les USART en "mini-réseau" : le mode 9bits.
En effet, ce mode permet d'envoyer (un peu comme l'I2C) l'adresse du périphérique avec lequel on veut discuter.
Pour cela il suffit de positionner le 9e bit pour signifier que les 8 bits qui suivent sont l'adresse de l'esclave avec le quel le maitre veut discuter (voir la datasheet du PIC16F877 chapitre 10 et en particulier paragraphes 10.2.1 et 10.2.2).
Il suffit de se créer son propre protocole du style après émission de l'adresse, 10 octets sont transmis, de cette manière tous les esclaves non concernés "jettent" les 10 octets qui suivent et se remettent en mode écoute adresse.

Concernant l'I2C, c'est seulement possible (normalement) si tous tes PICs sont sur la même carte. L'I2C n'est pas prévu à l'origine pour communiquer entre différents PCB.
Au niveau de la vitesse, il faut simplement vérifier la vitesse max que peut atteindre le PIC16F877. C'est la seule limite. On peut très bien faire de l'I2C à 1Mbits si le circuit le permet et a la puissance requise.

a+

[invite7f975a56]

Ou Salut vous tous, ou la la! il y a du choix dans mon problème!

Concernant les pic, chacun aura sa propre adresse de participant quelque soit le type de communication, je pense que cette solution limitera déjà le crach !

Tous les pics et même le pic intermédiaire entre la carrte mère et les 6 autres pics seront sur le même pcb et batisé "carte mère secondaire d'interface" donc dans le cas de l'I2C avec seulement 20 à 25 cm de piste le problème ne devrait pas se poser.
Jack et Moezzz, vous me parlé de SPI et PSP, avez vous plus d'information?
l'I2C en 400khz!!! soit 40000 bauds ? j'amais vu une vitesse pareil,mais comment y arriver? Si c'est possible sans trops de problème, cette solution m'attire.
Pour le PSP parralèle il faudrait alors utiliser le port parallèle DSub 25?mais la vitesse tourne à combien? sauf si je me trompe!Je repasse plus tard dans la soirée,je vais me pencher sur vos idées puisque j'ai déjà pas mal d'info qui me fait réfléchir !!Merci et à tantot

Fabrice

Risk, ton principe à 9 bits m'intrigue quand même, tu parles du cours de Bigonoff ou du pic in english?

Pour le mode de communication qui sera choisi, je ne dois pas n'égligé que temps que le pic mère dialogue avec un des 6autres pics, les restant doivent attendre que la ligne soit libérée pour envoyer les infos, donc il me semble que la communication doit resté dans le même style que l'I2C :une fois la ligne occupé les autres pics sont en écoute. Maintenant si j'ai deux pics qui occupe en même temps la ligne( pic5 et pic6), comment donner une priorité, ou comment éviter un problème d'occupation en même temps. Tous les pic seront cadencés à 20Mhz,il y aura toujours unpic plus rapide que l'autre quoi qu'il arrive???

J'ai de quoi prendre la tête avec toutes les solutions que vous me donner.

Le projet lui :
Une carte mère avec ecrant 17",clavier et souris,
la carte interface avec le pic intermédiaire et 6 autres pic 2à 7
PIC2, réalise par un multiplexage la lecture de 80 boutons et écriture de 80 leds ( on-off-clignotement ).
PIC3, réalise la lecture de 10 boutons, 18 leds ( on-off pour 8 et on-off-clignotement pour 10leds ), 8 roues codeuse signal A/B ( 256 pulse par rotatation de 360° et
PIC4, réalise par un multiplexage la lecture de 40 boutons, l'écriture de 40 leds ( on-off-clignotement ), la lecture de 15 faders 100mm et un lcd en 4 bit.

PIC5,PIC6 et PIC 7 pour chacun : réalise par un multiplexage la lecture de 20 boutons, l'écriture de 20 leds ( on-off-clignotement ), la lecture de 10 faders 100mm et un lcd en 4 bit.

Chaque LCd est au format 4*40 lignes

On m'a aussi parlé du bus CAN mais je suis limite dans les connaissances de protocolede communication , le RS485 et l'I2C je connais de quoi me débrouillermais sans une tonne d'expériance!!!

[Jack]

Pour le système proposé par RISC, la restriction est qu'il n'est pas bidirectionnel. Mais peut-être cela te suffit-il? (tu n'as pas préciser si ta liaison était bidirectionnelle).

Jack et Moezzz, vous me parlé de SPI et PSP, avez vous plus d'information?

La spi est une simple liaison bidirectionnelle synchrone, un registre à décalage en mieux si tu veux. Ton pic la gère, regarde la doc.

l'I2C en 400khz!!! soit 40000 bauds ? j'amais vu une vitesse pareil,mais comment y arriver? La spi est plus rapide. Comment y arriver? En programmant les registres du pic pour générer du 400 kHz

A+

[invite7f975a56]

Pour le système proposé par RISC, la restriction est qu'il n'est pas bidirectionnel. Mais peut-être cela te suffit-il? (tu n'as pas préciser si ta liaison était bidirectionnelle).

La spi est une simple liaison bidirectionnelle synchrone, un registre à décalage en mieux si tu veux. Ton pic la gère, regarde la doc.

l'I2C en 400khz!!! soit 40000 bauds ? j'amais vu une vitesse pareil,mais comment y arriver? La spi est plus rapide. Comment y arriver? En programmant les registres du pic pour générer du 400 kHz

A+

D'accord! Dans mon cas c'est du bi directionnelle pour l'échange de l'info.
je vais regarder sur Google pour le SPI et sa mise en oeuvre,mais dans le futur est ce que le SPI peux encore évoluer favorablement ou il est limité dans les applications ? : défini pour un certain type d'application

Dans mon calcul de vitesse je dois pouvoir faire une écriture et lecture des pic 25x par seconde . Dans mon cas des lcd je suppose qu'une écriture par exemple "Bonjour" consiste à l'envoi d'une seul écriture qui représente un octet par caractère sans tenir compte des autres octet de gestion nécessaire a l' lcd comme par exemple choix de la ligne et de l'emplacement ( X et Y en positionnement dans lcd), Enable 1 et 2, type du caractère petite ou grande police ( voir les registres interne de l'lcd. Mais dans tous les cas ce type de dialogue prendra un peux plus de temps vu le nombre de paquet d'octet à envoyer pour un simple message. Après recule je pense maintenant que l'I2C va peut-être saturer en vitesse de communication.
Dans le CAN PSP,SPI bref un autre protocol me semble comme vous me dite surement bien plus intélligent et fiable. Ca reste une question de choix concernant mes capacités de mise en oeuvre

je vais retourner google pour plus d'info.
A tantôt, Fabrice

[RISC]

Fabrice,

Tes PIC16F877 sont-ils sur des circuits imprimés différents ou sur le même ?
S'ils sont sur des CI différents, tu peux oublier l'I2C qui est prévu pour une communication entre les circuits intégrés sur le MEME circuit imprimé.

Le protocole le plus fiable de tous ceux proposé est sans nul doute le protocole CAN. C'est d'ailleurs celui qui est utilisé dans les voitures.
Cependant si ton système a été prévu sans le bus CAN, tu peux oublier. Les modifications électroniques à apporter seraient énorme dans ton cas. De plus il faut prévoir une couche logicielle assez importante pour gérer ce protocole.

Question vitesse, le SPI est le plus rapide (il existe des circuits, c'est pas le cas du PIC16F877, qui fonctionnent jusqu'à 30 ou 40 Mbits en mode SPI). Pour le PSP, c'est un mode parallele qui demande beaucoup de lignes. Il est donc déconseillé pour une liaison filaire car il faut une nappe complète de courte distance...

Il faudrait faire un cahier des charges plus précis pour avoir les idées claires sur la bande passante maximale dont tu as besoin et les temps de réponse...

Le protocole USART que j'ai proposé ne fonctionne pas uniquement en HALF DUPLEX comme cela a été commenté.
Le mode de fonctionnement dépend uniquement du protocole de communications qu'implémente l'utilisateur.

a+

[Jack]

Le protocole USART que j'ai proposé ne fonctionne pas uniquement en HALF DUPLEX comme cela a été commenté.

C'est moi l'auteur du commentaire . En fait, je voyais même plutôt une liaison simplex.

J'ai peut-être mal compris ton système. dans ce cas, peux-tu donner plus de détails sur le fonctionnement d'un réseau multipoints basé sur des usarts?

D'autres part, y a-t-il vraiment problème à relier deux cartes séparées par une dizaine de cm par un bus I2C?

A+

[RISC]

C'est moi l'auteur du commentaire . En fait, je voyais même plutôt une liaison simplex.

J'ai peut-être mal compris ton système. dans ce cas, peux-tu donner plus de détails sur le fonctionnement d'un réseau multipoints basé sur des usarts?

Salut,

En fait dans ce cas d'utilisation, tout le protocole doit être fait au niveau soft par l'utilisateur...Ca équivaut un peu à refaire en soft tout ce que l'I2C fait en HARD...
C'est à dire également que dans le cas ou plusieurs noeuds peuvent parler en même temps, les collisions doivent être gérées en soft.
On peut définir par exemple une machine d'état ou chaque commande donne lieu à des réponses et une/des transition(s) vers d'autres états.
Le point intéressant est le 9e bit que l'on peut utiliser à sa guise.
Dans cette topologie, il vaut mieux avoir un seul maître et plusieurs esclaves et que ce soit le maître qui interroge régulièrement les esclaves.

D'autres part, y a-t-il vraiment problème à relier deux cartes séparées par une dizaine de cm par un bus I2C?

Dans mon expérience professionnelle, plus de 50% des problèmes I2C sont d'origine matérielle (électronique)...
Contrairement à ce que beaucoup pensent, les résistances de rappel doivent être calculées précisemment !!!
Ce ne sont pas des simples résistances de rappel !!
L'impédance de chaque boitier sur les lignes I2C doit être prise en compte pour le calcul des résistances (c'est très bien expliqué dans la spécification et les diverses notes d'application.

Il existe bien sûr des possibilités de "détourner" l'I2C pour faire de la communication carte à carte grace à des circuits "booster" d'I2C.
Une lecture attentive de la spécification de l'I2C fait comprendre l'importance des fronts des signaux et l'impact de tout cirucit connecté voire du circuit imprimé lui-même...

a+

[invite03481543]

Salut,

RISC à bien résumé le problème de l'I2C inter-cartes, mais malgré tout il est possible de faire des liaisons de plusieurs mètres sans pour autant utiliser de circuits spécialisés tel que le PCF82B715 auquel il fait surement allusion.

Avec 2 transistors coté maître et 2 transistors coté esclave(s) ça marche très bien pour une dizaine de mètres.
D'ailleurs je posterai en projet prochainement une centrale de gestion en I2C basée sur un 80C552 utilisant cette liaison.

Le soucis majeur de l'I2C est son mode non différentiel qui le rend (très) sensible aux perturbations CEM.
C'est entre autre pour cela que le bus CAN est le plus performant avec le RS485 également différentiel.
@+

[Jack]

n fait dans ce cas d'utilisation, tout le protocole doit être fait au niveau soft par l'utilisateur...Ca équivaut un peu à refaire en soft tout ce que l'I2C fait en HARD...
C'est à dire également que dans le cas ou plusieurs noeuds peuvent parler en même temps, les collisions doivent être gérées en soft.

Ca va nécessiter également une configuration matérielle adaptée il me semble.

Le soucis majeur de l'I2C est son mode non différentiel qui le rend (très) sensible aux perturbations CEM.

Pareil pour la spi.

La RS485 n'est-elle pas également un bon compromis au niveau simplicité matérielle / logicielle / robustesse de la transmission dans la cas de ABYSS?

[invite7f975a56]

Re re salut tous le monde, ops,

Bon, réponse par réponse :
Tous les pics sont sur le même PCB:le pic secondaire et les 6 autres ( le train +les 6wagons ), pour limiter le cout de la fabrication de la carte et encombrement, seul la carte mère sera juste à coté à quelques centimètres distance minimum du cable pour faire la liaison,puisque l'alimentation général pour tous le projet sera celle d'un pc.

Pour ce qui est de la communication, il est peut-etre plus sage d'avoir le pic secondaire qui va interroger la carte mère et qui irait chercher les instructions pour chaque PIC et entamerais alors le dialogue. Ce qui revient à dire que le pic secondaire aura dans l'ordre : lire les instructions dans la carte mère pour le pic2 , envoyer ainsi l'ordre au pic 2 ,lire dans un ou plusieurs registres ce que le pic2 a eu comme changement de situation entre temps ( exemple 3 boutons sélectionés et, renvoyer le tous à la carte mère, ensuite même procédure pour les autres pics, en gros j'aurai une tournante dans le dialogue de chaque pic et donc 6 pics esclave, le pic 1 d'interface maître vis à vis des 6pics mais aussi exclave vis à vis de la carte mère et forcément ma carte mère qui reste la reine dans la gestion de toute la communication ?

Maintenant pour le taux de transmission nécessaire, je vais refaire une simulation entre chaque pic exclave et pic d'interface pour avoir une idée de la vitesse nécessaire, ca vas pas être du gateau mais bon, faut bien maintenant avoir une base plus solide.

Pour ce qui est de la conception des cartes pcb, je suis toujous au stade layout donc les changements ne sont pas un problème,mais ou je souhaite garder pied sur terre c'est dans le soft, si le bus CAN reste complexe, je risque alors de buté aussi pour mettre au point le dialogue

pour Jacky, le RS485 ne doit impérativement pas être utilisé dans mon cas il est déjà réservé quoi qu'il arrive donc c'est la croix rouge déjà garantie pour l'utiisé dans le dialogue. avec le RS485, le RS232 ok,.

Risk, pour le SPI tu m'informes qu'il existe des circuits tous fait et que le
16F877 n'est pas prévus des le départ, tu parles alors de quel genre de circuit? 30 à 40 Mbits cela me semble déjà pas mal en vitesse!!!

Si je dois ajouter / modifier mon layout autant le faire dès maintenant qu'après au stade conception du proto.
pour ce qui est du PSP,on tire alors un trait dessus à cause de problème de distance du cable > ok

L'I2C, trops lent en communication, résistance de Pull-UP à calculer avec précision, > ok quoi que j'ai déjà placé des résistances de 10K entre le pic et le lecteur de carte à puce, ca à du être un coup de bol de cocu que c'a fonctionnait sans problème!!!

Le CAN, demande l'implantation d'un code source assez lourd, j'imagine alors que les PICS vont trainer et perte quelques milli secondes dans leur tache de fonction ?

Bref le SPI, au final reste la solution la plus simple à mettre en oeuvre alors?

L'étau se resert vachement maintenant!!

Je vais réaliser un schéma simplifier avec les pics et leurs périphériques, ont vera plus clair ainsi. Je vais passer à table et je reviend ver 19h30 pour réaliser et placer se schéma ici. Je prendrais aussi une photo delamaquette que j'ai réaliser en couleur ( assemblage de plusieurs feuilles A4 collées bref une maquette bricoler mais qui représente bien le projet )

Sur ce, bon appétito et à tantôt, Fabrice

[freepicbasic]

Pour le mode de communication qui sera choisi, je ne dois pas n'égligé que temps que le pic mère dialogue avec un des 6autres pics, les restant doivent attendre que la ligne soit libérée pour envoyer les infos, donc il me semble que la communication doit resté dans le même style que l'I2C :une fois la ligne occupé les autres pics sont en écoute. Maintenant si j'ai deux pics qui occupe en même temps la ligne( pic5 et pic6), comment donner une priorité, ou comment éviter un problème d'occupation en même temps. Tous les pic seront cadencés à 20Mhz,il y aura toujours unpic plus rapide que l'autre quoi qu'il arrive???

Quelque soit le système il doit y avoir un master qui interroge et slave qui répond.
Donc le temps de réaction le plus rapide sera de six interrogations et de six réponses "nothing" avec Six périphériques.

Mais on ré invente L'I2C là ...

Il serait peut être plus utile d'expliquer à quoi ça sert plutôt que de faire des plans sur la comète

[invite03481543]

Tu pourrais tout aussi bien utiliser la liaison I2C ET une liaison RS485 full duplex avec le même PIC.

L'I2C serait émulé par soft sur 2 I/O et l'USART serait réservé pour une liaison RS485.
Ainsi tu aurais un bus différentiel extérieur et un bus local.

Pour ce qui est du CAN, il existe des PIC ou autre µC d'ailleurs qui ont un coeur CAN avec des librairies dédiées très simple à mettre en oeuvre.

PS: j'ai posté dans le forum des projets un descriptif d'une centrale de gestion par I2C avec modules satellites externes.
Je posterai le schéma de la centrale de gestion dans la soirée.
Vous noterez que je n'utilise pas de circuits spéciaux pour l'interface I2C inter modules mais un bête transistor PNP.
Une liaison de 10m se fait sans soucis.
Jack à raison sur le fait qu'une liaison RS485 est de loin la solution la plus simple, la plus économique et d'une grande fiabilité, bien que le CAN soit la panacée il faut bien l'admettre pour le protocole sécurisé et la vitesse de transmission des datas.

@+

[invite03481543]

Quelque soit le système il doit y avoir un master qui interroge et slave qui répond.
Donc le temps de réaction le plus rapide sera de six interrogations et de six réponses "nothing" avec Six périphériques.

Mais on ré invente L'I2C là ...

Il serait peut être plus utile d'expliquer à quoi ça sert plutôt que de faire des plans sur la comète

Tu as raison, c'est pour ça que le mode polling pourrait être avantageusement remplacé par un mode multi-maîtres si la vitesse de traitement est critique et fonctionner dans ce cas en interruptions.
@+

[RISC]

Risc, pour le SPI tu m'informes qu'il existe des circuits tous fait et que le 16F877 n'est pas prévus des le départ, tu parles alors de quel genre de circuit? 30 à 40 Mbits cela me semble déjà pas mal en vitesse!!!

Si je dois ajouter / modifier mon layout autant le faire dès maintenant qu'après au stade conception du proto.
pour ce qui est du PSP,on tire alors un trait dessus à cause de problème de distance du cable > ok

L'I2C, trops lent en communication, résistance de Pull-UP à calculer avec précision, > ok quoi que j'ai déjà placé des résistances de 10K entre le pic et le lecteur de carte à puce, ca à du être un coup de bol de cocu que c'a fonctionnait sans problème!!!

Le CAN, demande l'implantation d'un code source assez lourd, j'imagine alors que les PICS vont trainer et perte quelques milli secondes dans leur tache de fonction ?

Bref le SPI, au final reste la solution la plus simple à mettre en oeuvre alors?

L'étau se resert vachement maintenant!!

Salut,

Le SPI est pratiquement toujours interne. La vitesse du SPI dépend en général de la vitesse max du micro.
Le SPI de 30 à 40 Mbits auquel je fais allusion se trouve dans les PIC32 qui fonctionnent à 80MHz ;=)
Pour le PIC16F877, je pense que le SPI est limité à 1.2Mbits max avec Tcy = 5MHz (voir les paramètres du tableau 15-7 dans la datasheet).

La seule façon d'avoir un SPI plus rapide serait de changer de micro...

a+

[invite7f975a56]

Voila, désolé du retard, j'ai été appelé par un client qui veux transformer sa Goldwin en light show pour du tuning, jai donc du faire le trajet chez lui.

Voici les photos du projet, leprojet n'est d'autre qu'une console de lumière dont le RS485 est dédié pour avoir mon signal DMX 512.

Autre, j'ai au final 8 LCD et non 6, deux LCD par PIC mais cela ne va rien changer sauf une double communication avec les paramètres.


La photo 1 montre l'ensemble (photo 3022 )donc :
en bas à droit, j'ai mon écran TFT 15" avec au dessus et en dessous 4 roues codeuses et les led témoin pour dire quelle roue est pris en contre dans la programmation, 12 boutons avec leds, le tous sur le pic n°3.( photo 3023 )

Juste à gauche j'ai la fameuse matrix de 80 boutons et leds, ainsi que les 5 faders et 10 boutons et leds qui sont complètement à gauche de la console sur le pic n°2 ( photo 3024 )

Et au milieu en bas j'ai deux groupes de 5 fader avec un ecran LCD 4*40 et deux boutons par fader donc 2*(10 boutons et leds) soit 20 boutons et leds sur le pic n°3 et pic n°4.( photo 3023)

En haut j'ai trois groupe de 10 faders avec deux LCD par groupe et 20 boutons+leds. Chaque groupe reçoit le pic ( pic n°5,6 et pic n°7 ) Sur la photo les deux LCDs d'un groupe ne forme qu'un grand cadre bleu.

Maintenat , j'ai en tête qu'il existe des cartes optionel une entrér RS485 vers 8 sortie RS485, ceci changerait tous!

Hulk, passer de l'I2C vers du RS485 entre périphérique, ok mais en marche arriere ver ma carte mère je repasse en I2c? c'est là encore que le bas blaisse puisque j'aurais au finalun dialogue plus lent entre carte mère et le µC d'interface que entre celui-ci et les 7 autres périphérique

Pour Risk, tu fais référence à quel genre de pic en particulier ?

Au final le SPI me semble toujours une solution idéal.

le tous devient un vraix bouillon de soupe, il y a à boire et à manger dans chaque type de communication. Mais je pense que si cette carte 1RS 485 ver 8 sorties RS485 est dispo sur le marché, je vais voir regarder dessus.

Le CAN oui, mais devoir resortie des livres oua cheter un livre pour commencer à étudier et faire des essais,je suis partie pour 6mois avant de dire que je métrise allègrement ce type de communication.

Au final que faire??? quoi choisir dans la simplicité le RS485, convertir l'I2C en RS485 avec un 16F84?, le SPI?

Au secours!!!!!!!

[invite03481543]

Déjà tu peux oublier le 16F84.

Je ne vois pas bien l'impératif de vitesse que tu évoquais, il me semble qu'une liaison par RS485 suffirait, avec un µC sur chaque partie déportée et de l'I2C pour traiter localement les boutons, leds, faders, LCD.

Le tout est de travailler par interruptions afin que chaque partie activée puisse prendre la main, il ne faut pas un maître mais bel et bien un mode multi-maîtres.
Enfin personellement, c'est dans cette direction que je regarderai.
@+

[invite7f975a56]

Déjà tu peux oublier le 16F84.

Je ne vois pas bien l'impératif de vitesse que tu évoquais, il me semble qu'une liaison par RS485 suffirait, avec un µC sur chaque partie déportée et de l'I2C pour traiter localement les boutons, leds, faders, LCD.

Le tout est de travailler par interruptions afin que chaque partie activée puisse prendre la main, il ne faut pas un maître mais bel et bien un mode multi-maîtres.
Enfin personellement, c'est dans cette direction que je regarderai.
@+

Ops, entre mes pics et les boutons-leds-lcd et fader tous est presque en
74HC154 pour le démultiplexage des leds et multiplexage des boutons, donc rien en local style I2C tous est en direct ou presque avec les pics. C'est juste entre le pic secondaire et les 6 autres pics que j'ai le problème de dialogue.

Je pense donc m'orienter avec une communication entre la carte mère et directement avec les 6autres pics si je trouve ce fameux interface multi RS485.

C'est encore le plus simple dans ce cas ici.

[freepicbasic]

Je pense donc m'orienter avec une communication entre la carte mère et directement avec les 6autres pics si je trouve ce fameux interface multi RS485.

C'est encore le plus simple dans ce cas ici.

je vous souhaite bien du plaisir ...

Le plus simple;
Si la distance est de quelques centimètre un simple fil blindé et un signal TTL.
Une commutation Hard (genre 4066 ou 4052) par le master.
Un master et x slaves.

[invite7f975a56]

je vous souhaite bien du plaisir ...

Le plus simple;
Si la distance est de quelques centimètre un simple fil blindé et un signal TTL.
Une commutation Hard (genre 4066 ou 4052) par le master.
Un master et x slaves.

Le cd4052 n'est rien d'autre qu'un multiplexeur/démultiplexeur donc là je vois déjà pas comment mettre en oeuvre pour un dialogue entre plusieurs PICs
!!! sa ressemble franchement à un sucide !!

Et le 4066 est fort identique au 4016 du fonctionnement.

Dans les réponseil y a àboire et manger pour tous,mais dans mon cas, je dois aussi choisir ce qui est le plus facile pour moi, l'I2C me semble bien exclus, le RS232 j'oublie,le CAN je suisbon pour retourner à l'école, le SPI est le seul mode que je met juste à coté et le RS 485 je l'utilise pour le DMX512 donc déjà connu pour ma part.

Même la domotique chez moi sera en RS485.

Donc voila, je pense que moi choix se confirme à l'horizon pour une question de simplicité et de rapidité et non pour une question de prix.

Si quelqu'un à quelque chose d'autre plus intérresent,je suis preneur sinon je pense cloturer le débat ici qui reste quand même riche en réponse.

D'ici là encore merci à tous de votre aide et avis pour le projet qui dure depuis 1an-1/2 !!!

[freepicbasic]

Il s'agit du mode SPI , (registre à décalage)
Le DATA est commun et le clock est multiplexé , on aurait pu utiliser un registre mais un cycle de clock (perdu) aurait été nécessaire.

Une résistance de charge de 330 ohms donne 15 ma sur 5V donnant la possibilité de déporter d'environ 50 cm les pics slave avec un fil blindé de 3 conducteurs.
Ce n'est pas une boucle de courant pour cela il faudrait un étage driver supplémentaire avec AOP délivrant 50ma.

sur le schéma seul les PICs les 1,2,5 sont présents , on peu mettre différent type , c'est le soft qui pilote de toute façon.

sur les pic non équipé SPI on peu mette le clock sur l'entrée int externe, et ainsi traité la réception en quelques cycles.
Un Pic12F675 à 20Mhz devrait atteindre les 400khz ( ça laisserait que 12 cycles, difficile mais faisable)


Cette routine compte 14 cycles avec l'appel INT et le Return

	movwf	w_temp  	; sauver registre W
	swapf	STATUS,w	; swap status avec résultat dans w
	movwf	status_temp	; sauver status swappé

BSF STATUS,c
Btfss PORTB,1
BCF STATUS,C
rrf DATA,F

        swapf   status_temp,w   ; swap ancien status, résultat dans w
        movwf   STATUS          ; restaurer status
        swapf   w_temp,f        ; Inversion L et H de l'ancien W

Il faudrait l'associer à un time out pour séparer les octets
Peut être dans ce cas ajouter une ligne de flag réception
genre;
BSF FLAG,0

[freepicbasic]

exemple d'application avec bus I2C à 100khz commuté le data est commun le clock sert de "board select".
Pour une vitesse supérieure, il faudra du SPI sans protocole et des impédances assez faible 300 ou 150 ohms , le problème si on ne drive pas est le courant maximum débiter par le pic qui devient critique, il faudrait veiller à ne pas dépasser.

[invite7f975a56]

Ouais !

Vais regarder tous cela à tête reposé pour remettre un epu d'ordre maintenant.

En ce moment je calcul toutes les données aller-retour entre chaque pic exclave et le pic d'interface, ainsi j'aurais déjà une idée du taux de transfert et en fonction du résultat final je saurais vers quoi me retourner .
Mais le CAN est déjà exclus j'ai passer la nuit dessus pour voir le pour et le contre et dans mon application je n'ai aucun justificatif à prendre cette solution.

Quand j'aurais du neuf,je repasserais sur mon poste pour laisser les résultat de mes tests.

A+ FAbrice