Zitat :

kann ich wahrscheinlich nur Werte generieren, die auf dem ersten Blick zufällig aussehen.

Dafür gibt es aber ausgefeilte und sehr gut ausgetestete Algorithmen.
Solch eine einfach erzeugte Sequenz muss durchaus nicht einfach zu knacken sein.
Der Vorteil dieser Pseudozufallszahlen (PRN) ist, dass man ein Experiment mit der gleichen Sequenz wiederholen kann.

Physikalische Rauschgeneratoren sind auch nicht ganz leicht dazu zu bringen, dass in der Zahlenfolge wirklich keine Gesetzmäßigkeit durchschimmert. Frequenzgang der Teile oder Störspannungen aus der Versorgung können die schöne Idee zunichte machen.
Im Zweiten Weltkrieg rüsteten die Engländer ihre Bomber mit Störsendern gegen das deutsche Radar aus, die auf dem Rauschen eines Photomultipliers beruhten.

_________________
Haftungsausschluß:



Bei obigem Beitrag handelt es sich um meine private Meinung.



Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.



Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !

Hallo

Ich möchte gleich an das anknüpfen was perl angerissen hat.

Also einfach einen verauschten Eingang zu verwenden halte ich für keine gute Idee, da es sich dabei wahrscheinlich (passt das Wort hier?) nicht um eine Gleichverteilung handelt. Will sagen, bestimmte Werte treten häufiger auf als andere!

Ich würde eher zu Pseudozufallszahlengeneratoren tendieren als da wäre die lineare Kongruenzmethode.
http://de.wikipedia.org/wiki/Multip.....rator
Im Prinzip errechnet sich eine Zahl immer aus der vorherigen mit folgener Formel:

z_n+1 = a * (z_n + c)%m

% steht dabei für Modulo. m sollte man möglichst groß wählen. Auf einem 'digitalem Rechner' wenn ich das mal so sagen darf, gestaltet sich die Rechnung erstaunlich einfach, wählt man für z zb. den Typ unsinged int und für für m 2^32, so kann man sich das Modulo rechnen sparen, das wird von selbst durch den Überlauf erledigt.

Für a und c gibt es auch gewisse Faustregeln. Wenn man es geschickt anstellt, kriegt man einen sehr schnellen, recht guten Generator mit einer Periodenlänge von 2^32, dann beginnt die Zahlenfolge wieder von vorne. Wenn du wirklich nur jede Minute eine Zahl brauchst ist das vollkommen ausreichend.

Das einzige Problem aller Pseudozufallszahlengeneratoren: Wenn du das Ding resetest fängt die ganze Jagd exakt gleich von vorne an! Ich schlage deshalb vor den letzten Wert immer im EEPROM abzusichern und nach dem Reset wieder zu laden.

Wenn du es so machst hast du eine Periodenlänge von 8000 Jahren.

Ich hab grad Werte für 16Bit gefunden, also unsigned short, die Periodenlänge wäre dann 45 Tage, der Code in C sieht dann so einfach aus:

unsigned short x=123;

unsigned short Rand()
{
x=x*3421+1;
return x;
}

Ich hoffe, das hat geholfen.

mfg Fritz

_________________

Vielen Dank für Eure Beiträge.

Nachdem Beitrag vom Perl habe ich eine Realisierung mit einem physikalischen Rauschgeneratoren aufgegeben. Ein Pseudozufallszahlengenerator scheint mir jetzt zuverlässiger zu sein.

Die Frage ist nur Welcher?

Ich brauche eine gute Routine in Assembler für einen 8-Bit-Random. Die Schnelligkeit ist völlig egal, ich brauche es wirklich in Minutenabstand.

Zurzeit habe ich eine Routine aus piclist.com etwas modifiziert, mit dem Ergebnis bin ich aber noch nicht zufrieden. Ich möchte gerne andere Ideen ausprobieren.
Original Routine aus piclist.com

NewRandom
incf RANDOM,1
decfsz RANDOM,1
goto Calculate
movlw H'B4'
movwf RANDOM
return
Calculate
rlf RANDOM,W
rlf RANDOM,W
btfsc RANDOM,4
xorlw 1
btfsc RANDOM,5
xorlw 1
btfsc RANDOM,3
xorlw 1
movwf RANDOM
return

