non-volatile memory ab 100MB und schnell

Hallo,

ich bin für einen Datenlogger auf der Suche nach einem nicht flüchtigen Speicher, so um die 100MB aufwärts.

Wichtig wäre mir dabei, dass ich den Speicher sehr schnell mit einem AVR (AT90USB1287) beschreiben und lesen kann.

Ich habe schon Experimente mit einer MicroSD-Karte mit ISP-Anbindung gemacht. Als Quarz für den AVR wurden 8MHz eingesetzt. Mehr geht leider laut Datenblatt nicht, da die Versorgungsspannung 3,3V beträgt. (Wegen komptibilität zur SD-Karte und noch anderen Bauteilen)
Die Schreibleistung ist dabei gerade so ausreichend, aber nur mit sehr viel Optimierung. Aber die Lese-Leistung ist einfach zu dürftig.

Beim AVR sind fast keine IO's genutzt, deshalb habe ich mir überlegt die Karte irgenwie parallel mithilfe von Schieberegistern anzubinden, die dann über eine extra (und höhere) Taktquelle getaktet werden, um eine hohe Zugriffsgeschwindigkeit, bei möglichst geringem Software- und Warte-Aufwand im AVR zu realisieren. Aber irgendwie kommt mir das alles viel zu kompliziert vor.

Gibt es vielleicht einen nicht flüchtigen Speicher in der Größenordnung 100MB, der auch parallelen Zugriff erlaubt? SMD löten ist überhaupt kein Problem, den AT90USB1287 habe ich auch geschafft. :-)

Viele Grüße
Andreas

ich seh keine Vorteil darin Schieberegister zwischen zu schalten, da solltest Du Dir nochmal die Ansteuerung der Karte ansehen, das kommt mir spanisch vor.
Der schnellste nichtflüchtige Speicher der mir so direkt einfällt ist FRAM, ist aber schweineteuer. Evtl. wär ja nomales SD-RAM mit Batteriepuffer ne Option?
Oder D-RAM mit entsprechender batteriegepufferter Refresh-Beschaltung?

da wirst du es aber verdammt schwer haben, die sind schweine teuer!!!

muss es den unbedingt NV-RAM sein!?

Mir würde da jetzt nur ein Flashspeicherchip OHNE controller in den Sinn kommen und diesen dann selber ansteuern um die Datenträgerstruktur zu umgehen, aber die sind auch eher schwer beschaffbar, bzw. versuch bei ner SD-Karte doch einfach den Controller zu umgehen! Basteln halt ^^

EDIT: Wie ich sehe hat sich da noch jemand etwas mehr damit beschäftigt ^^

http://de.farnell.com/spansion/s25fl...oic/dp/1791300 sowas z.B.

man leidet halt nur an den Schwächen von Flash, man sollte vll. einen kleinen nichtflüchtigen nicht-degenerierenden (MRAM, FRAM nur halt ganz klein) Zwischenspeicher für die Adresse haben um beim nächsten Schreiben da weiter zu amchen wo man aufgehört hat und dann erst beim erreichen der letzten Zelle wieder zum Anfang zurückkehren, damit der Speicher durchgehen gleichmäßig degenrieren kann! (Und vielleicht den Chip iwie austauschbar verbauen falls er mal ausfälle hat und gewechselt werden muss)

Parallel ansteuern könntest du wohl eine Compactflash-Karte. Aber über die Geschwindigkeit kann ich dir leider nicht viel sagen.

Hallo,

vielen Dank erst mal für die Vorschläge.

Erst mal zum Thema Geschwindigkeit: Ich habe mit oben genanntem AT90USB1287 einen digitalen Rekorder gebaut. Bei diesem lese ich die SD Karte und schicke die Aufzeichnungen per USB serieller Schnittstelle an den PC. Die dabei erreichte Geschwindigkeit liegt auf jeden Fall nur um die 30 bis 50 Kilobyte pro Sekunde, was mir vieeeel zu langsam vorkommt. Den Code dazu habe ich soweit optimiert, wie mir möglich war. Während der SPI das nächste Byte liest, wird das vorherige schon über USB gesendet.
Das Projekt liegt schon fast 2 Jahre zurück, deswegen kann ich mich nicht mehr so gut an die Details erinnern. Der Code schaut mittlerweile auch aus wie "böhmische Dörfer". Da müsste man sich erst mal wieder eindenken. SPI-Takt war das schnellstmögliche. Eventuell liegt es an der USB-Übertragung, obwohl die ja im AT90USB1287 inkl. Buffer direkt integriert ist.

Da müsste ich mal Tests machen, wie schnell ich da maximal übertragen kann, wenn ich z.B. immer das gleiche sende.

Ich möchte aber auch aus den ISP frei halten, damit die Software-Entwicklung einfach bleibt. Es war eine ewige Bastelei den AVR über ISP vernünftig schnell zu programmieren, obwohl eine SD-Karte angeschlossen ist.
Und wenn ich die SD-Karte nicht am integrierten ISP des AVR betreibe wird das serielle auslesen wohl sehr langsam. (Clock High/low, Bit lesen, Clock High/Low, Bit lesen...)

