I2C et xxM2

[micharmi]

Bonjour
La série xxM2 ne peux fonctionner qu'en mode maitre, sur un bus I2C
ce qui est bien dommage car il serait très intéressant de les utiliser comme esclave
C'est à mon sens une grosse lacune;: je ne comprends pas la motivation pour ne pas avoir inclus le mode esclave.

Question: est-il envisageable de concevoir un programma qui réalis cette communication sur un I2C en esclave?

 

[BESQUEUT]

Un I2C esclave suppose d'être à l'écoute du bus. ce serait sans doute possible dans le firmware, mais au détriment des performances de l’interpréteur. Comme le PICAXE n'est déjà pas réputé pour aller très vite, les concepteurs n'ont sans doute pas jugé utile d'ajouter cette possibilité dans le firmware. Ceci n'est qu'une supposition bien sur...
Quand à réaliser un programme de ce type, ce serait une véritable prouesse vu les timings à respecter, et le pauvre Picaxe ne pourrait sans doute plus faire grand chose d'utile...
Il y a sur le forum anglais une discussion très intéressante sur les possibilités que pourrait offrir un Picaxe fondé sur un PIC plus puissant, 32 bits par exemple.
On serait alors dans la gamme de produits existants (genre MaxiMite et ses dérivés commerciaux ...) ce qui ne semble pas être le créneau actuel des Picaxes (puces très bon marché et très simples à mettre en oeuvre, en particulier pour l'éducation)

 

[westaust55]

La série xxM2 de PICAXE sont la nouvelle version de niveau inférieure.

La série xxX2 de PICAXE sont les puces avancées.

L'espace disponible de programme dans la puce PIC de l'interpréteur BASIC peut être une contrainte.Une autre est la nécessité de prévoir une différenciation ou supplémentaires de fonctionnalités pour les puces avancées. Cela inclut la capacité d'esclave i2c et les commandes 1-Wire, ainsi que les plus grand nombre de variables, l'utilisateur programme espace, etc.

 

[micharmi]

Un I2C esclave suppose d'être à l'écoute du bus. ce serait sans doute possible dans le firmware, mais au détriment des performances de l’interpréteur. Comme le PICAXE n'est déjà pas réputé pour aller très vite, les concepteurs n'ont sans doute pas jugé utile d'ajouter cette possibilité dans le firmware. Ceci n'est qu'une supposition bien sur...
Quand à réaliser un programme de ce type, ce serait une véritable prouesse vu les timings à respecter, et le pauvre Picaxe ne pourrait sans doute plus faire grand chose d'utile...
Il y a sur le forum anglais une discussion très intéressante sur les possibilités que pourrait offrir un Picaxe fondé sur un PIC plus puissant, 32 bits par exemple.
On serait alors dans la gamme de produits existants (genre MaxiMite et ses dérivés commerciaux ...) ce qui ne semble pas être le créneau actuel des Picaxes (puces très bon marché et très simples à mettre en oeuvre, en particulier pour l'éducation)

Alors il reste éventuellement cette solution là:
http://www.kranenborg.org/ee/picaxe/SerialPower/V3.0/PicaxeSerialPowerNetwork_V3.0.pdf

 

[PieM]

Bonjour,

Il faut admettre que le cas fréquent d'utilisation des modèles de base est la communication avec des capteurs divers, qui eux sont en esclaves.

Alors il reste éventuellement cette solution là:

J'ignore quel est votre projet, mais vu la différence de prix entre un 20M2 et un 20X2, c'est vraiment faire le choix de choses compliquées à réaliser et à configurer!

La gamme Picaxe et assez étendue et bon marché pour permettre le meilleur choix en fonction de son problème.
Mais ne serait-ce pas lié à ce sujet ancien : http://www.picaxeforum.co.uk/showthread.php?20873-Piloter-un-LCD&p=201026&viewfull=1#post201026 ?

 

[micharmi]

non, (la 1° question, c'est simplement la réalisation d'un pavé au moindre cout et pouvant être utilisé dans n'importe quel projet)

j'explore différentes solutions de réseau, pour un projet pour lequel j'ai besoin:

1- d'un réseau d'une vingtaine de mètres (éventuellement extensible localement)
(au delà, il est envisageable de réaliser un dialogue locale entre un des Picaxe réseau, avec un Picaxe process spécialisé gérant un bus 1-wire ou un I2C ou autre ....par exemple avec un abonné d'un 2° réseau du même principe permettant ainsi de prolonger le réseau à 40m, etc....)
2- avec 7/8 micro-contrôleurs répartis sur ce réseau (voir plus)
3- avec 1/2 entrées et 1/ 2sorties localement (voir plus en utilisant d'autres Picaxes)
4- avec un peu d'algorithme à y intégrer pour le process
5- peu de flux sur le réseau

Cette solution me plais bien, car

1- très souple le maitre,( du point de vue de la synchronistion des échanges) ne gère que le cadencement du réseau, au final, on dispose d'un pseudo réseau à "jeton" comme ceux réalisés en automatisme API
Son programme est standard et utilisable dans n'importe qeulle application utilisant ce type de réseau
2- communication entre Picaxes (genre diffusion), donc mis à part le cadencement donné par le maitre,
pas de limite dans les échanges entre les Picaxes abonnés
3- possibilité d'étendre le nombre d'abonnés facilement
4- communication avec seulement 2 fils au lieu de 4 et pas besoin de catégorie 5
5- possibilité d'utiliser simplement des 08M2 (et même des 08M seulement, d'après l'auteur)
voir si besoin d'y intégrer 1/des 14M2 ou 18M2 ou 20M2 ou n'importe quel Picaxe X2... pour un besoin spécifique d'un ou x abonnés
6- possibilité d'alimenter les Picaxes soit par le réseau soit en local (au choix de l'utilisateur, suivant la construction)
7- reconnaissance des nouveaux abonnés automatique par le Maitre (ou plutôt "gestionnaire de cadencement du réseau" est plus adapté) avec intégration / retrait automatique des apparition/disparition d'abonnés, et sans modifier le code du Maitre
8- coût très inférieur à une solution mettant en oeuvre un I2C bus via des Picaxes xxX2 (inutiles du point de vue des process) comme Esclaves et auxquels il faudrait adjoindre des "I2C Extender de bus" genre P82B715P
9- le code des échanges pour les abonnés est standard sur tous les abonnés
Le programme process n'a besoin que d'échanger les données et quelques identifiant pour utiliser ce programme réseau
10- le principe, le hardware et le code ont déjà été mis en oeuvre et testés
11- on peux envisager (je pense, moyennant quelques modifications Hard et Soft) d'installer 2 Picaxes Maitre sur le réseau (un en gestionnaire du réseau, l'autre en surveillance, de façon à réaliser un secours automatique du Maitre en cas de défaillance)
12- le seul point difficile est le fait que tout l'article et commentaires du code est en Anglais et que je dois réaliser un travail important (déjà commencé) pour le traduire car je ne maitrise pas cette langue...
j'ai bien envie de faire une maquette de cette solution:

car tout ce que j'ai trouvé jusqu' à maintenant est du type maitre esclave (pour ce qui est des échanges) et donc si des esclaves doivent communiquer entre eux, c'est le maitre qui doit prendre les initiatives et interroger tous les esclaves, pour éventuellement rediffuser à chacun des autres esclaves concernés.
En effet, dans les solution standards,
pour savoir si un abonné à besoin de transmettre une information,
le maitre doit interroger en permanence tous les abonnés un à un
puis si l'un deux doit transmettre,
le lire puis retransmettre un à un à chacun des autres abonnés concernés
Ceci a pour effet de générer un sur-trafic permanent, important, et inutile sur le réseau
(du point de vue des informations réelles à transmettre)
et donc cela ralentis l'échange des informations process à transmettre
(les informations échangées pour mettre en oeuvre la gestion des échanges pouvant être plus importantes que les informations échangées pour le process)
par rapport à cette solution.

 

[PieM]

Alors, oubliez le bus I2C qui n'est pas fait pour ces longueurs, et n'a aucune immunité au bruit...

 

[micharmi]

Alors, oubliez le bus I2C qui n'est pas fait pour ces longueurs, et n'a aucune immunité au bruit...

ben le bus I2C avec des I2C bus extender P82B715P permet pourtant d'atteindre ces longueurs
Le milieu concerné n'est pas perturbé

http://www.ti.com/lit/ds/symlink/p82b715.pdf

I2C Bus Operation Over 50 Meters of
Bus Signals Twisted-Pair Wire
· Allows Bus Capacitance of 400 pF on Main I2C ·
Latch-up Performance Exceeds 100 mA Per
Bus (Sx/Sy Side) and 3000 pF on Transmission JESD 78, Class II
Side (Lx/Ly Side) · ESD Protection Exceeds JESD 22
· Dual Bidirectional Unity-Voltage-Gain Buffer
With No External Directional Control Required
· Drives 10´ Lower-Impedance Bus Wiring for Improved Noise Immunity
– 400-V Machine Model (A115-A)
– 2500-V Human-Body Model (A114-A)
– 1000-V Charged-Device Model (C101)

 

[westaust55]

Membre du forum InglewoodPete sur le forum Anglais a fait des travaux dans le passé à l'aide de copeaux de l'autobus-extendeur pour un réseau i2c.
Cependant, il a été à l'aide de plusieurs PICAXE 28X1, qui ont la capacité de maître et l'esclave.

 

[micharmi]

7 x 28X1 + 7 P82B714P: coût= 105$ + le surcout du cablage: 4 fils au lieu de 2
+ le surcoût du catégorie 5 et des connecteurs cat 5
(mais je suis pas certain que ce soit nécessaire avec les P82B715P),
mais 50m au lieu de 20m
avec le gros inconvénient de l'impossibilité de diffuser des messages d'esclave à esclave(s) directement, sans passer par de multiples dialogues à initier par le maître et avec pour conséquence la surcharge inutile du réseau et un temps de réponse multiplié par le nombre d'échanges nécessaires à cette diffusion

7 x 08M2: Coût= 21$
+ quelques $ pour les quelques composants (peu chères correspondant à la fabrication des interfaces réseau)
mais peut-être peut-on aussi augmenter la longueur du réseau même au-delà des 50m dans ce cas, en utilisant aussi un câblage de cat5, je ne sais pas?

Autrement, il y a la solution pour l'I2C, de passer en RS485 pour quelques $, comme sur cet exemple:
(auquel on peux adjoindre une isolation galvanique sur le bus en ajoutant des isolateurs numériques genre ADUM1301 ou similaire, entre les Max... et le PIC)
http://xj900diversion.free.fr/bus/I2C - RS-485 adapter.htm
Longueur maximale de 1000 mètres et 32 ​​émetteurs et récepteurs connectés.
(mais je suppose, en bas débit)
Au delà il faut passer en fibre optique
Mais bien sûr toujours avec l'inconvenient des seuls échanges de type maitre esclave et avec 4 fils câble spécifique (genre câble profibus, je crois: non, car Profibus cabl n'a que 2 conducteurs)

 

[micharmi]

La série xxM2 de PICAXE sont la nouvelle version de niveau inférieure.

La série xxX2 de PICAXE sont les puces avancées.

L'espace disponible de programme dans la puce PIC de l'interpréteur BASIC peut être une contrainte.Une autre est la nécessité de prévoir une différenciation ou supplémentaires de fonctionnalités pour les puces avancées. Cela inclut la capacité d'esclave i2c et les commandes 1-Wire, ainsi que les plus grand nombre de variables, l'utilisateur programme espace, etc.

Il me semble qu'il aurait été très intéressant, par exemple:
de faire les 08M2 et les 14M2 telle qu'ils sont en I2C Maitre
et de laisser une porte ouverte à d'autres applications,
en programmant le 14M2 en esclave uniquement (pas de fonction Maitre, ce qui n'aurait je suppose pas posé de problème en terme de capacité)
Et ainsi les possibilités de cette gamme aurait été étendues.

 

[PieM]

@ micharmi

par correction, évitez de modifier vos posts après qu'ils aient eu une réponse ...

Il est difficile de comparer des coûts d'une réalisation avec des 28X1 (post de Westaust) avec une réalisation avec des 08M2 ! on ne fait pas la même chose avec.

En I2C, il est possible de faire communiquer plusieurs maîtres via un seul esclave le bus I2C étant un bus multi maîtres.

Concernant le système Kranenborg, je suis très dubitatif du principe utilisant des pulsout, du serin /serout avec des interruptions (qui sont dépendantes des instructions de programme)!
Quant à son fonctionnement sur des dizaines de mètres sans buffer de ligne, je ne vois pas grâce à quel miracle.

Il existe une application qui fonctionne ? et à quel débit pratique ?

Sinon, si votre projet est de réaliser un réseau type industriel (vous parlez maintenant de RS485, Profibus ), il existe des µC beaucoup plus adaptés que le Picaxe.

faire les 08M2 et les 14M2 telle qu'ils sont en I2C Maitre et de laisser une porte ouverte à d'autres applications, en programmant le 14M2 en esclave uniquement

Ce n'est pas une question de programme mais de possibilité de µC pic de base.

 

[micharmi]

"Sinon, si votre projet est de réaliser un réseau type industriel (vous parlez maintenant de RS485, Profibus ), il existe des µC beaucoup plus adaptés que le Picaxe."
1- Je parle de RS485 car je donne un exemple qui permettrait de communiquer avec l'I2c en RS485, mais je ne souhaite pas le mettre en oeuvre.
C'était simplement en réponse aux limites théoriques du bus I2C de quelques dizaines de cm. Il semble qu'il existe des possibilités mises en oeuvre par d'autres et c'est ce que je regarde et transmet.
2- de Profibus (c'est uniquement du câble dont je parle....), et pourquoi pas l'utiliser s'il peux répondre à un besoin?
Je parle aussi de catégorie 5 et vous ne me dites pas en réponse que je veux construire un réseau informatique
3- j'ai une expérience dans le domaine automatisme et je me réfère donc à ma culture.
4- je ne souhaite pas faire une application industrielle, mais personnelle dans le domaine de l'habitat
"Ce n'est pas une question de programme mais de possibilité de µC pic de base."
5- je voulais bien parler du contenu du µC, le terme "programme" est certainement mal adapté! je ne sais pas si c'est la couche logicielle embarquée dans le picaxe ou sa fabrication qui est concernée?

@ micharmi
Il est difficile de comparer des coûts d'une réalisation avec des 28X1 (post de Westaust) avec une réalisation avec des 08M2 ! on ne fait pas la même chose avec.

D'accord, mais si le 08M2 me suffit, pourquoi utiliser un 28X1?

@ micharmi
En I2C, il est possible de faire communiquer plusieurs maîtres via un seul esclave le bus I2C étant un bus multi maîtres.

Avec toujours le même inconvénient de multiplier le nombre de messages simplement pour échanger une données depuis 1 maitre vers les x autres maitres concernés: c'est réaliser beaucoup de communication pour quelques échanges....
Celà ne me semble pas la meilleure approche.

@ micharmi
Concernant le système Kranenborg, je suis très dubitatif du principe utilisant des pulsout, du serin /serout avec des interruptions (qui sont dépendantes des instructions de programme)!

Il faut quand même tenir compte:
1- que le programme de application ne gère que 1 à 2 IN et 1 à 2 OUT
2- donc la charge 08M2 est disponible pour la communication réseau qui est très faible du fait du principe de "diffusion de messages" par rapport à toutes ces solutions Maitre-esclave
Par ailleurs si besoin de tâches importantes dans un esclave, alors il prévois de mettre un 08M2 dédié à la communication du réseau principale et de faire communiquer ce 08M2 avec un Picaxe ou autre

Je vous prie de m'excuser pour les modifications intervenues mais elles ne me semblaient pas remettre en cause le contenu des réponses (Je ne le ferais, plus, encore milles excuses aux autres intervenants concernés)

 

[PieM]

Concernant la gamme X2 la gestion des I2C master et slave est faite dans la puce Microchip (16F872 pour le28X2)
par contre pour le 14M2 (16F684), rien concernant l'I2C n'existe. L'I2C master est donc je pense développé par Rev-Ed. Par contre le slave nécessite des possibilité hardware (écoute tache de fond).

Vu le faible débit du principe Kranenborg : "At 8MHz a maximum throughput of over 20 messages per second (equals 40 bytes of information) can be reached."
donc pour une application qui ne semble pas avoir besoin de forte réactivité, pourquoi ne pas envisager le principe de la liaison série en chaînage entre les différents composants, chacun recevant le message du précedent et le répercute sur le suivant, jusqu'au maître. Idem au retour. Chaque picaxe ajoutant au message précédent, le sien dans un sens ou lisant celui qui lui est destiné, dans l'autre sens .

 

[PieM]

Avec toujours le même inconvénient de multiplier le nombre de messages simplement pour échanger une données depuis 1 maitre vers les x autres maitres concernés: c'est réaliser beaucoup de communication pour quelques échanges....
Celà ne me semble pas la meilleure approche.

Je ne vois pas en quoi il y a multiplication des messages avec l'I2C!
Chaque Picaxe écrit et lit dans le scratchpad de l'esclave à une adresse définie à l'avance. et cela se fait en tâche de fond pour l'esclave, qui en l'occurrence reste le maître de la gestion des données échangées.
C'est très rapide et ça ne demande pas des 10 de lignes de programmation rien que pour transmettre une température!

J'utilise ce système pour des applications demandant des temps de réponse relativement courts entre plusieurs picaxes et capteurs divers ( sonar, compas, accéléromètres), sans aucun problème.

Quant à la charge réseau, le système Kranenborg transmettant 40 bytes utiles par seconde ne me semble pas un modèle d'optimisation de communication.

 

[micharmi]

Oui j'avais pensé à cette solution, l'ennui c'est que j'ai peu d'informations à transmettre et pas simultanément, mais je souhaite une rapidité de transmission lorsque l'ordre de transmettre un message est détecté par un esclave.
Par ailleurs la disparition d'un abonné avec cette façon de faire condamne le réseau
certes la solution suivant le principe de Kranenborg a un faible débit, mais ceci est compensé par:
1- la notion de "diffusion de message" ce qui fait que pour émettre un message le temps de réponse est seulement le temps d'attente du créneau d'émission affecté à un esclave + le temps d'émission de son message, uniquement.
2- l'absence de circulation des messages redondants et inutiles (du point de vue process), induit par cette solution ou les autres (maitre/esclaves), en effet pour que tous les abonnés réceptionnent le message, on va avoir:
a) le temps d'attente pour prendre son tour dans la possibilité d'émettre,
b) le temps d'émission du message de l'initiateur du message
c) et pour 7 abonnés par exemple: 6 x le temps de réémission du message initiale
plus les temps d'attente inter messages
soit environ, 10 fois plus de communication! et 6 fois plus de messages devant circuler sur le réseau
N.B.: calculs rapides et certainement à affiner
donc finalement en communiquant 10 fois plus vite, on ne fera pas mieux! et on perdra du temps, en terme de réactivité

En conclusion le "temps de réactivité" est avec le principe de Kranenborg
le temps d'attente de l'autorisation d'émettre + le temps d'émission d'un message qui existe dans toute application .... et celà quelque soit le nombre de destinataire(s) du message
Ce temps est pratiquement fixe et peut être déterminé d'avance par mesure ou calcul: 1000ms / 20 msg/s, soit <50ms/msg + le temps d'attente d'autorisation pour emettre = temps de réactivité (cela me suffit amplement)

et après cette simple émission, le réseau est à nouveau disponible pour le/les autres abonnés qui auront besoin d'émettre vers 1 ou l'ensemble des abonnés (un seul message a circulé sur le réseau)

Enfin, si je veux rajouter 1/des abonnés sur le réseau, je n'ai pas besoin de modifier les autres abonnés du réseau, si le nouvel abonnél utilise un process déjà connu
Je n'aurais à les modifier que si je rajoute un nouveau process ayant une interraction sur les procédés existant

 

[PieM]

Voir le sujet http://www.picaxeforum.co.uk/showthread.php?7694-quot-SerialPower-quot-true-two-wire-data-power-network

Finalement pas encore d'exemples fonctionnels ... et ça n'a pas soulevé l'enthousiasme des foules.

mais je souhaite une rapidité de transmission lorsque l'ordre de transmettre un message est détecté par un esclave.

Un réseau basé sur l'utilisation d'interruptions avec un système interprété ne peut assurer qu'une rapidité aléatoire... La limite atteinte de la liaison série semble par ailleurs assez faible , et la gestion des interruptions perturbe en outre les programmes. pause, pulsin, pulsout servo, pwm sont directement en conflit avec elles.

Je lit l'intensité de moteurs, configure leurs vitesses, lit un sonar en mouvement, un compas et deux accéléromètres 50 fois par secondes en échangeant entre capteurs, deux 08M2 deux 18M2 et un 28 X2...

Mais il faut des pionniers partout...

bonne chance.

 

[micharmi]

Voir le sujet http://www.picaxeforum.co.uk/showthread.php?7694-quot-SerialPower-quot-true-two-wire-data-power-network

Finalement pas encore d'exemples fonctionnels ... et ça n'a pas soulevé l'enthousiasme des foules.



Un réseau basé sur l'utilisation d'interruptions avec un système interprété ne peut assurer qu'une rapidité aléatoire... La limite atteinte de la liaison série semble par ailleurs assez faible , et la gestion des interruptions perturbe en outre les programmes. pause, pulsin, pulsout servo, pwm sont directement en conflit avec elles.

Je lit l'intensité de moteurs, configure leurs vitesses, lit un sonar en mouvement, un compas et deux accéléromètres 50 fois par secondes en échangeant entre capteurs, deux 08M2 deux 18M2 et un 28 X2...

Mais il faut des pionniers partout...

bonne chance.

effectivement si vous faites cela 50 fois par seconde ce n'est plus dans la même cours,
mais jusqu'à présent personne n'avait donné d'indication sur les vitesses obtenues, mis à part kranenborg!

Mais je n'ai rien trouvé concernant la manière de mettre 7 x 08M2 Maitre I2C + un xxX2 esclave sur un réseau et de gérer les conflits!
Et puis comme tous les maitres devront surveiller en même temps et en permanence l'esclave (scratchpad) pour vérifier s'ils doivent lire une données provenant d'un autre Maitre: j'ai de la difficulté à imaginer un tel fonctionnement ou pour échanger une information réelle de temps en temps il faut que tous les utilisateurs communiquent en permanence et presque simultanément avec un destinataire unique
en terme imagé, cela me fait penser à une réunion de 8 personnes ou les 8 personnes parlent continuellement en même temps....., sans jamais écouter les autres

"pwm sont directement en conflit avec elles." oui, celà me gêne
Pause, je crois avoir lu dans un de vos posts que l'on peux utiliser d'autres instructions
pulsin, Pulsout , servo je pense pas avoir à les utiliser (dans l'immédiat)

 

[PieM]

Il n'y a pas 8 personnes qui parlent en même temps !
Il n'y a rien à surveiller, chacun va écrire et lire les données qui le concernent dans le scratchpad à des adresses bien précises, au rythme lié aux besoins du process. Certaines infos peuvent être lues et utilisées par plusieurs maîtres, tout comme certaines données ne sont utilisées que par le µC central qui peut les remettre en circuit après traitement.
Il est même très simple d'instituer une procédure de handshake.

Si votre fréquence d'échange est faible, je pense que l'I2C viendra à bout d'éventuel conflits. C'est le principe même du multi-maître...

 

[westaust55]

Pour la série de pièces PICAXE M2, les puces PIC natic comprennent un module MSSP SPI et i2c interface de communications. Voir la fiche technique de PIC16F1825 qui représente le 14M2 ou le PIC12F1840 qui représente le 08M2.
L'i2c et SPI comms permettre un fonctionnement maître et esclave ( PIC16F1825 dataheet pages 243 et 244).

Mes pensées seulement, mais les motifs probables que révolution de l'éducation (Rev Ed) ne comprennent pas le mode d'esclave i2c pour les parties de M2 est :

1. Pour fournir un degré de séparation fonctionnelle ou la distinction entre les M2 et X2 pièces

2. Les puces PIC utilisés pour la série M2 ont un total de 8 kilo-octets d'espace du programme. La moitié utilisée pour le firmware (programme d'amorçage et BASIC interprète) et l'autre moitié est disponible pour le programme de base utilisateurs. Par comparaison, les X2 pièces ont 8 kilo-octets pour la 20X2 et 32 kilo-octets pour les 28/40X2 puces à moitié utilisé pour le firmware intrinsèque et la moitié restante pour l'utilisateur des programmes BASIC.
Les plus peu d'espace (2 kilo-octets) dans les parties de M2 pour le firmware, il y a une restriction quant aux caractéristiques totales qui peuvent être mises en &#339;uvre. Comparaison avec les premières parties de « M », qui avaient seulement 1 Ko d'espace du firmware, les parties M2 ont ajouté plusieurs nouvelles fonctionnalités, y compris i2c Master mode, cependant il est a, quant à combien de nouvelles fonctionnalités peuvent être pressées dans les disponibles 2 Koctets espace, programme qui doit être tempérée par la majorité des utilisateurs est susceptible d'utiliser les fonctionnalités de la GI-TI.

 

[micharmi]

Il n'y a pas 8 personnes qui parlent en même temps !
Il n'y a rien à surveiller, chacun va écrire et lire les données qui le concernent dans le scratchpad à des adresses bien précises, au rythme lié aux besoins du process. Certaines infos peuvent être lues et utilisées par plusieurs maîtres, tout comme certaines données ne sont utilisées que par le µC central qui peut les remettre en circuit après traitement.
Il est même très simple d'instituer une procédure de handshake.

Si votre fréquence d'échange est faible, je pense que l'I2C viendra à bout d'éventuel conflits. C'est le principe même du multi-maître...

J'ai quand même besoin que chaque abonné Maitre sache en permanence et le plus rapidement possible (enfin je me comprends je ne cherche pas la ms) si l'un des autres abonnés Maitre a écris une information dans le scratchpad:
Donc je devrais en permanence initiér une lecture du scratchpad par chacun des Maitres afin de savoir si une information a été émise par l'un des autres Maitres et dans ce cas la lire et agir sur son process en conséquence. C'est ce principe qui me gênait dans la manière de procéder car j'initie des communications en permanence (trafic sur le réseau) et 99% du temps pour rien
S'il n'y a rien à gérer au niveau des conflits cela me rassure, car je ne comprenais pas du tout comment faire, mis à par tirer une ligne supplémentaire de synchronisation....

 

[PieM]

C'est ce principe qui me gênait dans la manière de procéder car j'initie des communications en permanence (trafic sur le réseau) et 99% du temps pour rien

C'est cette "angoisse" que je ne comprends pas. Que vous importe qu'il y ait du trafic pour "rien". Je le comprendrais si la bande passante était critique vis à vis de votre process, mais ce n'est pas le cas .
Quand vous avez une liaison WiFi, vous ne la mettez pas en stand by sous prétexte qu'il n'y a rien à transmettre ...
D'autre part, tout dépend de votre process local: si vous attendez une info pour dire qu'une porte a été ouverte, ou qu'il faut fermer un store, vous n'avez pas besoin d'initier une lecture toutes les 100ms. de la même façon, si vous mesurez une température, à moins de faire une régulation pointue (qui peut être traitée en local), vous n'avez pas besoin d'une grande fréquence de rafraîchissement des données.

Avec le systeme Kranenborg, chaque esclave est à l'écoute permanente via un serin déclenché par une interruption, d'un message qui lui est destiné ou pas.

 

[PieM]

@ Westaust:

Pour la série de pièces PICAXE M2, les puces PIC natic comprennent un module MSSP SPI et i2c interface de communications. Voir la fiche technique de PIC16F1824 qui représente le 14 M 2 ou le PIC12F1840 qui représente le 08 M 2.

Selon Rev-Ed : http://www.picaxe.com/What-is-PICAXE/Superseded-Parts/

14M2 = PIC 16F684 (sans SPI / I2C)

 

[micharmi]

bien entendu la vitesse me conviendra,
mais avouez tout de même qu'un système
qui n'émet que lorsqu'il a besoin d'émettre est quand même intellectuellement parlant (au minimum) plus approprié,
même s'il doit être à l'écoute en permanence, ce qui ne me choque pas: c'est le cas de tout esclave sur un bus quel qu'il soit

 

[PieM]

bien entendu la vitesse me conviendra,
mais avouez tout de même qu'un système
qui n'émet que lorsqu'il a besoin d'émettre est quand même intellectuellement parlant (au minimum) plus approprié,
même s'il doit être à l'écoute en permanence, ce qui ne me choque pas: c'est le cas de tout esclave sur un bus quel qu'il soit

Personnellement, le principe d'avoir de "l'intelligence" déportée traitant localement des données et échangeant uniquement en fonction des besoins ne me choque pas.

C'est dans le principe, ce qui est fait (d'une manière plus industrielle et sécurisée) avec le bus CAN (multi-maîtres) généralisé dans l'automobile.