Das Problem mit dem Anfangswert habe ich dadurch ohne EEPROM gelöst, in dem ich die RAM-Zelle mit dem RANDOM-Wert nur überschreibe, wenn sie Null sein sollte. Ausschalten mit einem Schalter tue ich sowieso nicht, Ein- und Aus-Taster weckt den PIC nur aus dem Schlaf. Zu meiner Überraschung habe ich festgestellt, dass selbst nach einem Batteriewechsel die RAM-Zelle immer irgendein Wert hat. Eine Null habe ich noch nicht bekommen.

Den letzten Wert im EEPROM abzusichern, ist natürlich eleganter. Danke für den Vorschlag.

Hallo,

Zitat :

Zu meiner Überraschung habe ich festgestellt, dass selbst nach einem Batteriewechsel die RAM-Zelle immer irgendein Wert hat

Das ist bei bestimmten Arten von RAM normal, da dort Flipflops als Speicher benutzt werden. Wird die Versorgung eingeschaltet, ist es mehr oder weniger Zufall, welchen Zustand jedes Flipflop einnimmt. Aus diesem Grunde muss/sollte diese Art RAM auch vorher initialisiert werden, i.d.R. mit 0x00.
Diese Tatsache kann man auch nutzen, indem man aus einer RAM-Zelle, welche nicht initialisiert wurde, den Wert ausließt und als Startwert nimmt.

Allerdings ist das nicht sehr zuverlässig, es kann durchaus passieren, dass die SRAM-Zellen den Wert recht lange halten.

_________________

Ich meine der letzte Wert bleibt immer, auch nach einem normalen Batteriewechsel. Ein Batteriewechsel im Sleep merkt der PIC wegen der großen Kondensatoren überhaupt nicht.

Den letzten Wert immer im EEPROM abzusichern, ist einfach eleganter. Ich habe aber lange kein EEPROM benutzt und ich weiß nicht mehr wie man das macht, ich muss mich erstmal belesen.

Hallo

Mit Assembler kenn ich mich leider gar nicht aus. Kann es denn nicht C sein?

Die lineare Kongruenzmethode funktioniert im Prinzip auch mit 8 Bit, du musst dir aber darüber im klaren sein, dass dann nach 256 Werten die ganze Sache wieder von vorne beginnt.

Du kannst aber den Algorithmus für 16 Bit verwenden und einfach nur die ersten 8 Bit verwenden. (WICHTIG: die ersten 8 Bit, nicht die letzten, sonst ist der Zufall im Eimer) Ich C sehe das so aus:

Code :

unsigned short x=123; // der Startwert unsigned char Rand() { x=x*3421+1; return (x>>8); }

Für einen Assembler Fuchs wie dich ist es sicher kein Problem das in Assembler um zu münzen, wenn du es schon darauf anlegst.

mfg Fritz

[ Diese Nachricht wurde geändert von: ffeichtinger am 30 Dez 2008 12:41 ]

[ Diese Nachricht wurde geändert von: ffeichtinger am 30 Dez 2008 12:48 ]

Danke Dir Fritz, leider kann ich die Kongruenzmethode auf meinem kleinen PIC12 nicht umsetzen. Erst ab PIC18 kann man multiplizieren.

Multiplizieren/teilen kannst du schon, nur eben mit 2, 4, 8 etc. Es gibt auch fertige Librarys mit Rechenroutinen, die du in deinen Code einbauen kannst.

_________________
Fnord ist die Quelle aller Nullbits in deinem Computer.
Fnord ist die Angst, die Erleichterung, und ist die Angst.
Fnord schläft nie.

Eine schlaue Assembler-Routine wahrscheinlich. 2*100 wird wahrscheinlich durch das addieren der 2 genau 100-Mal erledigt und natürlich eine Menge Overhead um die Sache abzurunden.

[ Diese Nachricht wurde geändert von: Micropower am 30 Dez 2008 16:40 ]

Was, auch egal wäre, du hast ja eine Minute Rechenzeit.