Der Vorteil durch Schieberegister, den ich mir erhoffe ist, dass der AVR nicht auf das Byte vom ISP "warten" muss. Das ganze müsste mit einer anderen, schnelleren Taktquelle für den Clock der Register so gelöst werden, dass der AVR das Byte parallel einliest und nur ein Signal gibt, dass das Schieberegister das nächste Byte lesen oder schreiben soll, also den Takt quasi wieder für 8 Zyklen startet. Den Takt für die Schieberegister muss man ermitteln, was die SD-Karte verträgt. Aber irgendwas im zweistelligen MHz-Bereich sollten schon drin sein.

Akku gebuffert muss ich mir noch mal überlegen. Die Anwendung soll optional eh am Akku betrieben werden. Aber eben nur optional...
Falls ich mich dafür entscheide: Hat jemand einen Vorschlag für einen Speicher in meiner Größenordnung? Wie hoch ist wird der stromverbrauch im "standby" sein? (Um mal grob den Buffer-Akku abzuschätzen)

Das mit dem rotierenden Beschreiben habe ich auch für die SD-Karte umgesetzt, da ich hier bedenken hatte. SD-Karten wären halt optimal zu tauschen, wenn sie mal zu viele Schreibzyklen haben sollten.
Wie viele Schreibzyklen es werden kann ich noch nicht genau sagen. Ich denke mal so ca. 5000 bis 10000 Einträge pro Woche mit einer Größe von durchschnittlich 50 Kilobyte. Das sollte eigentlich ewig halten mit modernen Flash-Chips und rotierendem Beschreiben.
Aber eventuell soll ein GPS-Datenlogger mit rein, da wirds dann heftiger. Hier müsste man sich wieder eine gute Speichermethode überlegen und ein paar Positionen sammeln, um dann auf einmal zu speichern.

Compactflash ist eine gute Idee, ich glaube ich weiß was du meinst. (Habe sowas schon mal gesehen) Die muss ich mir mal genauer anschauen.

Viele Grüße
Andreas

von dem Chip den ich dir gepostet habe gibt es Varianten mit Parallelinterface!

Hallo,

SD Karten können ganz schön schnell werden, aber das ist dann eine Art SPI mit 4 Datenleitungen und bis zu 50MHz. Das Protokoll dazu ist auch ziemlich aufwändig. Ich befürchte, du bewegst dich an der Grenze des mit einfachen Mitteln machbaren.

MfG Klebwax

Hallo,
ich habe mal angefangen das Thema SD-Karten-Ansteuerung über Schiebe-Register durchzudenken und muss sagen, dass es für mich sehr interessant ist. Deshalb möchte ich versuchen das umzusetzen. Ich habe mir dazu folgende Schaltung überlegt:

Anhang 18862

