Jean-Christophe a tapoté du bout de ses petites papattes :
Si t'as un ADC sur ton proc (je suppose que c'est un µC) et qu'il n'est ni filtré ni à trop faible impédance, c'est pas mal. Y'a pas mieux que du bruit blanc pour faire de l'aléatoire. En plus tu peux faire le test en quelques minutes pour voir si ton entrée d'ADC ne tue pas le bruit.
Tiens nous au courant, j'imagine que le besoin d'un nombre vraiment aléatoire sur un µC n'est pas si rare qu'on le pense.
-- LeLapin
Jean-Christophe a tapoté du bout de ses petites papattes :
J'avais pensé à un truc comme ça, mais je ne savais pas si tu disposais d'un compteur sur la carte/le proc. Sinon le principe me semble valide.
-- LeLapin
Le 14/10/2011 18:31, Jean-Christophe a écrit :
oui, je vois, l'écoute est permanente donc.
ce qui me déplait, c'est que le maitre poole en permanence, ça va faire du trafic en permanence et n'y aurait-il pas risque de collisions avec le protocole de communication? Il faut alors que le protocole soit managé par le maitre, et donc le pool n'aurait lieu que dans les temps morts (idle)?
Oui, ça peut marcher.
JJ
On 14 oct, 20:34, jj
Oui, tous les esclaves sont toujours =E0 l'=E9coute du bus.
Attention : pour l'instant on parle de l'install du syst=E8me, cette la phase de num=E9rotation ne dure que le temps que chaque esclave ait obtenu son identifiant unique. A ce moment-l=E0, plus personne ne r=E9pond aux trames proposant un num=E9ro d'attribution, donc le maitre sait que tous les esclaves ont obtenu un identifiant.
Une fois que c'est fait, on passe en phase d'exploitation, et l=E0 il n'y a plus besoin de messages de ce type.
Seul le maitre prend l'initiative d'envoyer un message, les esclaves n'envoient jamais de message (d'eux-m=EAmes) sauf en r=E9ponse =E0 une requ=E8te explicite du maitre.
Si je comprends bien ta remarque : en cas de plantage d'une carte, celle-ci ne r=E9pondra plus aux requ=E8tes du maitre (genre r=E9cup des donn=E9es de l'esclave) donc le maitre saura bien que cette carte est HS et pourra remonter l'information plus haut. ( et dans ce cas inutile d'essayer de r=E9attribuer un N=B0 =E0 cet esclave, puisqu'il est plant=E9 il ne r=E9pondra pas)
Je le crois aussi.
( j'en profite pour remercier ceux qui ont bien voulu d=E9monter cet algo par tous les moyens imaginables ... m=EAme si la question reste ouverte )
On 14 oct, 19:51, LeLapin
| Et si je branche une pinouille d'entr=C3=A9e ADC | sur une zener polaris=C3=A9e dans son coude | histoire d'avoir un bon niveau de bruit, | et que je convertis cette tension en | un entier qui servira de valeur de d=C3=A9part : | l=C3=A0 j'aurais une proba tr=C3=A9s faible d'avoir plus | d'une carte qui d=C3=A9marre sur la m=C3=AAme valeur ?
Oui c'est un uC avec des ADC (de 10 =C3=A0 16 bits, chais pu)
pas mal.
Le fait est que sur ce uC l'imp=C3=A9dance d'entr=C3=A9e des ADC n'est pas si =C3=A9lev=C3=A9e que ca (quelques k=CE=A9 environ, et bien s=C3=BBr il y a des capas parasites) donc le signal sera att=C3=A9nu=C3=A9 et filtr=C3=A9 en passe-bas. D'autre part la dynamique du bruit de zener sera assez faible et je n'aurai qu'un delta de quelques bits par rapport =C3=A0 la pleine =C3=A9chelle de l'ADC ; donc une amplification est indispensable en plus d'une imp=C3=A9dance =C3=A9lev=C3=A9e : un seul FET suffirait. Avant tout, la seule chose qui compte est que les signaux de diff=C3=A9rentes cartes soient d=C3=A9corr=C3=A9l=C3=A9s ; pour ca, le bruit blanc est id=C3=A9al puisque sa fonction d'auto-corr=C3=A9lation est un Dirac ! (sauf que l=C3=A0, le bruit ne sera pas blanc, mais color=C3=A9)
Mais je ne veux pas non plus commencer =C3=A0 ajouter trop de hard, sinon c'est l'engrenage. Faut voir si le coup du timer est d'assez bonne qualit=C3=A9.
| Il y a m=C3=AAme plus simple sans zener ni ADC : | lire un free running timer interne au uP. | A la mise sous tension des cartes leurs mont=C3=A9es | de tension respectives ne peut pas se faire exactement | en m=C3=AAme temps ( =C3=A0 l'=C3=A9chelle de temps du cycle d'horloge ) | Donc, m=C3=AAme =C3=A0 quelques ms pr=C3=A8s, des compteurs 32 bits | qui tournent =C3=A0 quelques dizaines de MHz auront | forc=C3=A9ment des valeurs tr=C3=A9s diff=C3=A9rentes ... ok ?
Oui, il y en a. ( quartz =3D> diviseur =3D> compteur )
Oui, les g=C3=A9n=C3=A9rateurs pseudo-al=C3=A9atoires sont tr=C3=A9s facile= s =C3=A0 mettre en oeuvre et peuvent g=C3=A9n=C3=A9rer des s=C3=A9quences aussi longues qu'= on veut, et pour pas un poil de hard, mais bien s=C3=BBr ce n'est pas de l'al=C3=A9atoire ! On peut faire ressortir leur biais et dans certaines applications ca n'est plus du tout exploitable. Certains fabricants ont propos=C3=A9 des cartes PC qui g=C3=A9n=C3=A8rent u= n =C2=AB vrai =C2=BB bruit physique (dans une bande de fr=C3=A9quence sp=C3= =A9cifi=C3=A9e) avec un syst=C3=A8me =C3=A9lectronique (bruit thermodynamique ou autre)
Pour un uC ca me semble faisable facilement en num=C3=A9risant le bruit amplifi=C3=A9 d'un composant polaris=C3=A9 expr=C3=A8s. Et je suis assez curieux de voir ce que donnerait une distribution des valeurs d'un tel syst=C3=A8me : normalement ce devrait =C3=AAtre Gaussien, non ?
Le 14/10/2011 21:06, Jean-Christophe a écrit :
oui, tu peux inclure un processus de pooling permanent pour être sur de ne pas perdre le contact.
j'ai réalisé il y a longtemps un protocole avec 16 micros et un PC, et j'envoyais les infos "utiles" au plus vite, et j'avais une boucle de rafraichissement en idle qui pouvait rafraichir les esclaves déconnectés. Il s'agissait d'entrées sorties déportées.
pour la tempo aléatoire, il existe probablement ton ton UC (possède certainement des registres 'timer' que tu pourras laisser tourner à vide, tu auras un beau nombre aléatoire en lisant ce timer !
JJ
Jean-Christophe a tapoté du bout de ses petites papattes :
Tu ne peux pas choisir à ton gré les Vref+ et Vref- de l'ADC ?
-- LeLapin
On 14 oct, 23:04, jj
Si un esclave est d=E9connect=E9 du bus, je ne vois pas comment tu le rafraichirais ?
Ah non, la valeur ne sera pas al=E9atoire du tout. ( j'ai l'impression que tu ne lis pas tous les messages, ou qu'ils n'apparaissent pas tous sur ton lecteur, l'id=E9e d'utiliser un timer date d'hier =E0 18h43 ) | On 14 oct, 18:43, Jean-Christophe : | Lire un free running timer interne au uP, | =E0 la mise sous tension des cartes leurs mont=E9es | de tension respectives ne peut pas se faire exactement | en m=EAme temps ( =E0 l'=E9chelle de temps du cycle d'horloge ) | Donc, m=EAme =E0 quelques ms pr=E8s, des compteurs 32 bits | qui tournent =E0 quelques dizaines de MHz auront | forc=E9ment des valeurs tr=E9s diff=E9rentes ...
L'important est que les g=E9n=E9rateurs pseudo-al=E9atoires de diff=E9rents esclaves aient une valeur de *d=E9part* diff=E9rente, pour assurer leur d=E9synchronisation.
On 15 oct, 00:05, LeLapin
| Jean-Christophe a tapot=E9 du bout de ses petites papattes : | D'autre part la dynamique du bruit de zener sera | assez faible et je n'aurai qu'un delta de quelques | bits par rapport =E0 la pleine =E9chelle de l'ADC
Si, mais la tension cr=EAte du bruit g=E9n=E9r=E9 par un composant est tr=E9s tr=E9s faible ... cela obligerait =E0 avoir les deux Vref tr=E9s proches l'un de l'autre et c'est pas bon. Ajout=E9 =E0 la relativement faible imp=E9dance d'entr=E9e de l'ADC, je vois mal comment me passer d'un FET pour assurer =E0 la fois l'adaptation d'imp=E9dance et l'amplification.
C'est s=FBr qu'une telle source serait de meilleure qualit=E9 qu'un timer d=E9cal=E9 par les dispersions =E0 la mise sous tension, mais au final il ne s'agit que d'obtenir la valeur de d=E9part du cycle pour le g=E9n=E9 pseudo-al=E9atoire, ca ne sert qu'une fois, donc si je peux =E9viter d'ajouter un peu de hard ce serait ok.
Question suivante :
Avant de tenter l'envoi d'une r=E9ponse au maitre, vaut-il mieux que les N esclaves :
1=B0) Attendent pendant une dur=E9e al=E9atoire entre 0 et N-1. 2=B0) Ne r=E9pondent qu'avec une probabilit=E9 1/N.Je suppose que l'un doit =EAtre meilleur que l'autre ?
Le 11/10/2011 22:49, Jean-Christophe a écrit :
=================
Bonjours,
J'ai eu par le passer besoin d'attribuer automatiquement des adresse a des modules. La solution retenue au final etait de faire passer une chaine E/S par chaqu'un des modules y compris le maitre. Le maitre envoie des impulsions sur la sortie tant que son entree reste a zero. Les esclaves recopie l'etat de leur entree sur la sortie a partir de la deuxiemme imulsion recu. En fin de compte, lorsque le dernier esclave recois sa deuxiemme impulsion, le maitre s'arrette et connait le nombre d'esclave present (nombre d'impulsion emise -1). Chaque esclave ayant recu un nombre d'imulsion differentes, il lui suffit d'utiliser ce nombre comme addresse (nombre d'impulsion recu -1).
On sait aussi que les esclave son numeroté dans l'ordre de cablage de la chaine.
On 15 oct, 16:48, JiMPulse
C'est =E0 dire, une Daisy Chain ? Dans mon cas, tous les modules sont en parall=E8le sur le m=EAme bus ; il n'y a donc pas de chainage s=E9riel entre eux.
Ok. L'avantage est qu'il n'y a pas d'al=E9atoire, c'est totalement d=E9terministe, et la dur=E9e totale est strictement proportionnelle au nombre d'esclaves.
Oui, contrairement =E0 mon algo qui n'induit pas de relation d'ordre alors que ce serait assez int=E9r=E9ssant d'en avoir une. Mais comme je disais, la topologie est d=E9ja existante : bus RS485 avec tous les modules en parall=E8le.
Jean-Christophe a tapoté du bout de ses petites papattes :
Il est vrai que j'ai toujours utilisé un ampli-op (généralement un TL07x) derrière la diode pour faire ce genre de choses. C'est pour ça que je te demandais pour l'impédance et la capacité de l'entrée de l'ADC.
En repensant aux sources possibles de valeurs aléatoires, je me suis dit qu'un micro (genre electret) pourrait faire l'affaire : pas de hard supplémentaire, juste 3 fils, et c'est le bruit ambiant local qui ferait le boulot. Ca se teste, ça m'étonnerait que tous les electrets donnent pile la même tension au même moment (position de la carte par rapport aux autres, retard/déphasage des sources de bruit selon la position, sans parler des résonances différentes...). En plus, pas besoin de préampli, et une amplitude de signal déjà plus exploitable que le bruit d'une diode.
T'en penses quoi ?
-- LeLapin
Jean-Christophe a tapoté du bout de ses petites papattes :
Moi je vote pour la durée aléatoire, c'est bien éprouvé dans plein de systèmes.
-- LeLapin
On 15 oct, 18:54, LeLapin
Ok.
Original et surprenant. Mais si tout est silencieux ? On ne contr=F4le pas l'environnement sonore ...
On 15 oct, 18:57, LeLapin
Oui, mais en principe, une proba de r=E9ponse en 1/N devrait r=E9duire le nombre de collisions ...
Jean-Christophe a tapoté du bout de ses petites papattes :
Je ne crois pas au silence absolu. Sauf en chambre sourde, et encore.
-- LeLapin
Jean-Christophe a tapoté du bout de ses petites papattes :
Pas forcément. Si l'unité de temporisation de base (que tu vas multiplier par ton nombre aléatoire pour faire l'attente) n'est pas pile (et synchrone) un multiple du bitrate, statistiquement, la quasi-totalité des collisions sera évitée par les esclaves puisqu'ils font du sensing sur la liaison (en gros c'est du csma/cd).
Et la méthode avec proba en 1/N sera plus lente sans être plus fiable.
-- LeLapin
Le 15/10/2011 11:48, Jean-Christophe a écrit :
sir ce compteur tourne assez vite, il est peu probable que deux cartes soient synchronisées.
C'est un concept que j'ai utilisé il y a très longtemps et qui marche très bien.
jj
Le 15/10/2011 21:56, LeLapin a écrit :
Dans le vide :-)
-- http://grincheux.de-charybde-en-scylla.fr/?p=312&more=1&c=1&tb=1&pb=1 http://fr.narkive.com/2011/1/16/4070064-f5pbg-lapprenti-anonyme.html http://www.edaboard.eu/souffle-ampli-marantz-sr5200-t408291.html http://www.radioamateurs-online.fr/2011/09/tout-savoir-sur-f5pbg-ludovic-vuillermet/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.