Je pense également que de vouloir créer un principe de réseau en utilisant un langage interprété, est voué à des restrictions qui le condamnent.

 

[micharmi]

c'est pourtant ce qui est utilisé dans tous les réseaux industriels d'API et cela a fait ses preuves (enfin, interprété pour la couche utilisateur)
mais là par comparaison entre la couche I2C et le programme utilisateur bien entendu

 

[PieM]

c'est pourtant ce qui est utilisé dans tous les réseaux industriels d'API et cela a fait ses preuves (enfin, interprété pour la couche utilisateur)
mais là par comparaison entre la couche I2C et le programme utilisateur bien entendu

Dans les réseaux utilisés par les API, la gestion du réseau n'est pas faite par un langage interprété. Profibus et autres utilisent des circuits spécifiques (ASIC) sur les cartes d'interface, qui sont dédiés à ce job.

On peut toujours faire du bit banging, mais ça ne se fait pas en basic interprété.

 

[westaust55]

@ Westaust:

Selon Rev-Ed : http://www.picaxe.com/What-is-PICAXE/Superseded-Parts/

14M2 = PIC 16F684 (sans SPI / I2C)

PIC16F684 est la partie soldes de début 14M

Pour la 14M2 et d'autres plus récente pièces voir :http://www.PICAXE.com/What-is-PICAXE/PICAXE-Chip-labels/

