Envoi simultané série...

spheris

Senior Member
Bonjour,
J'ai besoin d'un petit coup de pouce pour coder la partie acquisition d'un montage météo.
J'ai une 40 aine de capteurs avec différents signaux de sortie.
J'ai donc réalisé ceci (voir schéma)
View attachment protocole.pdf
le picaxe A envoi toutes les secondes au pciaxe D.
Le picaxe B de meme et ainsi de suite.
le D quantà lui reçoit les données et les stocke dans sa mémoire.
ensuite toutes les 30 secondes, il envoi une chaine au PC par la broche programmation comme ceci :

Code:
SERTXD (mem1,";",mem2,";",mem3",";",10)
Mes questions :
le code du picaxe A :
Code:
SEROUT (C.O,C.1,C.3), B.3
c'est à peu près ça je crois..
Le code du picaxe B :
Code:
SEROUT (C.O,C.1,C.3), B.3
Le code du picaxe D,le plus délicat :
Code:
SERIN 150ms,C.0
stockage de la valeur de C.0 dans la memoire
SERIN 150ms,C.1
stockage de la valeur de C.1 dans la memoire
SERIN 150ms,C.2
stockage de la valeur de C.2 dans la memoire

attente 30 secondes
SERTXD(mem1,";",mem2,";",mem3,";",10)
Merci de votre réponse.
 

MGU

Senior Member
Bonjour,

Je pense qu'il y a un problème d'architecture.
Serout utilise un et un seul port sur le picaxe émetteur (voir syntaxe, port, vitesse, etc)
Chaque serout est relié à un serin distincte sur le récepteur commun (n'importe quelle broche compatible).
Questions:
Les liaisons sont elles filaires ou radio?
Les données sont elles byte ou word?

MM
 

BESQUEUT

Senior Member
Ce serait bien d'avoir des programmes complets et non des extraits.
Par exemple, pour D, où sont définies et lues les variables mem1, mem2 et mem3 ?

En outre, ce n'est pas une mémoire qu'il faut, mais 30 par canal, soit 90 en tout.

Concernant l'architecture : qu'est ce qui fait que les Picaxes A, B et C vont attendre sagement leur tour (dans le bon ordre) pour envoyer leurs données pile au bon moment ?
En d'autres termes, quand D attends les données de A, qu'est ce qui empêche B et C d'envoyer simultanément leurs données ?

J'ai déjà expliqué à d'autres que dans une architecture multi-processeurs, le plus simple est d'avoir un seul processeur à l'initiative des échanges (D en l'occurence), les autres ne faisant que répondre à la sollicitation. Mais ça suppose une liaison bidirectionnelle, ou a minima un "chip select" (ou handshake ce qui est la même chose)

Je précise puisque cette notion n'est pas claire pour tous, que l'initiateur est celui qui décide du moment où les données sont échangées. Si l'initiateur envoie aussi les données, le récepteur doit être capable de les recevoir "à tout moment" (on dit encore à la volée). Pas facile avec un processeur monotâche...

Il existe différentes formes de bus pour pallier à ce problème (I2C, RS485, TCP-IP, ...)
La remarque de MGU n'est pas anodine : si liaison radio, c'est comme si tous le monde émettait sur un seul fil...

L'idée est que A, B et C émettent sur le même fil, mais pas trop longtemps chacun. En outre, on fait en sorte que les fréquences d'émission soient légèrement différentes de façon à ce que la probabilité d'émission simultanée soit faible.

Le récepteur reçoit toutes les données sur le même fil ; c'est donc plus facile d'être à l'écoute en permanence, mais pas trivial quand même. Par exemple, tant que D fait sont sertxd, il n'écoute plus...
Reste à utiliser un protocole permettant d'identifier l'émetteur et aussi de détecter les émissions simultanées (conflits),
En cas de conflit, les données sont perdues. Dans votre cas, ça ne semble pas trop grave : le prochain envoi sera le bon... Il reste nécessaire de se rendre compte que les données reçues sont erronées.
Mais suivant les applications, le protocole peut prendre également en charge la ré-émission des données perdues.


Sinon, j'ai déjà programmé un processeur capable de buffériser simultanément 4 ports série à la volée. Mais c'est un Xmega, et le code n'est pas interprété mais compilé...
 
Last edited:

MGU

Senior Member
Pour simplifier,

Les émetteurs envoient des données toutes les secondes, sans synchronisation;
La réception (filaire) se fait sur des serin, un port par émetteur.
Le récepteur a une commande serin par émetteur, chaque commande attend ses données, une fois reçues, on passe au serin suivant, etc.
Il y a des données perdues, mais est ce important? Les données sont réactualisées dans ce cas toutes les 3 secondes (environ)
Toutes les données reçues en 30 secondes sont elles toutes mémorisées? Sinon, elles sont réactualisées toutes les 30 secondes.

CDC à préciser

MM
 

spheris

Senior Member
MGU, reponse au post 4
Les données seront toujours en filaire vu que les picaxes sont sur la meme cartes.
Le picaxe A par exemple recevra des valeurs de *ds18b20 sur ses 6 premieres broches et les enverrra de cette façon:

Code:
main: 'exemple pour 3
readadc10 C.0,w3
readadc10 C.1,w4
readadc10 C.2,w5
serout (#w2,#w3,#w4)B.3
pause 1000
goto main
apres, coté réception, si quelques données sont perdues, ce n'est pas trop grave.
Je ne souhaite pas de synchro. je veux eviter le dialogue. Que dans un seul sens c'est bien plus simple.
 
Last edited:

spheris

Senior Member
BESQUEUT, reponse au post 3

Par exemple, pour D, où sont définies et lues les variables mem1, mem2 et mem3 ?
C'est là que j'ai besoin de votre aide. je ne connais pas la commande pour mémoriser une valeur en mémoire dans le picaxe pour la lire et ecrire.
 

MGU

Senior Member
MGU, reponse au post 4
Les données seront toujours en filaire vu que les picaxes sont sur la meme cartes.
Le picaxe A par exemple recevra des valeurs de *ds18b20 sur ses 6 premieres broches et les enverrra de cette façon:

Code:
main: 'exemple pour 3
readadc10 C.0,w3
readadc10 C.1,w4
readadc10 C.2,w5
serout (#w2,#w3,#w4)B.3
pause 1000
goto main
apres, coté réception, si quelques données sont perdues, ce n'est pas trop grave.
Il faut juste que l'envoi toutes les 30 secondes comportent toute la chaine avec toutes les temperatures. (qui ne variera pas beaucoup en 30s)
Sans synchro ce n'est pas possible, je veux eviter le dialogue. Que dans un seul sens c'est bien plus simple.
Sans synchro voulait dire que les émetteurs émettent indépendamment les uns des autres.
Ensuite, je conseille de lire attentivement le manuel, broches utilisables, readtemp pour le ds18b20, etc

MM
 

PieM

Senior Member
Sans synchro voulait dire que les émetteurs émettent indépendamment les uns des autres.
Ensuite, je conseille de lire attentivement le manuel, broches utilisables, readtemp pour le ds18b20, etc

MM
Bien d'accord. Chaque serin étant sur une entrée dédiée, une émission toutes les secondes laisse largement le temps de recevoir 3 serin. Il n'y a aucune criticité de timing!
Et pourquoi toutes les secondes si c'est pour les enregistrer sur PC toutes les 30 secondes !?
Sinon solution simple: remplacer les A,B et C par des 20X2 et les utiliser en esclaves I2C. Le maître D allant lire les données quand il le souhaite.

spheris said:
le code du picaxe A :
Code:SEROUT (C.O,C.1,C.3), B.3


c'est à peu près ça je crois..
Ben non ce n'est pas à peu près ça! merci de faire un minimum d'effort en lisant la doc.
 

spheris

Senior Member
Sinon solution simple: remplacer les A,B et C par des 20X2 et les utiliser en esclaves I2C. Le maître D allant lire les données quand il le souhaite.
Solution très interessante. Cela veut-il dire que le maitre D a la possibilité de lire les données directement dans la memoires des A,B et C?
Auriez-vous un exemple de code ?

Et pourquoi toutes les secondes si c'est pour les enregistrer sur PC toutes les 30 secondes !?
Tout simplement parce qu'il n'y a pas que 3 picaxe A B C mais une quinzaine.


Autre question .
Quelles sont les commandes pour lire et écrire dans la mémoire d'un 20M2?
 

PieM

Senior Member
Tout simplement parce qu'il n'y a pas que 3 picaxe A B C mais une quinzaine.

Autre question .
Quelles sont les commandes pour lire et écrire dans la mémoire d'un 20M2?
15 picaxes !? Bigre !
quelle distance entre les plus éloignés ? quels types de capteurs?
merci de préciser ce que comporte le système, pour ne pas découvrir les choses au compte goutte.

j'ai parlé de picaxes X2 pour utiliser l'I2C.
 

BESQUEUT

Senior Member
C'est là que j'ai besoin de votre aide. je ne connais pas la commande pour mémoriser une valeur en mémoire dans le picaxe pour la lire et ecrire.
Voir Scratchpad et la variable @ptrinc

apres, coté réception, si quelques données sont perdues, ce n'est pas trop grave.
Je ne souhaite pas de synchro. je veux eviter le dialogue. Que dans un seul sens c'est bien plus simple.
Tellement simple que vous semblez rencontrer quelques difficultés à écrire le programme pour D...
Et tout d'un coup le bus I2C vous intéresse ? N'est-il pas bidirectionnel justement ?

Avec 15 lignes en entrée, c'est au minimum 14 trames sur 15 qui seront perdues... Mais pourquoi pas après tout...
Question timing, si les données sont émises toutes les secondes, un timout de 150ms est bien trop court.

Ces 15 Picaxes vont se tourner les puces (ou balancer des données en pure perte ce qui revient au même) en attendant leur tour.
On pourrait peut-être les utiliser par exemple à calculer une moyenne mobile ce qui améliorerait la qualité des observations...
 
Last edited:
Top