Hallo, ich möchte eine Zufallszahl mit rand() erzeugen, bekommen jedoch nach dem Start des Mikrocontrollers immer die gleichen Zahlenfolgen. Woran liegt das?
Das ist das normale Verhalten von rand() übrigens nicht nur auf Microcontrollern. Schau dir Mal srand() und seed an. Thomas
Du musst beim Start den Pseudo-Zufallsgenerator mit der srand() Funktion
initialisieren ("seeden").
Dafür kann man z.B. die aktuelle Zeit (in Sekunden) nehmen kombiniert
mit dem internen Temperatursensor (sofern vorhanden) o.ä.
Man sollte nie einen Zufallsgenerator mit der Zeit seeden. Nie :) Wenn das irgendwas sicherheitskritisches ist, liefert der prng vorhersagbaren Zahlenfolgen.
Verstehe ich nicht so ganz. Soll eine Zufallsfunktion nicht Zufallszahlen erzeugen? Was bringt mir das, wenn da immer die selben Zahlenfolgen bei herauskommen? Ist das dann nicht etwas nutzlos?
Deswegen heisst es Pseudo Zufall. Dahinter steht eine deterministische Berechnungsformel, die zwar scheinbar zufällige Werte liefert, aber mit identischer Initialisierung des Startwerts immer dieselbe Folge.
Andi schrieb: > Verstehe ich nicht so ganz. Soll eine Zufallsfunktion nicht > Zufallszahlen erzeugen? Was bringt mir das, wenn da immer die selben > Zahlenfolgen bei herauskommen? Ist das dann nicht etwas nutzlos? "Echte" Zufälle sind mit einen µC kaum zu erzeugen! Versuch das mal, und du wirst sehen....
Arduino Fanboy D. schrieb: > "Echte" Zufälle sind mit einen µC kaum zu erzeugen! doch am ADC mit offener langer Leitung. Was die Antenne einfängt muss zufällig sein (glaube ich zumindest)
Andi schrieb: > Verstehe ich nicht so ganz. Soll eine Zufallsfunktion nicht > Zufallszahlen erzeugen? Ein Computer weiß nicht, was Zufall ist. Er kann nur logische Dinge berechnen. Er kann also nur eine bekannte Zahl als Basis nehmen und daran eine wilde, aber immer gleiche Rechenoperation vornehmen, um auf die nächste Zufallszahl zu kommen. Bei jedem Start des Controllers ist dieser Startwert gleich, daher immer die gleiche Zahlenfolge. Es gibt aber die Möglichkeit, diesen "Seed" vorzugeben. Zum Beispiel mit dem Wert eines unbenutzten ADC-Einganges, der ein bisschen Rauschen empfängt.
Es gibt auch uC die einen TRNG in Hardware drin haben: https://www.st.com/content/ccc/resource/technical/document/application_note/4a/6a/82/05/8e/9e/4e/94/DM00073853.pdf/files/DM00073853.pdf/jcr:content/translations/en.DM00073853.pdf
Martin schrieb: > Wenn das irgendwas sicherheitskritisches ist ... dann nimmt man ohnehin nicht rand(). Aber wenn man rand() nimmt, weil es nicht sicherheitskritisch ist, kann man auch mit der Zeit seeden.
Joachim B. schrieb: > doch am ADC mit offener langer Leitung. > > Was die Antenne einfängt muss zufällig sein (glaube ich zumindest) Halte ich für sehr gewagt. Einmal eine FFT drauf werfen und schon werden diverse Peaks (zB. n*50...) auftauchen. Das darf bei echtem Zufall nicht sein.
Andi schrieb: > Verstehe ich nicht so ganz. Soll eine Zufallsfunktion nicht > Zufallszahlen erzeugen? Was bringt mir das, wenn da immer die selben > Zahlenfolgen bei herauskommen? Ist das dann nicht etwas nutzlos? Das hat tatsächlich einen Nutzen. Angenommen, Du willst ein Programm testen, dass Du gerade schreibst. Programmierer wollen, dass ihre Programme sich vorhersehbar, auf eine genau bestimmte Weise verhalten. Das muss man davon unterscheiden, dass sich ein Programm im Einsatz, durch Zufallszahlen zufällig verhält. In einem Spiel etwa, sollen Fische im Teich an zufälligen Stellen auftauchen oder zufällige Strecken entlangschwimmen. Während der Tests aber, also während man das Programm noch schreibt, will der Programmierer testen, ob der Fisch, wenn eine bestimmte Zufallszahl genommen wird, auch genau eine zu dieser Zahl gehörende Strecke schwimmt (oder an einer zu dieser Zahl gehörenden Stelle auftaucht). Dazu testet er mit rand() und einem bestimmten Initialisierungswert, damit er Veränderungen am Programmtext auch beurteilen kann, ob sie wirksam sind und wie gewünscht funktionieren. Würde er tatsächliche Zufallszahlen zum Test nehmen, dann würde sich das Programm jedesmal anders verhalten und er müsste warten bis irgendwann einmal gerade die Zahl "gezogen" wird, für die er eine Änderung im Programm gemacht hat. Analog gilt das für Folgen von Zufallszahlen. Der Programmierer kann damit das zeitlich ausgedehnte Verhalten und das letztliche Ergebnis testen.
Arduino Fanboy D. schrieb: > "Echte" Zufälle sind mit einen µC kaum zu erzeugen! Doch: mit allem, was physikalisch bedingt zufällig ist. Ob das nun ein ADC-Eingang ist (besser als "offen" wäre die Beschaltung mit einer rauschenden Z-Diode), oder ob es andere nicht vorhersagbare Dinge wie der Zeitabstand zwischen Tastenbetätigungen oder etwas ganz anderes ist, muss man von Fall zu Fall selbst organisieren.
Bei dem Thema fällt mir das hier wieder ein: Für richtig gute Zufallszahlen hat das Unternehmen Cloudflare 100 Lavalampen eingesetzt: https://winfuture.de/news,100452.html https://www.cloudflare.com/learning/ssl/lava-lamp-encryption/ Diese 100 Lampen werden von einer Kamera fotografiert, aus den Bildern werden Zufallszahlen generiert und damit werden letztendlich Schlüssel für SSL und TLS generiert.
Frag doch mal einen Maker, ob er dir nicht einen Robbi baut, der wirklich Würfel wirft und danach wieder einsammelt. Noch eine Kamera zur Erkennung der Augen, und schon gibt es Zufall.
Echten Zufall hat man doch nur wenn man als Basis z.B. das Rauschen eines Transistors mit rein nimmt: https://www.subroutine.info/elektronik/zufallsgenerator/
M. K. schrieb: > Echten Zufall hat man doch nur wenn man als Basis z.B. das Rauschen > eines Transistors mit rein nimmt Nein, nicht nur. Man hat ihn überall, wo sich nicht vorhersagbare physikalische Effekte überlagern. Die Lavalampe wurde ja schon genannt. Wenn man mit dem offenen ADC-Eingang allerdings nur das überall vagabundierende 50-Hz-E-Feld der Niederspannungsversorgung misst, dann hat man dadurch allein eben auch keinen Zufall.
:
Bearbeitet durch Moderator
Andi schrieb: > Was bringt mir das, wenn da immer die selben > Zahlenfolgen bei herauskommen? Ist das dann nicht etwas nutzlos? Zum Beispiel wird diese Eigenschaft bei dem Spiel Senso (auch bekannt als Simon) ausgenutzt. Es erzeugt scheinbar zufällige Tonfolgen, die bei jeder Spielrunde um einen Ton länger werden. Die Ton-Sequenz muss nicht gespeichert werden, weil jede Berechnung immer die gleiche Zahlenfolge liefert.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.