Le lien il vous mènera à la datasheet/fiche technique pour 16F1825 très similaire à 16F1824 que je l'ai mentionné, qui comprend i2c

 

[micharmi]

Finalement, je viens de trouver des 20X2 à 5.6&#8364; % à 2.4&#8364; pour le 08M2
Avec 7 20X2 cela ne conduit qu'à un surcout de 22.4&#8364; et alors on peux faire ceci
tous les 20X2 sont en esclave
lorque l'un d'entre eux doit émettre on le reconfigure en Maitre (par programme)
il émet vers chaque esclave, successivement
puis on le reconfigure en esclave,
etc...
l'émission est ainsi immédiate (t d'émission de 6 msg) lors de la détection du besoin
et la communication minimale sur le réseau, donc le réseau reste disponible pour d'autres usages futurs

 

[PieM]

l'émission est ainsi immédiate (t d'émission de 6 msg) lors de la détection du besoin
et la communication minimale sur le réseau, donc le réseau reste disponible pour d'autres usages futurs

Je ne comprends pas trop l'organisation de votre système, en particulier du qui fait quoi...
Chaque esclave diffuse donc ses données à chaque autre esclave, à charge pour eux d'utiliser les données qui les concernent ?
Si vous avez 7 esclaves, chacun va être tour à tour maître et diffuser ses données sur les 6 autres ? soit 42 communications ?
Quant au volume des messages ils sera limité à 21 byte, le scratchpad d'un 20X2 étant de 128 bytes.

