Hallo Leute,
ich habe einen Slave-Mikrocontroller der mit einem Master-Controller
über CAN kommuniziert. Beim Start des Slave-Mikrocontrollers soll eine
WakeUp Message versendet werden mit einer zufälligen ID welche sich wie
folgt berechnet: 0x660 + Zufallszahl (0-31).
Die Zufallszahl soll bei jedem Neustart des Controllers anders sein.
Aktuell verwende ich folgendes:
1
// Set Random Wakeup-ID
2
m_random=xorshift8();
3
srand(m_random);
4
WAKEUP_ID=STARTDEFID+(rand()%31);
Ist ja egtl. auch verständlich damit ich immer die gleiche Zahl erhalte,
da die Base immer die gleiche ist oder?
Hintegrund ist dieser, es sollen mehrere Slave-Controller starten können
ohne die gleiche ID zu besitzen. (PIC18F45K80)
Weiterhin wollte ich fragen ob sich jemand mit dynamischen Masken und
Filtern, welche sich abhängig von der eigenen zugewiesenen ID ändern
auskennt.
MFG
Flo
Also, erstens ist für mich eine ID eine ID.
Eine unverwechselbare eindeutige Erkennung.
Vielleicht konfigurierbar, aber dann ist auch gut.
Wenn dein PIC einen ungenutzten ADC hat, könntest du diesen ein paar mal
auslesen. Und aus dem jeweils letzten Bit, deinen Seed zusammenstoppeln.
--------
Wie auch immer, ich habe kein Ahnung von PICs, aber das hört sich alles
falsch an.
Wüsste jetzt wie ein MC-Program aus sich selbst heraus
(Pseudo)Zufallszeiten erzeugen kann.
Eine möglichkeit wäre bei der Initialisierung am CAN-BUS auf
irgendwelche Signale zu lauschen und dabei einen Timer mitlaufen
zulassen. Den Timer könnte man dann (beschnitten auf gewüchte Anzahl
Bits) als ID nehmen oder als Startwert für die Zufalszahlenerzeugung
Alternativ könne man an einen freien Pin eine R/C-Kombination hängen die
beim Start umgeladen wird und diese Zeit timen. Die Bauteil-,
Thermische- u. Versorgungsspannungsschwankungen sollten ausreichen das
der Wert ausreichend streut.
Oder an einem freien A/D-Wandler ein Temperaturabhängiges Bauteil...
"Echter" Zufall lässt sich nur in Hardware erzeugen.
P.S. Bei einem ID-Bereich von nur 1-31 seh ich allerdings die Gefahr von
häufigen ID-Kollisionen.
Du brauchst also auch dringend eine Kollisionserkennung.
P.P.S.
Ausserdem widerspricht dein Vorhaben der Philosophie des CAN-Bus.
Beim CAN-BUS werden Messages autentifiziert, keine ICs.
Was auch geht, ist ein Spannungsteiler (2 * z.B. 10 MegOhm), mittig
daran angeschlossen eine elektrisch leitende Fläche mit vielleicht 1
cm^2 und dann ebenfalls an den ADC. Sollte durch externe Felder auch
zufällig sein.
Allerdings gebe ich meinem Vorposter auch recht darin, dass man dadurch
ID-Kollisionen erhält. Vielleicht einen kleinen Baustein mit einer
einzigartigen ID nutzen? Sind nicht teuer gewesen soweit ich weiß.
FloJ schrieb:> Hintegrund ist dieser, es sollen mehrere Slave-Controller starten können> ohne die gleiche ID zu besitzen. (PIC18F45K80)
Ist doch Unsinn: Bei nur 32 Adressen kommt es ganz schnell zu zufällig 2
mal derselben Zahl.
Wenn es wenigstens 64 bit wären...
Immerhin hat auch ein PIC18F45 ein EEPROM, kann also eine Zahl
speichern. Beim nächsten Start kann er per PRNG eine andere nehmen. Das
wäre aber blöd, weil das dann vielleicht dieselbe ist, die sich ein
anderer uC ausdenkt. Das Verfahren ist also Scheisse.
Nehmen wir an, jeder uC lauscht immer am Bus, und registriert, mit
welchen Nummern sich andere uC anmelden, und sucht sich dadurch eine
Nummer, die bisher nicht verwendet wird. Dann hast du ein anderes
Problem: Alle uC müssen unterschiedlich lange warten, bis sie versuchen,
ihre Nummer mitzuteilen. DAS wiederum kann man per fester aber
individueller Konstante machen, also eine 16 bit Zahl und der uC wartet
so viele Takte nach dem Anlegen der Spannung bevor er versucht, sich mit
seiner dann noch freuen Nummer zu registrieren. Aber wenn er sowieso
eine feste aber individuelle Nummer hat, dann nimm doch einfach die, und
erweitere im Protokoll die Zahl auf 16 bit.
CAN Bus?
Dann lass deinen Slave einen Broadcast verschicken, mit der er eine ID
anfordert, die er ebenfalls bei Broadcast zugestellt kriegt.
Während der Mechanismus läuft, darf kein anderer Slave eine ID
anfordern. Sollte das doch der Fall sein (weil ein Slave noch nicht
mitgekriegt hat, dass gerade eine ID Vergabe läuft), gibt der Master
eine Cancel Broadcast raus und alle Slaves, die noch keine ID haben,
müssen noch mal neu anfordern.
Mit Zufallszahlen kannst du hier sowieso nichts anfangen. Du müsstest
dich genauso um Kollisionen kümmern. Da kannst du es auch gleich lassen
und die ID Vergabe zentral machen und dir was überlegen, wie du
Kollisionen bei der Vergabe bereinigst.
Eine zuverlässige Methode ist, man schließt die Slaves zuerst
nacheinander an und der Master weist jedem neu erkannten eine ID zu, die
dieser in seinem EEPROM speichert.
Hi,
danke für die Antworten!
Ich weiß es hört sich dämlich an mit der CAN-Bus und den ID´s etc. es
funktioniert aber. Und daran kann ich nichts ändern ist von einer
anderen Firma die den Master-Controller entwickelt so vorgegeben.
Nochmals die Vorgehensweise detaillierter:
1. Slave startet
2. Slave sendet WakeUp Message
3. Master weißt eine logische Adresse zu, aus welcher sich die
Nachrichten Identifier der Slaves errechnen.
4. Slave nimmt die Adresse an und weißt den Telegrammen entsprechende
IDS zu.
5. Master sendet Nachricht für den start der zyklischen Kommunikation
6. Slave legt los und sendet zyklische Daten...
... das funktioniert alles soweit nur eben mit immer der gleichen
wake-Up ID, das werde ich aber mal mit dem ADC-Versuchen.
Dann zu der Filterung:
Es ist so der Master sendet die Steuerbefehle immer mit der ID 0x020.
Das funktioniert auch alles soweit, jedoch wird die Zeit (4-Byte)
abhängig von der zugewiesenen logischen Netzwerkadresse versendet
(versteh ich selber nicht warum), sozusagen bekommt jeder Teilnehmer die
Zeit mit persönlichem Identifier geliefert.
Wenn die Zeit zentral mit kp 0x030 gesendet werden würde wärs kein
Problem, aber da muss ich glaube ich nochmal mit der anderen Firma
reden.
Auf jeden!
Vielen Dank für eure bisherigen Antworten!
MFG
Flo
Ganz abgesehen davon.
Was passiert denn mit dieser ID weiter?
Meistens wird die ja in irgendeiner Form benutzt, so dass man wissen
sollte welche ID zu welchem Gerät gehört. Schon alleine deshalb sind
ständig wechselnde ID nicht so prickelnd.
Ich kenn mich mit PICs jetzt nicht aus,
aber manche µCs haben doch eh einmalige Seriennummern in einem festen
Register stehen. Aus der kann man sich ja ne Adresse basteln, die immer
einmalig ist.
Vlt. hat der PIC auch sowas.
mfg.
Aus einem Paper, es ging um Temperatursensoren am CAN:
"Data is sent using two CAN bus controller mailboxes, one acting as a
transmit mailbox, the other as a receive mailbox. Commands are uniquely
defined by their CAN bus address contained in each datagram's header.
All datagrams transfer one 32 bit address word and one 32 bit wide data
word.
The enumeration scheme takes advantage of the inherent medium access
control of the CAN bus which guarantees collision-free communication and
allows each slave node to detect successful datagram transmission. The
sensor network is initialized by the bus master by issuing a RESET
datagram which will set all slaves to an uninitialized state. Thereafter
the master sends out FIND datagrams and listens for SENDID datagrams,
containing the node ID, sent simultaneously by all slave nodes in reply.
On successful transmission of their ID slave nodes will enter the
initialized state and in turn ignore SENDID datagrams unless reset. The
master continues sending FIND datagrams and adding slave nodes to its
slave node table until all slave nodes are initialized and no further
SENDID datagrams are received.
For further configuration and measurements the master sets the address
word of the datagram to the desired slave ID and sends up to 32 bits of
data. Initialized slave nodes act upon the received datagrams, issuing a
reply datagram containing node ID and data value if required. Additional
datagrams for triggering, of measurements, transferring measurement
results and configuration have been defined."
Ich schrieb:> the master sends out FIND datagrams and listens for SENDID datagrams,> containing the node ID, sent simultaneously by all slave nodes in reply.
Das setzt aber vorraus, dass jeder Slave schon eine eindeutige ID hat.
Was auch logisch ist, denn woher will man denn nachher wissen, welcher
Sensor zb der im Schlafzimmer ist.
Die Methode in diesem Paper beschreibt eine Lösung für die
Problemstellung: Wie kriegt der Master raus, welche Sensoren vorhanden
sind, ohne den kompletten Adressraum von 32 Bit Adressen abklappern zu
müssen und bei jeder einzelnen Adresse die Frage zu stellen "Ist da
jemand?"
Was mit 32 Bit Adressen nicht mehr geht, ist mit lediglich 32 möglichen
Adressen kein Problem. Die kann man einzeln durchgehen und abfragen. Das
ist zeitlich noch kein Fiasko.
Aber: in beiden Fällen müssen die Sensoren (oder Slaves) fixe Adressen
haben.
Max M. schrieb:> Wüsste jetzt wie ein MC-Program aus sich selbst heraus> (Pseudo)Zufallszeiten erzeugen kann.
Echter Zufall geht nur über physikalische Effekte, die auch wirklich
zufällig sind (Rauschen, der berühmte Abstand von Tastenanschlägen
etc.).
Jörg W. schrieb:> Max M. schrieb:>> Wüsste jetzt wie ein MC-Program aus sich selbst heraus>> (Pseudo)Zufallszeiten erzeugen kann.>> Echter Zufall geht nur über physikalische Effekte, die auch wirklich> zufällig sind (Rauschen, der berühmte Abstand von Tastenanschlägen> etc.).
Sorry!!! Da fehlt ein "nicht"!
Sollte heissen:
Wüsste jetzt NICHT wie ein MC-Program aus sich selbst
heraus(Pseudo)Zufallszeiten erzeugen kann.
Sorry!!!
Hatte das auch weiter unten so geschrieben
Max M. schrieb:> "Echter" Zufall lässt sich nur in Hardware erzeugen.
Hey,
der Master kann die angeschlossenen Geräte anhand einer festen
MAC-Adresse, die er über CAN abfragen kann zuordnen. Er sendet ein
Telegramm wobei im ersten Datenbyte die zugewiesene logische
Netwerkadresse steht z.b. 0x19, der Teilnehmer mit der zugewiesenen
Adresse 0x19 weiß jetzt ok ich muss meine MAC senden und tut das dann!
mfg
flo
FloJ schrieb:> Er sendet ein> Telegramm
Er sendet ein Telegram an wen?
> wobei im ersten Datenbyte die zugewiesene logische> Netwerkadresse steht z.b. 0x19, der Teilnehmer mit der zugewiesenen> Adresse 0x19 weiß jetzt ok ich muss meine MAC senden und tut das dann!>
Du hast doch hier ein 'Henne - Ei' Problem!
Anders rum wird ein Schuh daraus.
Der Teilnehmer sendet eine Nachricht: Hallo, ich bin der so und so (MAC
Adresse) und ich bräucht eine ID.
Der Master antwortet: Ok lieber so und so (MAC Adresse), hier ist deine
ID, mit der ich dich in Zukunft ansprechen werde.
Da ein Teilnehmer bis zur Vergabe seiner ID noch nicht weiss, welche
Messages für ihn sind und welche nicht, filtert er die nicht aus,
sondern wartet bis er eine ID-OK Message sieht. Die sieht er sich an,
wenn die darin enthaltene MAC-Adresse seine eigene ist, dann übernimmt
er die ID aus dieser Message ansonsten verwirft er die Msg und wartet
weiter.
Niemand braucht dazu Zufallszahlen.
Thread beobachten
Seitenaufteilung abschalten