In Datenblättern von 8bit-PICs steht, dass nach einem POR der Inhalt von W (und manchen SFRs) "unknown" ist. Ist das trotzdem praktisch immer 0x00 oder steht da mehr oder weniger Zufall drin? Ich möchte einen Melodiegenerator bauen, der beim Anschalten eine von 8 Melodien spielt. Ich könnte natürlich bei jedem Anschalten 8bit Pseudozufall mit einem LFSR erzeugen und in einer EEPROM-Speicherzelle für den nächsten Start speichern, aber falls ich durch uninitialisierte SFRs bzw. W ebenfalls halbwegs zufällige Werte bekomme wär das doch auch was.
Sascha schrieb: > In Datenblättern von 8bit-PICs steht, dass nach einem POR der > Inhalt von > W (und manchen SFRs) "unknown" ist. Ist das trotzdem praktisch immer > 0x00 oder steht da mehr oder weniger Zufall drin? Ich möchte einen > Melodiegenerator bauen, der beim Anschalten eine von 8 Melodien spielt. > Ich könnte natürlich bei jedem Anschalten 8bit Pseudozufall mit einem > LFSR erzeugen und in einer EEPROM-Speicherzelle für den nächsten Start > speichern, aber falls ich durch uninitialisierte SFRs bzw. W ebenfalls > halbwegs zufällige Werte bekomme wär das doch auch was. Unknown ist was völlig anderes als zufällig. Die Chancen stehen gut, dass oft das gleiche Muster auftaucht, oder wenige Variationen. Gruss Reinhard
Wie es so schön heißt: probieren geht über studieren :D Ich kann mir aber nicht vorstellen, dass da echter Zufall zustande kommt. Ich würde mir meinen Zufall per ADC aus dem Umgebungsrauschen holen, vorrausgesetzt dein PIC hat soetwas (ich kenn nur AVRs und da ist es eher schwer einen OHNE adc zu finden ;) ). Ansonsten rauscht vlt. auchschon ein offener Port ohne pullup genug um Zufälle zu kriegen (das ist aber dann meist stark Exemplarabhängig)....
Das muss natürlich kein wasserdichter Zufall sein, an sich würds reichen wenn die Melodien nacheinander spielen würden. Aber da uninitialisierte Speicherbereiche wohl nicht genug Entropie bringen, muss ich wohl über das LFSR und EEPROM gehen. ADC hat der geplante PIC nicht (16F628), aber ich könnte die Zeit vermessen die ein RC-Glied mit einem NTC (Temperatur ist durchaus variabel) benötigt einen Eingang von 0 auf 1 zu bringen. Der Watchdog ist afaik ebenfalls recht temperaturabhängig, damit könnte man ebenfalls etwas anfangen.
Sascha schrieb: > ich könnte die Zeit vermessen die ein RC-Glied mit einem NTC (Temperatur > ist durchaus variabel) benötigt einen Eingang von 0 auf 1 zu bringen. Zumindest kannst du dann aus der Melodie auf die Temperatur schliessen und sparst dir eine halbe Wetterstation. Du kannst die Melodien ja gleich sortieren von "Oh Tannenbaum" bis "Glühend heisser Wüstensand". Gruss Reinhard
Das W Register enthàlt nach dem Start die Calibration fuer den internen OSC. Dies geht so, dass der Resetvektor eigentlich nicht 0 ist, sondern -1. Dort ist ein retlw imm vorhanden, und da der Inhalt des PC-Stacks 0 ist, làd der uC den immediate Wert und spring zur Adresse 0.
Fuer einen Melodiengenerator wird gerne kein WDT verwendet, weil dann die Batterie viel lànger haltet, und man mit dem Einschalten einen Reset macht, und sonst im Sleep bleibt. Den ersten Zufallswert bekommst du, indem man die Ram Zellen zusammenzahlt, bzw Xort usw. Dann initialisierst du den Timer und verwendest ihn als Zufallswert. Beim Sleep wird dieser schlafen gelegt, aber beim Einschalten ist der alte Wert da. Das mit dem Ram aufsummieren/Xor'en kann man sich auch sparen, dann ist der allererste Song nach dem Batterien einsetzen immer das gleiche Lied, danach ist dieser aber Zufall wenn man den Timer dann als weiteren Randomwert nimmt. In meiner Startup welche die Ram lòscht mache ich auch ein Aufsummieren/Xor der Registerfiles und summiere sie zum Timerwert. So kann ich ihn als Random Wert verwenden.
> Das W Register enthàlt nach dem Start die Calibration fuer den > internen OSC. Dies geht so, dass der Resetvektor eigentlich nicht > 0 ist, sondern -1 Nicht bei allen PICs. Nur jene, die einen softwarekalibrierbaren internen Takt haben, wie der 12F675. Der 16F628A kann das nicht. Wenn der Prozessor durchlaufen könnte (auch im Sleep) wärs ja kein Problem, aber der Strom wird vollständig abgeschaltet. Dann wirds halt das LFSR mit EEPROM. Bevor ich die 1 Million Schreibzyklen voll hab geht die Welt unter.
klar hat der 16F628A einen internen OSC, sogar zwei 4Mhz und 48khz.
> klar hat der 16F628A einen internen OSC, sogar zwei 4Mhz und 48khz.
Genau lesen, gilt für Beiträge und auch Datenblätter. Der interne Osc
des 16f628 ist NICHT über die Software kalibrierbar, was man auch anhand
des Fehlens des OSCCAL-Registers feststellen kann.
Bessere Idee für Zufallszahlen ist der ADC. Siehe folgenden Artikel, hinter dem Satz "Was macht das Programm?" http://www.schramm-software.de/tipps/zufallszahlen/ Gruss
Hi, Sascha schrieb: > ADC hat der geplante PIC nicht (16F628), aber > ich könnte die Zeit vermessen die ein RC-Glied mit einem NTC (Temperatur > ist durchaus variabel) benötigt einen Eingang von 0 auf 1 zu bringen. Ist es ein (privates? Studienarbeit?) Einzelprojekt oder soll daraus mal Seriengerät werden? Wenn es ein Einzelprojekt ist und du den Weg über den ADC gehen willst könntest du ja auch noch auf den PIC16F88 ausweichen. Der ist Pinkompatbel, hat nur mehr Speicher und Peripherie. Für ein Serienprodukt ist diese Option nur für eine Zufallszahl natürlich völlig Illusiorisch, da der F88 gleich rund 50% mehr kostet. Allerdings würde ich sowieso vorher noch einmal überprüfen ob der offene ADC beim PIC wirklich zufällige Werte liefert. Ich stand mal vor einem ähnlichen Problem und habe "nur" durch den offenen Pin immer nur sehr kleine zufällige Werte gehabt, vielleicht 3 Bit verwendbar... Ich weis aber nicht ob es an dem AD des PIC oder aber am Layout lag. Erst dur einen vorgeschalteten OP und der Leiterbahnführung nahe des Timer1 Oszillators mit dem Quarz für die RTC konnte ich dann eine halbwegs gleichmäßige Verteilung über den vollen benötigten 8Bit Bereich erreichen (Der Systemtakt kam aus dem internen Oszillator der ja auch extrem Temperaturabhängig ist. Das war dann zufällig genug ;-)) Im Realbetrieb ohne Temperaturregelung auf 1/100 Grad war das dann wirklich zufällig. Die Alternative wäre gewesen einfach 3x zu wandeln und aus den jeweils brauchbaren Bits dann 8Bit zu Basteln. Aber das kam aus Zeitgründen und weil wir uns nicht sicher waren ob die Spannungswerte am ADC sich schnell genug ändern nicht in Frage Wenn man nicht wirklich eine tatsächliche Zufallszahl braucht ist der Aufwand sicher viel zu übertrieben! Gruß Carsten
Ich würde einen simplen PRNG benutzen (z.B. xorshift, den gibt es auch mit 8 Bit) und nach jeder Melodie den neuen Wert ins EEPROM schreiben. Wenn du Angst um die Schreibzyklen hast, kannst du ja wear-levelling betreiben.
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.