Chaque message devra donc contenir l'étiquette des données reçues, ou bien se positionner à une adresse mémoire correspondant toujours à la même donnée, afin que le récepteur sache à quoi il a affaire ...

Si vous avez besoin de transmettre une donnée d'un esclave à un autre, vous avez donc 6 communications, alors qu'il n'en faut que deux sur un réseau maître, comme celui que j'utilise, tout en ayant l'ensemble des données accessible à tous.

 

[micharmi]

Dans mon système,
1- chaque abonné exécute son process (c'est logique...)
2- parfois (flux faible) transmet dans le cas maximum une information à l'ensemble des abonnés (et pourquoi pas???)
3- les abonnés réagissent et modifient leur activité en fonction de cette information (pourquoi pas???)
4- le volume des msg me suffit (1 byte= bien un octet, donc 21 octets par abonné), par ailleurs,
je peux envisager un reconditionnement des données par l'esclave pour les traiter et les compacter
il y a aussi la possibilité d'étendre les données avec un indicateur de type de données, ou de process
enfin, pour cela, j'ai des solutions
Par ailleurs, cette limite, ce n'est qu'en réponse à ce que vous affirmez:
en réalité pour moi, je n'ai pas cette limite, car
a) un abonné écrit le scratchpad (au maxi la totalité - 2 bytes qui sont réservés à un usage spécifique)
b) l'esclave le traite (éventuellement) puis l'émet vers chacun des abonnés qui en sont destinataires
c) a la fin de cette émission, le scratchpad est à nouveau disponible
d) n'importe quel esclave peux devenir Maitre à tout instant et émettre suivant la même procédure

