PIC: Ist W nach einem POR halbwegs zufällig?

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

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.