Ich hab eine Schaltung mit Atmega + SD-Card, bei der keine
Hardware-Überwachung am SD-Slot auf Wechsel des Mediums vorgesehen ist.
Aus Performance-Gründen werden allerdings Verzeichnisse bzw. deren
Einträge im Atmega zwischengebunkert. Wenn jemand im laufenden Betrieb
die SD-Card wechselt, könnte das zum Daten-GAU führen.
Hab mir jetzt als "Notlösung" überlegt, im Root-Verzeichnis jeder
SD-Card eine kleine Datei mit einer sehr wahrscheinlich einmaligen
Zufallszahl abzulegen. Damit wär dann per Software ein Wechsel des
Mediums erkennbar - Commodore läßt grüßen ;)
Hab allerdings den Verdacht dass rand() immer mit der gleichen
Zufallszahl beginnt - oder irre ich mich da?
Ich muss zu meiner Entschuldigung sagen dass ich momentan noch nicht
praktisch probieren kann, da ich keinen Zugriff auf mein
Entwicklungssystem habe, erst wieder am Montag.
genau das was ich befürchtet hab - auf einem "richtigen" Computersystem
kann man sich behelfen indem man mit srand und der Systemzeit "time" den
Zufallsgenerator dazu bringt irgendwo anzufangen. Gibts beim Atmega bzw.
AVR-GCC diese "time" Systeminformation? Ich würde eher auf NEIN tippen,
weiss es aber nicht definitiv.
Gibts alternativ bei nem Atmega irgendeinen Zähler oder etwas, dass man
eben als seed für srand() benutzen kann?
Du könntest irgendein rauschendes Signal mit einem ADC abtasten und den
ADC Wert als seed verwenden. Je nach Rauschquelle sollte das zufällig
genug sein.
@ Micha (Gast)
>Einträge im Atmega zwischengebunkert. Wenn jemand im laufenden Betrieb>die SD-Card wechselt, könnte das zum Daten-GAU führen.
Das Entfernen kann man doch leicht per Taster erkennen, alle Sockel
haben den. (Card detect)
Wenn nicht, kann man auch periodisch die Karte lesen, z.B. eine einfache
Datei im Hauptverzeichnis. Schlägt das fehl, wurde die Karte entfernt.
Filesysteme haben üblicherweise eine sehr wahrscheinlich eindeutige
ID/Seriennummer, zumindest wenn sie formatiert wurden, und nicht 1:1
geklont. Auch die diversen FAT Varianten.
Solche IDs schützen aber nicht vor Datensalat, wenn die SD vom Gerät zum
PC und wieder zurück wandert, und das Gerät nicht merkt, dass
zwischendurch keine drin war.
Micha schrieb:> Hab allerdings den Verdacht dass rand() immer mit der gleichen> Zufallszahl beginnt - oder irre ich mich da?
Du könntest den generierten Zufallszahl ins EEPROM schreiben und beim
nächsten mal mit srand() als "Seed" setzen. Etwa so:
Falk Brunner schrieb:> @ Micha (Gast)>>>Einträge im Atmega zwischengebunkert. Wenn jemand im laufenden Betrieb>>die SD-Card wechselt, könnte das zum Daten-GAU führen.>> Das Entfernen kann man doch leicht per Taster erkennen, alle Sockel> haben den. (Card detect)>> Wenn nicht, kann man auch periodisch die Karte lesen, z.B. eine einfache> Datei im Hauptverzeichnis. Schlägt das fehl, wurde die Karte entfernt.
Und wie unterscheided sich jetzt die Antwort von der Frage des TE?
Hi,
kann mal jemand bei diesem Zufallszahlenerzeuger Hife leisten, wie die
Polynome sein müssen?
7 9 5 sind meine Wahl aber das gibt es glaube ich eine mathematische
Formel für optimale Parameter, so dass das Wiederholugsintervall maximal
wird. Diese Routine ist erheblich kürzer als das rand() aus der libc.
Hallo Micha,
wenn du im laufenden Betrieb die SD-Karte wechselst, muss die neu
eingesteckte zuerst initialisiert werden. Ansonsten kannst du gar nicht
auf die Karte zugreifen. Ist das nicht schon Hinweis genug?
Christian J. schrieb:> Diese Routine ist erheblich kürzer als das rand() aus der libc.
rand() an sich ist nicht wesentlich länger. Das Problem bei rand()
besteht darin, dass 32 Bit Arithmetik benutzt wird. Speziell die
Divisions und Multiplikationsroutinen schlagen da zu Buche.
Wenn du also irgendwo in deinem Programm etwas mit einem long oder einem
uint32_t machst, dann kriegst du diese Routinen genauso aufs Auge
gedrückt und sparst dann mit deiner Version fast nichts mehr.
Wenn du in deinem Programm allerdings nirgendwo 32 Bit Arithmetik hast,
dann kannst du tatsächlich ein paar 100 Bytes einsparen.
Es gibt hier im Forum ein paar Threads, die sich mit Zufallszahlen
beschäftigen. Suche mal nach "PRNG"
Der Beitrag hier (ohne die Funktion getestet zu haben), scheint mir
momentan aussichtsreichster Kandidat zu sein
Beitrag "Re: Quellcode für Pseudozufallsgenerator"
Karl Heinz schrieb:> Der Beitrag hier (ohne die Funktion getestet zu haben), scheint mir> momentan aussichtsreichster Kandidat zu sein> Beitrag "Re: Quellcode für Pseudozufallsgenerator"
Genau den habe ich gesucht !!!!! Wollte ich mal mit TTL Register
aufbauen,
32 D-FF's und Feedback Schleifen. Blöd nur wenn die 0 ihn anhält.
Ich werde den mal testen und eine kleine Statistik der Verteilung
machen. Seit RNG in den STM32 ist man allerdings schon etwas verwöhnt
"echte" Zahlen zu haben und das millionenfach immer neue.
Hallo,
Micha schrieb:> Wenn jemand im laufenden Betrieb> die SD-Card wechselt, könnte das zum Daten-GAU führen.>> Hab mir jetzt als "Notlösung" überlegt, im Root-Verzeichnis jeder> SD-Card eine kleine Datei mit einer sehr wahrscheinlich einmaligen> Zufallszahl abzulegen. Damit wär dann per Software ein Wechsel des> Mediums erkennbar - Commodore läßt grüßen ;)
...und wenn jemand die Karte zieht und nach 1h die gleiche Karte wieder
einsteckt?
Mit freundlichen Grüßen
Selbsternannter Weltverbesserer
Dieter Frohnapfel schrieb:> Vielleicht kann das ja auch als Anregung dienen ...>> http://www.jtxp.org/tech/xr232usb.htm
Ja...... sehr lustig :-)
Reine Assemblerprogrammierung
Keinesfalls möchte ich den hardwarefremden, hochsprachenverwöhnten Snobs
das Vergnügen absprechen, sich mit klobigen Compilern, dutzenden
Direktiven, sachfremder Syntax, abartiger Abstraktion und labilen
Libraries herumzuschlagen! Fast könnte man meinen, dass manchem
"Embedded"-Entwickler das Trugbild von Professionalität und
Portierbarkeit wichtiger sind, als technisch saubere und
ressourcenschonende Lösungen vorzulegen. Wen juckt's schon, wenn der
primitive LED-Blinker gerade noch so in einen ATmega reinpasst...
Dennoch möchte ich diesen Fehlgeleiteten zurufen:
Wenn der Speicherplatz schon wieder knapp geworden und die ganze
Performance bei der Übersetzung in Blähcode versackt ist, dann werdet
ihr sehen, dass man nicht jeden Unsinn aus der PC-Welt auf einen
Mikrocontroller übertragen kann ...!
Christian J. schrieb:> Ja...... sehr lustig :-)>> Reine Assemblerprogrammierung
Aber reingeschaut hast Du schon mal - oder? Es geht um das Prinzip, mit
einem Operationsverstärker ein digitales Rauschen zu erzeugen, mit
dessen Hilfe man Zufallszahlen generieren kann.
Die Schaltung ist einfach und das Verfahren ist im Klartext beschrieben.
Ist halt nicht fertig in C vorgekaut -sorry.
Dieter Frohnapfel schrieb:> Die Schaltung ist einfach und das Verfahren ist im Klartext beschrieben.
Beschrieben ist sie. Allerdings stimme ich mit der Aussage, dass alle
Spezifikationen des LM393 eingehalten würden, nicht überein. Die
verlangen nämlich, dass beide Eingangsspannungen Vcc-1,5V nicht
überschreiten. Der (+) Eingang tut das aber trivialerweise. Der (-)
Eingang auch, denn der schrammt an der Abschaltgrenze dieses Zweigs des
internen Differenzverstärkers entlang.
A. K. schrieb:> Allerdings stimme ich mit der Aussage, dass alle> Spezifikationen des LM393 eingehalten würden, nicht überein. Die> verlangen nämlich, dass beide Eingangsspannungen Vcc-1,5V nicht> überschreiten. Der (+) Eingang ...
Das ist mir, beim Betrachten der Schaltung auch sofort aufgefallen, da
ich den LM393 schon mehrfach verwendet habe.
Mit freundlichen Grüßen - Martin
