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?
Nunja, Zeit ist ja auch nicht wirklich zufällig, dann könntest du einen Timer dauerhaft zählen lassen und dessen momentanen Wert als Seed verwenden.
Die Karte hat schon eine eingebaute ID, es ist also nicht nötig so eine Datei anzulegen. Suche nach "cid sd card". -mv
:
Bearbeitet durch User
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.
Hatte eigentlich das hier gesucht. Keine Ahnung welche randr besser is. Beitrag "Glühwürmchen in Rotkohlglas gefangen"
@ 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.
:
Bearbeitet durch User
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:
1 | int get_next_random() |
2 | {
|
3 | read_from_EEPROM(RANDOM_SEED, &seed); |
4 | srand(seed); |
5 | random = rand(); |
6 | write_to_EEPROM(RANDOM_SEED, random); |
7 | return random; |
8 | }
|
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?
M. V. schrieb: > Die Karte hat schon eine eingebaute ID, es ist also nicht nötig so eine > Datei anzulegen. Suche nach "cid sd card". Das ist es. Danke.
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.
1 | /////////////////////////////////////////////
|
2 | // Zufallszahlengenerator
|
3 | |
4 | static uint16_t seed=10000; |
5 | |
6 | void sprng(uint16_t start) |
7 | {
|
8 | seed = start; |
9 | }
|
10 | |
11 | uint16_t prng(uint16_t max) |
12 | {
|
13 | uint16_t result; |
14 | |
15 | seed ^= seed<<7; |
16 | seed ^= seed>>9; |
17 | seed ^= seed<<5; |
18 | result = seed % max; |
19 | |
20 | return (result); |
21 | }
|
:
Bearbeitet durch User
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"
Falls du noch einen ADC Pin frei hast lass ihn einfach ein offenes Ende messen, da funktioniert auch ganz gut. Das Ergebnis benutzt du dann als seed.
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.
:
Bearbeitet durch User
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
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.