Alors je n'ai pas tout compris dans ce que vous avez dit
je vois pas comment dans votre réseau: soit avec 6 maitres et un esclave,
vous allez pouvoir diffuser de chaque maitre vers l'ensemble des autres maitres avec seulement 2 messages???
Avec 1 msg vous envoyez les données dans le scratchpad, et puis après?
Peut-être imaginiez vous que l'esclave était le seul destinataire (je ne comprends pas votre solution)

oui, effectivement dans le pire des cas, j'ai besoin de transmettre d'un abonné vers tous les autres abonnés
je parle de cela depuis le début en me référant au réseau Serial Power, qui lui permet la "diffusion" de msg vers l'ensemble des abonnés!!

 

[PieM]

relisez ce que j'ai dit :

Si vous avez besoin de transmettre une donnée d'un esclave à un autre, vous avez donc 6 communications, alors qu'il n'en faut que deux sur un réseau maître, comme celui que j'utilise

la diffusion se fait d'un maitre vers un esclave (28X2 dans mon cas, le patron du système) et chaque maître va lire l'information qu'il veut, quant il veut. C'est en ce sens que je dis que toutes les infos sont disponibles à la lecture par tout le monde.
donc transmettre une donnée d'un maitre à un autre demande 2 communications: une en écriture, l'autre en lecture.
Avec six maitres il suffit de 12 communications pour échanger toutes les données .