Nein ernsthaft, einen einigermaßen guten Zufallszahlengenerator zu programmieren ohne zu Multiplizieren ist wohl recht unmöglich. Außer man macht es ganz primitiv, aber wenn das auch tut, beurteile mal die Qualität dieser 500 Zahlen und rate wie ich sie gemacht habe:

234 89 200 55 166 21 132 243 98 209 64 175 30 141 252 107 218 73 184 39 150 5 116 227 82 193 48 159 14 125 236 91 202 57 168 23 134 245 100 211 66 177 32 143 254 109 220 75 186 41 152 7 118 229 84 195 50 161 16 127 238 93 204 59 170 25 136 247 102 213 68 179 34 145 0 111 222 77 188 43 154 9 120 231 86 197 52 163 18 129 240 95 206 61 172 27 138 249 104 215 70 181 36 147 2 113 224 79 190 45 156 11 122 233 88 199 54 165 20 131 242 97 208 63 174 29 140 251 106 217 72 183 38 149 4 115 226 81 192 47 158 13 124 235 90 201 56 167 22 133 244 99 210 65 176 31 142 253 108 219 74 185 40 151 6 117 228 83 194 49 160 15 126 237 92 203 58 169 24 135 246 101 212 67 178 33 144 255 110 221 76 187 42 153 8 119 230 85 196 51 162 17 128 239 94 205 60 171 26 137 248 103 214 69 180 35 146 1 112 223 78 189 44 155 10 121 232 87 198 53 164 19 130 241 96 207 62 173 28 139 250 105 216 71 182 37 148 3 114 225 80 191 46 157 12 123 234 89 200 55 166 21 132 243 98 209 64 175 30 141 252 107 218 73 184 39 150 5 116 227 82 193 48 159 14 125 236 91 202 57 168 23 134 245 100 211 66 177 32 143 254 109 220 75 186 41 152 7 118 229 84 195 50 161 16 127 238 93 204 59 170 25 136 247 102 213 68 179 34 145 0 111 222 77 188 43 154 9 120 231 86 197 52 163 18 129 240 95 206 61 172 27 138 249 104 215 70 181 36 147 2 113 224 79 190 45 156 11 122 233 88 199 54 165 20 131 242 97 208 63 174 29 140 251 106 217 72 183 38 149 4 115 226 81 192 47 158 13 124 235 90 201 56 167 22 133 244 99 210 65 176 31 142 253 108 219 74 185 40 151 6 117 228 83 194 49 160 15 126 237 92 203 58 169 24 135 246 101 212 67 178 33 144 255 110 221 76 187 42 153 8 119 230 85 196 51 162 17 128 239 94 205 60 171 26 137 248 103 214 69 180 35 146 1 112 223 78 189 44 155 10 121 232 87 198 53 164 19 130 241 96 207 62 173 28 139 250 105 216 71

mfg Fritz

_________________

Ich verstehe zwar nix von PICs (bastele mit Atmel AVRs), trotzdem: Wo ist das Problem?

Zitat :

Multiplizieren/teilen kannst du schon, nur eben mit 2, 4, 8 etc.

Genau. 3421 zerlegt sich in 2^11+2^10+2^8+2^6+2^4+2^3+2^2+1.
Im Prinzip (wenn die Register breit genug sind) brauchst du also nur die Zahl 8 mal kopieren, jeweils mit der passenden Zweier-Potenz multiplizieren (-->links schieben) und die einzelnden Ergebnisse addieren.
Einen Multiplikationsbefehl braucht man dafür nicht.

Oder hab ich einen Denkfehler?

a_(i+1)=a_(i)+111?

_________________
Es irrt der Mensch solang er strebt

Er hat wohl abwechselnd -145 oder 111 addiert.

edit: Halt, Stop, ich war zu schnell.
nächster Versuch:
-145
+111
-145
+111
-145
+111
+111
und dann wieder von vorne...

Neh, das stimmt auch nur bis 150... Ist aber wohl immer irgendwas mit +/- 111/145

[ Diese Nachricht wurde geändert von: bastler16 am 30 Dez 2008 18:24 ]