Hier meine Gedanken dazu, wie das ganze funktionieren soll:
Zur Initialsierung wird bei A4 an Pin S0 / S1 der Modus parallels laden eingestellt und mit einem Clock-Impuls von A1:PE4 der Wert binär 1000 ins Schieberegister geladen. Dann wird der Modus an S0 / S1 von A4 auf schieben umgestellt.
Jetzt wird A1:PE1 auf high gelegt, und mit 4 Clock-Impulsen von A1:PE4 ein Clock für das Schieberegister A6 erzeugt, und dieses so mit dem Wert binär 10000000 gefüllt.
A1:PE1 geht wieder auf low. Die Initialisierung ist damit abgeschlossen.
Das Schieberegister A4 erzeugt den Takt für einen Zyklus, der wie folgt aussieht:
Zuerst wird das Schieberegister A3 getaktet, damit der Wert an MOSI für die SD-Karte passt. Dann wird die SD-Karte getaktet, um das Bit an MOSI zu übernehmen und an MISO ein neues bereitszustellen. Dann wird A2: getaktet, um dieses Bit zu übernehmen. Als letzten Schritt wird A6 weiter geschoben. Dieses Register zählt dann die 8 zu übertragenden Bits.
A7:A schaltet den Takt frei für die Übertragung frei. Dieses Gater wird über das Flip-Flop A8:1 freigegeben. Eine 1 im Flip-Flop schaltet den Takt frei.
Die Übertragung eines Byte wird mithilfe eines Clock-Impulses an A1:PE5 gestartet. Durch diesen Impuls werden beide Flip-Flops in A8 auf 1 gesetzt. Die Freigabe des Taktes in A8:1 ist dann so lange aktiv, bis das letzte Bit im Schieberegister A6 erreicht ist. Mit diesem Bit wird A8:1 per Reset zurückgesetzt.
Die 1 im Flip-Flop A8:2 schaltet das MOSI-Schieberegister A3 auf paralleles laden, um das Byte vom AVR beim ersten Clock im Zyklus zu übernehmen. Dadurch steht auch gleich das erste Bit an MOSI der SD-Karte bereit. Im Zweiten "Zustand" des Zyklus wird das Flip-Flop A8:2 wieder durch einen Reset gelöscht, wodurch das MOSI-Schieberegister A3 auf schieben gestellt wird, um bei den nächsten Zyklus-Durchläufen die anderen Bits an MOSI durchzusschieben.
Nun läuft der Zyklus 8x durch, bis alle Bits ind und aus der SD-Karte geschoben wurden.
Durch löschen der Takt-Freigabe in A8:1 wird dem AVR über A1:PE6 signalisiert, dass die Übertragung abgeschlossen ist und das MISO-Byte der SD-Karte vom Schieberegister A2 einlesen werden kann.
Wer kann das vielleicht auch mal durchdenken. Bei folgenden Fragen bin ich mir noch unschlüssig bin:
1) kann das Ganze grundsätzlich so funktionieren?
2) Wie schnell kann der Takt maximal werden, was vertragen die Logik-Bausteine, die ich ausgesucht habe? Ich werde leider aus den Werten in den Datenblättern nicht ganz schlau, was maximal möglich ist. Die Versorgungsspannung soll 3,3V betragen.
3) ist das Schieberegister A6 nach einem Byte wieder im richtigen Anfangs-Status für das nächste Byte?
4) wird die Rückstellung der Flip-Flops mit den Transistoren BC847 so funktionieren, oder sind diese eventuell zu träge? Anonsten müsste ich hier wohl noch einen IC mit 2 NOT-Gattern benutzten.
5) wie erzeuge ich den Takt für das Ganze am besten? Soweit ich mich erinnere, muss eine SD-Karte erst mal mit einem langsamen Takt initialisiert werden, und dann kann man schneller werden. Theoretisch kann ich den Initilisierungs-Takt per A1:PE4 erzeugen, aber ich würde gerne trotzdem noch verschiede Geschwindigkeiten nutzen können, da ich nie weiß welche Karte eingesetzt wird. Die Schaltung sollte dann versuchen die maximal mögliche Geschwindigkeit der KArte herauszufinden und diese dann nutzen.
6) Eine Idee von mir zur Takterzeuzung wäre der Quarz des AVR. Ich betreibe den AT90USB1287 an 3,3V. Die maximal mögliche Taktfrequenz laut Datenblatt beträgt bei dieser Spannung 8MHz. Kann ich eventuell einen 64MHz-Quarz einsetzen und im AVR dann intern via Fuse um den Faktor 8 runterteilen? Wird das so funktionieren? Da der AVR im TQFP64-Gehäuse ist, ist Programmierung nur nach einlöten via ISP möglich. Wie wäre dass mit so einem Quarz beim ersten flashen. Bekomme ich hier eventuell Probleme? Und wie "zapfe" ich dann das 64MHz-Signal an, um es für die Schaltung oben zu nutzen?
Viele Grüße
Andreas

Der Flaschenhals bei dem Projekt ist dein Controller. Bei 8MHz wirst du auch beim parallelen Zugriff nicht sehr schnell werden.
Du wirst wohl einen schnelleren Controller brauchen. Entweder, du benutzt einen ARM-Controller, oder du verwendest einen CPLD, der die SD-Karte ausließt und die Daten an einen USB-Controller weiterleitet.
Dann könntest du weiter mit nem langsamen µC arbeiten und müsstest nur den CPLD managen.

ARM wäre wahrscheinlich "vernünftiger" ;D

Zu Punkt 6 deines letzten Posts: Das dürfte nichts werden. Du könntest aber einen 64MHz Taktgenerator verwenden, per Schieberegister teilen und das dann dem Controller zuführen.

Hallo lokirobotics,

Der parallele Zugriff soll nicht nur der Gechwindikgeit dienen. Wie oben erwähnt möchte ich die Karte nicht am ISP-Anschluß des AVR betreiben, da ich in der Vergangenheit damit oft viele Probleme durch die Mehrfachnutzung des Ports hatte.
Ich habe noch mal nachgeschaut. Die erreichte Geschwindigkeit beim auslesen der SD-Karte über ISP und gleichzeitiges senden über den im AVR integrierten USB-Anschluß mithilfe einer seriellen Schnittstelle als USB-Device beträgt ca. 30kByte bis 50kByte pro Sekunde.
Da habe ich mir erhofft etwas mehr zu erreichen. Aber wenn ich von 50kB ausgehen ist das ja schon eine Baudrate von 500kBaud. Vielleicht ist die serielle mein Problem und ich sollte mal ein Datenspeicher-Device versuchen.

Ich arbeite schon immer mit AVR, wenn es ein µC sein muss. Und du weißt, der Mensch ist ein Gewohnheitstier...
CPLD sagte mir nichts, dazu habe ich mir gerade mal einen Überblick auf Wikipedia verschafft. Hast du hier vielleicht speziell einen Vorschlag für mich welchen Chip ich verwenden sollte? Und auch für einen USB-Controller? Ich wollte den Atmel-Chip einsetzen, weil hier das USB bereits integriert ist. Bedingung für einen eigenen USB-Chip wäre natürlich, dass nicht nur Daten von der SD-Karte übertragen werden, sondern auch vom µC selbst. (Zum Beispiel um Einstellungen zu übertragen, etc.)

Viele Grüße
Andreas