Si vous ne faites pas de diffusion générale, cela veut dire que chaque esclave sait quelles données envoyer à quel destinataire ?
Une modif de votre circuit (ajout d'un esclave) supposerait de reprendre tous les programmes pour tenir compte du nouvel arrivant ?

 

[micharmi]

la diffusion se fait d'un maitre vers un esclave (28X2 dans mon cas, le patron du système)
et chaque maître va lire l'information qu'il veut, quant il veut.
et comment le Maitre concerné sait-il qu'un msg est arrivé et qu'il doit le lire? (je rappelle que le msg est urgent et qu'il doit être communiqué le plus rapidement possible s'il est du type évènementiel)
, si ce n'est en allant lire l'esclave? et au gré de la décision du Maitre destinataire du msg qui ne connais ni son existence, ni son contenu à l'avance!: DONC une lecture x 6 Maitres en permanence, donc beaucoup de msg ou à moins que vous n'appeliez pas ça un msg? il en reste que c'est une lecture donc du temps sur le réseau et du trafic et du temps de perdu en terme de réactivité
C'est en ce sens que je dis que toutes les infos sont disponibles à la lecture par tout le monde.seulement ce n'est pas une tâche évènementielle, personne ne sais à l'avance qu'il a un msg à lire
donc transmettre une donnée d'un maitre à un autre demande 2 communications: une en écriture, l'autre en lecture.parce que vous ne comptez pas les msg de détection de l'arrivée de msg, vous raisonnez comme si tout Maitre savait par avance qu'un msg est disponible et qu'il est le moment précis de le lire
Avec six maitres il suffit de 12 communications pour échanger toutes les données .il ne s'agit jamais d'échanger toutes les données mais d'échanger "les données qui viennent d'arriver d'un abonné" d'un maitre vers le(s) maitre((s) concernés et le plus rapidement possible. Il semble que vous raisonniez en terme de "collecte de données" et non pas de transmission de "données de type évènementiel" . La donnée de type événementielle est périmée dès lors qu'elle a été transmise et n'a donc pas à être stockée, sauf à faire un journal des évènements éventuellement, cela devient alors en plus de l'évènement, une donnée de collecte de type événementielle. Mais je peux également traiter cette donnée et des données de type collecte, bien entendu, ça ne change rien au principe, il suffit que je dédie un abonné au stockage des données

 

[micharmi]

relisez ce que j'ai dit :

Si vous avez besoin de transmettre une donnée d'un esclave à un autre, vous avez donc 6 communications, alors qu'il n'en faut que deux sur un réseau maître, comme celui que j'utilise


Si j'ai besoin de transmettre une donnée d'un esclave à un autre: je n'ai qu'une communication, dans mon cas
Rappel: j'ai écris celà dans le post initiateur de cette nouvelle discussion
lorque l'un d'entre eux doit émettre on le reconfigure en Maitre (par programme)
il émet vers chaque esclave, successivement
puis on le reconfigure en esclave,Bien entendu s'il n'y a qu'un seul destinataire du msg il n'émet qu'un seul msg et se reconfigure en esclave. De ce fait il n'y a même eu qu'un seul msg pratiquement en temps réel....

 

[micharmi]

Si vous ne faites pas de diffusion générale, cela veut dire que chaque esclave sait quelles données envoyer à quel destinataire ?
dans tous les cas, il faudra bien que quelqu'un décide de ce qu'il fait en termes de msg, que ce soit répartis dans les Abonnés ou intégrés massivement dans l'Esclave
Une modif de votre circuit (ajout d'un esclave) supposerait de reprendre tous les programmes pour tenir compte du nouvel arrivant ?

Dans votre cas, il faudra bien modifier les Maitres concernés (voir les autres si remise en cause de l'adressage du scratchpad), ainsi que l'esclave avec son scratchpad, pour traiter la nouvelle information s'il la gère, et les modifier, non?
Dans mon cas les Abonnés non concernés par le msg ne sont pas à modifier.


si j'utilisais votre principe, je le ferais pour réaliser à la fois un stockage de données et une diffusion d'évènements:
Maitre --> Ecris l'Esclave stockant les données
Esclave -- analyse, -- sépare les données et les évènements, puis si évènements présents, les répercute --> vers le(s) Maitre(s) concernés (sans attendre que ceux-ci viennent le lire
Les Maitres ne feraient dans ce cas que écrire l'Esclave
MAIS: L'Esclave, lui écrirait les Maitres
(tout cela, bien entendu par retournement des fonctions Maitre/Esclaves)
Tout le monde étant Esclave quand il n'y a rien à transmettre, et le réseau est "Disponible en permanence"!! et en terme de réactivité, cela me semble la solution la plus rapide

 

[PieM]

Dans votre cas, il faudra bien modifier les Maitres concernés (voir les autres si remise en cause de l'adressage du scratchpad), ainsi que l'esclave avec son scratchpad, pour traiter la nouvelle information s'il la gère, et les modifier, non?
Dans mon cas les Abonnés non concernés ne sont pas à modifier.
[/COLOR]

En ce qui concerne le réseau de maîtres, bien évidemment le nouveau va avoir son programme qui va gérer ses propres données et l'adresse de l'esclave pour échanger les données pouvant l'intéresser lui, et les autres abonnés. Il n'y a pas à modifier le scratchpad sous prétexte qu'il y a de nouvelles info à traiter.
Et il n'y aucune table de gestion des adresses I2C et des données liées à gérer dans chaque picaxe.

Votre soucis principal semble être la réactivité face à un évènement et l'utilisation à minima d'un réseau !
d'un autre coté, sous ce prétexte, vous envisagiez d'utiliser un système à base de liaison série 2400 bauds plafonnant pratiquement à 40 bytes par seconde ... je suis un peu perplexe.

pour ce qui me concerne ce que je vous ai décrit satisfait amplement des besoins sans doute pas aussi pointus que votre projet, mais qui permet tout de même une très bonne réactivité sur certaines applications robotisées et protos paramédicaux. Quant aux trafics réseau malgré des lectures/écritures permanentes, et un mode slow, il est loin d'être saturé.

Seulement ce n'est pas une tâche évènementielle, personne ne sais à l'avance qu'il a un msg à lire

Quand j'ai un accéléromètre qui change de valeur, je n'attends pas qu'il me dise qu'il a changé pour lire sa valeur. (d'ailleurs ils ne le fait pas) par contre je vais le lire aussi souvent que le nécessite mon process.

Après, appeler ça partage de données, principe évènementiel, c'est de la philosophie ...
Si on veut un vrai réseau performant de grande longueur , sans réinventer l'eau chaude, il suffit de créer un réseau CAN à base de PIC (et non Picaxe) et de transceiver MCP2551. Cela existe, les bibliothèques C++ existent.

PS: je vois que vous avez encore modifié votre post après coup ! Je précise donc que je ne fais aucun stockage de données. tout ce qui transite dans le scratchpad ne sont que des variables réactualisées en permanence.

 

[micharmi]

Je pense que l'on ne parle plus du même sujet: j'ai abandonné le système auquel vous faites allusion :

Votre soucis principal semble être la réactivité face à un évènement et l'utilisation à minima d'un réseau !
d'un autre coté, sous ce prétexte, vous envisagiez d'utiliser un système à base de liaison série 2400 bauds plafonnant pratiquement à 40 bytes par seconde ... je suis un peu perplexe.:
il semble pourtant évident, que + le réseau est lent, + la vigilance s'impose pour gérer au mieux la disponibilité et la charge du réseau (enfin, .... celà n'engage que moi, bien sûr! et c'est facile de tourner à la dérision en inversant la cause et l'effet!!)
Et je parle maintenant en référence à ce post:

Aujourd'hui, 15h09 #29
micharmi
micharmi est connecté maintenant
New Member
" Finalement, je viens de trouver des 20X2 à 5.6&#8364; % à 2.4&#8364; pour le 08M2
Avec 7 20X2 cela ne conduit qu'à un surcout de 22.4&#8364; et alors on peux faire ceci
tous les 20X2 sont en esclave
lorque l'un d'entre eux doit émettre on le reconfigure en Maitre (par programme)
il émet vers chaque esclave, successivement
puis on le reconfigure en esclave,
etc...
l'émission est ainsi immédiate (t d'émission de 6 msg) lors de la détection du besoin
et la communication minimale sur le réseau, donc le réseau reste disponible pour d'autres usages futurs "


Et vous, vous continuez à me parler du 1° post!!!!
c'est navrant

Bien entendu je ne remets pas en cause la capacité de votre projet et sa capacité à gérer le mien, mais peut-on discuter sérieusement d'un autre projet que le votre qui peut aussi répondre à un autre besoin, et avec une approche de solution différente, MAIS basée sur le même matériel, même réseau!!!?

par contre je vais le lire aussi souvent que le nécessite mon process.
Le mien nécessite que la lecture soit faite 24h/24 par tous les abonnés: vous pouvez comprendre (ou pas!) que je cherche d'autres solutions que celle d'initier en permanence des msg saturant ainsi le réseau?

Je ne vois vraiment pas en quoi la démarche que je vous propose vous gêne (je ne cherche qu'un avis sur la faisabilité: impossibilité ou complexité technique avec le matériel utilisé)
Je pensais que vous étiez apte à prendre en compte l'évolution de mon projet depuis le 1° post, je suis déçu car il n'en est rien!
Cordialement, et avec mes remerciements, pour tout ce que j'ai appris

 

[PieM]

Le mien nécessite que la lecture soit faite 24h/24 par tous les abonnés: vous pouvez comprendre (ou pas!) que je cherche d'autres solutions?

Je ne vois vraiment pas en quoi la démarche que je vous propose vous gêne (je ne cherche qu'un avis sur la faisabilité: impossibilité ou complexité technique avec le matériel utilisé)
Je pensais que vous étiez apte à prendre en compte l'évolution de ma démarche depuis le 1° post, je suis déçu car il n'en est rien!
Cordialement, et avec mes remerciements, pour tout ce que j'ai appris

1/ Vous avez parlé de cette solution jusqu'au post 28. je pensais que vous en parliez en connaissance de cause. Visiblement, ce n'étais pas le cas.

2/ Ensuite que la lecture soit faite 24h/24, ne change pas grand chose à l'affaire !

Désolé de ne pas être apte à comprendre votre évolution vers la complexité.
Je vous laisse donc expérimenter en vraie grandeur.

 

[micharmi]

2/ Ensuite que la lecture soit faite 24h/24, ne change pas grand chose à l'affaire !
sauf que cela donne un réseau saturé et indisponible pour autre chose, puisqu'il y a 6 communications en attente en permanence et celà pour rien, ça doit s'appeler l'optimisation des réseaux informatiques!
et vous pinaillez à côté de cela sur le fait que j'émette un msg de plus ou de moins qu'avec votre solution, pour transmettre un msg...., alors que si ce que je décris est réalisable techniquement seuls circulent de vrais msg (et 0 msg de recherche par rapport a des dizaines de millions par jour dans votre application;;; mes 1 ou 2 msg supplémentaires (ce qui est faux) vous dérangent, mais pas ceux-là!!)

1/ Vous avez parlé de cette solution jusqu'au post 28. je pensais que vous en parliez en connaissance de cause. Visiblement, ce n'étais pas le cas.
Oui, ce n'est que votre proposition avec une vitesse de réseau qui a pu m'amener à me rendre compte de la différence!

PS: je vois que vous avez encore modifié votre post après coup ! Je précise donc que je ne fais aucun stockage de données. tout ce qui transite dans le scratchpad ne sont que des variables réactualisées en permanence.
Oui, le problème c'est que lorsqu'une nouvelle page est créée, on ne vois pas l'arrivée d'un nouveau post, et aussi, un postpeut arriver pendant que l'on modifie le sien.... enfin on ne visualise pas les post en cours de frappe en pleine page.

 

[PieM]

2/ Ensuite que la lecture soit faite 24h/24, ne change pas grand chose à l'affaire !
sauf que cela donne un réseau saturé et indisponible pour autre chose, puisqu'il y a 6 communications en attente en permanence et celà pour rien, ça doit s'appeler l'optimisation des réseaux informatiques!
et vous pinaillez à côté de cela sur le fait que j'émette un msg de plus ou de moins qu'avec votre solution, pour transmettre un msg...., alors que si ce que je décris est réalisable techniquement seuls circulent de vrais msg (et 0 msg de recherche par rapport a des dizaines de millions par jour dans votre application;;; mes 1 ou 2 msg supplémentaires (ce qui est faux) vous dérangent, mais pas ceux-là!!)

1/ Vous avez parlé de cette solution jusqu'au post 28. je pensais que vous en parliez en connaissance de cause. Visiblement, ce n'étais pas le cas.
Oui, ce n'est que votre proposition avec une vitesse de réseau qui a pu m'amener à me rendre compte de la différence!

Car pour vous la saturation d'un réseau se situe au niveau de l'utilisation sur 24 H ? Quant à l'optimisation de réseaux informatiques ce n'est pas le sujet...

Vous avez décidé à priori que la solution que je vous indiquais , avec un développement logiciel minime, qui fonctionne sur des applications réelles relativement pointue, ne convenait pas à votre problème. Dont acte.

Je ne vais pas passer mon temps sur la solution concernant un moyen, pour un problème dont on je connais ni les tenants ni les aboutissants.
Bonne chance dans votre réalisation "optimisée".

PS: je vois que vous avez encore modifié votre post après coup ! Je précise donc que je ne fais aucun stockage de données. tout ce qui transite dans le scratchpad ne sont que des variables réactualisées en permanence.
Oui, le problème c'est que lorsqu'une nouvelle page est créée, on ne vois pas l'arrivée d'un nouveau post, et aussi, un postpeut arriver pendant que l'on modifie le sien.... enfin on ne visualise pas les post en cours de frappe en pleine page.

Quand on modifie un post plus d'une heure après, il ne faut s'étonner du résultat. Tous vos post sont systématiquement modifiés après parution !
C'est sans doute ce que vous appelez de l'optimisation de forum .