Ich hatte früher vor wirklich langer langer Zeit mal ein DRAM Modul aus
einem PC an einen Mikrocontroller angeschlossen. Die damaligen DRAM
Module hatten eine überschaubare Anzahl von Pins die man problemlos in
Handarbeit löten konnte. Blöd war damals aber, dass der regelmäßige
Refresh ganz erhebliche CPU Ressourcen in Anspruch nahm. Deswegen hatte
ich solche Konstrukte danach stets vermieden.
Dank Sommerloch habe ich aber nun doch wieder Lust, diese Idee mit einem
STM32F1 nochmal zu wiederholen. Also einfach nur aus Spaß, ohne
konkreten Bedarf. Dieses mal soll es natürlich nicht 1MB sein, sondern
1GB oder mehr. Aber die aktuellen RAM Module die ich kenne (aus Laptops)
haben so kleine Kontakte, dass ich sie nicht löten kann. Außerdem sind
Hobby-taugliche technische Infos dazu rar.
Hat das in den vergangenen 1-5 Jahren mal jemand gemacht? Welche DRAM
Module könnte man heute verwenden und Hand-Löten?
Selbst wenn du es noch verlötest bekommst, wirst du feststellen, dass
das routing, die terminierung und die differenziellen signale noch ganz
andere anforderungen an dich stellen.
kurzum: vergiss es.
@Stefanus F. (stefanus)
>Dank Sommerloch habe ich aber nun doch wieder Lust, diese Idee mit einem>STM32F1 nochmal zu wiederholen. Also einfach nur aus Spaß, ohne>konkreten Bedarf. Dieses mal soll es natürlich nicht 1MB sein, sondern>1GB oder mehr.
Dein Sommerloch muss wirklich tief sein . . .
>Hat das in den vergangenen 1-5 Jahren mal jemand gemacht?
Ja, aber "nur" 16 MB am ATXmega.
Beitrag "Re: Viel RAM am kleinen Controller"
Es ist bestimmt auch nicht hilfreich das SD-Ram mit 1.5V arbeitet.
Vermutlich waere es sinnvoll da ein FPGA dazwischen zu schalten. Aber
klar, als kleine Fingeruebung fuer die heissen Tage nicht schlecht. :)
Olaf
Ich habe gerade dieses Modul gefunden, aber das wären ja sie alten
bekannten Chips aus den 90er Jahren zum Schweinepreis:
> http://www.electromyne.de/RAMs---Memory-Other-RAM---Memory-Hitachi-HM62256LFP-10T-1Mbit-4x256kbit-SRAM-Static-RAM-Memory-Module-Gold-DIP-32.html> Unterstützt der STM32F1 überhaupt differentielle Leitungen?
Natürlich nicht. Mir in meiner grenzenlosen Naivität auch gar nicht
bewusst, dass ich differentielle Leitungen benötige.
> Nimm doch z.B. einen STM32F429 o.ä. statt eines F1, der hat eine> SDRAM-Ansteuerung schon eingebaut, mit automatischem Refresh usw.
Das wäre mir allerdings zu einfach, da fehlt der retro Faktor :-)
> Vermutlich gibt es in diesem Zusammenhang überhaupt nichts Sinnvolles!
Das habe ich befürchtet. Wenn ich das gewünschte nicht finde, dann gibt
es das meistens auch nicht.
Ist nicht schlimm, mir fällt sicher noch anderer Unsinn ein, denn man
zusammen löten könnte.
FPGA ist ein gutes Stichwort, kenne ich noch nicht.
Stefanus F. schrieb:> Das wäre mir allerdings zu einfach, da fehlt der retro Faktor :-)
Der STM32F1 ist nun auch nicht soooo alt, dass man ihn schon als retro
bezeichnen müsste.
Wolfgang R. schrieb:> Ich schlage vor, Du adaptierst mal einen Ferritkernspeicher an> einen> Intel 8008. DAS ist retro.
Besser an einen STM32F7, der hat einen L1-Cache, dann ist der Zugriff
schneller.
> Ich schlage vor, Du adaptierst mal einen Ferritkernspeicher
Früher als Schüler bekam ich mal so ein Teil vom Schrott in die Finger.
Habe ich dummerweise direkt wieder zurück auf den Schrotthaufen
geworfen. Heute würde es jeder Besucher bestaunen.
@ Stefanus F. (stefanus)
>Ich habe gerade dieses Modul gefunden, aber das wären ja sie alten>bekannten Chips aus den 90er Jahren zum Schweinepreis:>>http://www.electromyne.de/RAMs---Memory-Other-RAM-...
Das ist ja auch Unsinn^3. Ersten nur SRAM, der hat geringe
Speicherdichten und 2. Arduino-Style Modul.
>Natürlich nicht. Mir in meiner grenzenlosen Naivität auch gar nicht>bewusst, dass ich differentielle Leitungen benötige.
Kommt auf den Speicher an. Old School SDRAM funktioniert noch mit 3,3V
CMOS, auch beim Takt. Erst ab DDR1 wird's differentiell.
>Ist nicht schlimm, mir fällt sicher noch anderer Unsinn ein, denn man>zusammen löten könnte.
Mach mal.
Wolfgang R. schrieb:> Ich schlage vor, Du adaptierst mal einen Ferritkernspeicher an einen> Intel 8008. DAS ist retro.
Oder gleich ein Delay-Line-Memory ;-)
Stefanus F. schrieb:> Blöd war damals aber, dass der regelmäßige> Refresh ganz erhebliche CPU Ressourcen in Anspruch nahm. Deswegen hatte> ich solche Konstrukte danach stets vermieden.
Also das ist noch recht handzahm selbst wenn man das "zu Fuß" macht ohne
natives DRAM-Interface. Mit CAS-before-RAS- oder Hidden-Refresh ist der
Ressourcenbedarf für den Refreshvorgang überschaubar. Aber jeder
Speicherzugriff benötigt mehrere Aktionen und ist damit in Summe relativ
aufwändig. Das geht aber auch noch, je nach Anspruch.
Hier gibt es dazu einen Klassiker:
Beitrag "2MB DRAM an AVR"
Aktuell wäre es wohl das Sinnvollste einen Controller zu nehmen, der ein
SDRAM-Interface schon in Hardware integriert hat. SDRAM ist zwar nicht
brandaktuell, aber in der Regel ausreichend schnell, noch aufzutreiben
und auch noch von Hand lötbar und weniger kritisch in der Ansteuerung
und zudem mit 3,3-Volt noch im "Hobbybereich". Allerdings wirst du damit
wohl kaum Gigabytes zusammenbekommen.
Entweder echtes SDRM mit programmierbaren MUX dafür für die übergrossen
Adressen, oder ein FPGA mit integriertem DDR-Controller.
Alles andere ist Mumpitz oder zu teuer!
Wenn es etwas Sinnvolles sein soll, täte ich einen IDE-Controller nehmen
und Flahs-Disks dranhängen oder eine andere konventionalle Form des
Flashs.
Flash Speicher wäre natürlich einfach, gibt's ja auch mit seriellen
Interface. Aber das ist weit von RAM entfernt, was die Anzahl der
Schreibzyklen angeht.
Stefanus F. schrieb:> Aber das ist weit von RAM entfernt, was die Anzahl der> Schreibzyklen angeht.
Ich bezweifle, dass Du eine grosse SSD (sagen wir mal 1TB) mit einem
STM32F1 in vernünftiger Zeit totkriegst.
Ja eine SD-Karte ist wirklich trivial und halt auch schnell kaputt, wenn
man nicht selber ein wear-leveling implementiert.
Aber Du könntest wirklich eine SATA-Library für den STM32 entwickeln,
das gäbe es bestimmt noch den einen oder anderen Abnehmer dafür und wäre
meiner Meinung nach auch 100 mal sinnvoller als unmengen an SDRAM
anzuschliessen.
abc. schrieb:> Selbst wenn du es noch verlötest bekommst, wirst du feststellen,> dass das routing, die terminierung und die differenziellen signale noch> ganz andere anforderungen an dich stellen.>> kurzum: vergiss es.
Palaber von jemand der keine Ahnung hat, dass man den Signaltakt auch
anpassen kann...
Johnny B. schrieb:> wenn man nicht selber ein wear-leveling implementiert.
SD Karten beinhalten bereits ein Wear Leveling. Dafür haben die eine
komplexe Firmware. Das funktioniert aber ggf. nur dann optimal wenn man
sich 100% an die Spezifikation hält, inklusive der vorgeschriebenen
Dateisysteme FAT16/FAT32/exFAT.
Johnny B. schrieb:> Ja eine SD-Karte ist wirklich trivial und halt auch schnell kaputt, wenn> man nicht selber ein wear-leveling implementiert.
Das wear-leveling sollte eigentlich den Controller auf der SD Karte
machen. Allerdings gibt es da durchaus Qualitätsunterschiede bei den
Algorithmen.
@Johnny B. (johnnyb)
>Ja eine SD-Karte ist wirklich trivial und halt auch schnell kaputt, wenn>man nicht selber ein wear-leveling implementiert.
Selten so einen Blödsinn gelesen. Aber wir wissen ja, von wem es kommt.
Stefanus F. schrieb:> Dank Sommerloch habe ich aber nun doch wieder Lust, diese Idee mit einem> STM32F1 nochmal zu wiederholen. Also einfach nur aus Spaß, ohne> konkreten Bedarf. Dieses mal soll es natürlich nicht 1MB sein, sondern> 1GB oder mehr.
Ach, und ertens WIE und zweitens WOFÜR willst du 1 GB RAM bei einem
STM32F1xx benutzen?
Natürlich geht sowas nicht, denn die STM32F1xx haben m.W. überhaupt
keinen Peripheriecore für externen SDRAM.
Es dürfte auch sonst nicht gehen, denn in der Aufteilung des 4 GB großen
Adressraumes ist m.W. bei diesen Chips kein Bereich für einen externen 1
GB großen Speicher vorgesehen.
Zum dritten ist es bei RAM-Größen im GB Bereich eher üblich, LPDDRAM zu
benutzen. SDRAM gibt es m.W. in diesem Bereich nicht - und mal eben
davon eine Handvoll anzuschließen, ist auch nicht so einfach.
Wenn du sowas wie einen LPC17xx oder LPC4088 nimmst, dann kannst du
wenigstens SDRAM überhaupt anschließen und diese Chips haben m.W. bis
zu 4 Selects dafür. Da kommt man mit derzeitigen Mitteln auf 64 MB - und
das ist für so einen Controller schon recht ansehnlich.
Wozu also sich 1 GB vornehmen?
W.S.
W.S. schrieb:> Ach, und ertens WIE und zweitens WOFÜR willst du 1 GB RAM bei einem> STM32F1xx benutzen?
Als Gedankenexperiment finde ich das interessant.
"Wofür" spielt bei einem Hobby ja an sich keine Rolle,
sonst wär's ja keins.
> Natürlich geht sowas nicht, denn die STM32F1xx haben m.W. überhaupt> keinen Peripheriecore für externen SDRAM.
Man kann sowas auch mit ein bisschen Klebstofflogik mit Pins machen,
also wie AVRCPM einen DRAM ansteuert. Da sind 128 KB RAM auch kein
Problem, obwohl weder Peripheriecore noch Adressraum dafür existieren.
Es mag zwar ein weiter Weg sein, aber das hier:
https://www.youtube.com/watch?v=yHXx3orN35Y ist auch so ein
offensichtlicher Fall von "natürlich geht das nicht". Oder ähnliche
solche Dinge. Die sind genau so lange unmöglich, bis sie jemand macht.
Heißt ja nicht, dass es einfach, billig, schnell oder auch nur
ansatzweise gut wird.
W.S. schrieb:> Ach, und ertens WIE und zweitens WOFÜR willst du 1 GB RAM bei einem> STM32F1xx benutzen?>> Natürlich geht sowas nicht, denn die STM32F1xx haben m.W. überhaupt> keinen Peripheriecore für externen SDRAM.
Die Frage stelle ich mir auch. ARM-Kern irgendwie mit 1 GB Ram
kombinieren..., da muß ich irgendwie an einen Raspberry Pi 3 denken...
W.S. schrieb:> Wozu also sich 1 GB vornehmen?
Naja, wenn es dem Esel zu bunt wird geht er aufs Eis tanzen.
Bedauerlich wenn man nicht weiss was man mit seiner Zeit
anfangen soll.
Oder man schlüpft einfach mal in die Rolle des Troll-Narren.
> Ach, und ertens WIE und zweitens WOFÜR willst du 1 GB RAM bei einem> STM32F1xx benutzen?
Habe ich doch geschrieben, aus Langeweile und Spaß an der Aufgabe.
Frage nicht nach dem praktischen Sinn, da gibt es keinen.
> Natürlich geht sowas nicht, denn die STM32F1xx haben m.W. überhaupt> keinen Peripheriecore für externen SDRAM.
Das alleine wäre erstmal kein Hindernis. Man kann Speicherchips auch an
GPIO Pins anschließen - natürlich entsprechend langsamer und mit mehr
Softwareaufwand ansprechbar.
> Es dürfte auch sonst nicht gehen, denn in der Aufteilung des 4 GB großen> Adressraumes ist m.W. bei diesen Chips kein Bereich für einen externen 1> GB großen Speicher vorgesehen.
Auch das ist kein Hindernis. Ich habe auch schon mit einem ATmega644
eine SD Karte mit mehreren GB (sinnvoll) benutzt. Ich habe nicht
verlangt, dass der ganze Speicher an einem Stück in den Adressraum für
Daten eingeblendet wird und genau so wie "normales" RAM ansprechbar sein
soll.
> Zum dritten ist es bei RAM-Größen im GB Bereich eher üblich, LPDDRAM zu> benutzen. SDRAM gibt es m.W. in diesem Bereich nicht
Ich habe auch nicht nach SDRAM gefragt, sondern nach "ganz viel DRAM"
und dann gleich Notebook Speichermodule als ersten Ansatz genannt.
Jedenfalls ist der aktuelle Stand, dass es nicht so einfach geht, wie
ich das gerne hätte. Erster Knackpunkt ist nach wie vor das Rastermaß
der Anschlüsse, als nächstes käme die Notwendigkeit zahlreicher
Levelshifter. So viel Aufwand will ich in dieses Experiment dann doch
nicht rein stecken.
Früher (TM) konnte man Speichermodule von PC's quasi direkt an die GPIO
Ports anschließen und die hatten damals auch noch handliche Anschlüsse,
nur eine Reihe im 2,54mm Raster. Ich suche nach Modulen, die aktuell im
Handel sind und ähnlich einfach verwendbar sind (oder fertige
Adapterplatinen, die das ähnlich ermöglichen).
Daraus wird wohl nichts. Macht nichts, war sowieso ohne konkreten
Bedarf.
Stefanus F. schrieb:> Ich suche nach Modulen, die aktuell im Handel sind und ähnlich einfach> verwendbar sind
Gibt's nicht, weil die Speicherinterfaces sehr viel komplexer geworden
sind. Die größten Speichermodule, die es in der "klassischen" Bauform
mit 30 Pins gab, waren AFAIK 4-MByte-Module. Die aber sind seit gut
einem Vierteljahrhundert obsolet.
Stefanus F. schrieb:> Frage nicht nach dem praktischen Sinn, da gibt es keinen.
Das ist mir fremd.
Basteleien sollten nach meiner Meinung IMMER einen praktischen Sinn
haben, auch wenn dieser sich zunächst nicht in einem benutzbaren Gerät
manifestiert, sondern "nur" zu einem Zuwachs an Wissen&Können im eigenen
Kopfe, also zu einer Erweiterung des eigenen Horizontes führt.
W.S.
Falk B. schrieb:> @Johnny B. (johnnyb)>>>Ja eine SD-Karte ist wirklich trivial und halt auch schnell kaputt, wenn>>man nicht selber ein wear-leveling implementiert.>> Selten so einen Blödsinn gelesen. Aber wir wissen ja, von wem es kommt.
Du scheinst 0 Ahnung zu haben und beleidigst trotzdem Leute mit Deinem
Unwissen; in der Spec. zu SDHC wird nirgends vorgeschrieben dass Wear
Leveling implementiert sein muss. Ein Hersteller kann es implementieren
wenn er will, aber eine Garantie, dass Du einfach eine SD Karte kaufen
kannst und die macht dann selber Wear Leveling gibt es nicht.
Dr. Sommer schrieb:> Johnny B. schrieb:>> wenn man nicht selber ein wear-leveling implementiert.> SD Karten beinhalten bereits ein Wear Leveling. Dafür haben die eine> komplexe Firmware. Das funktioniert aber ggf. nur dann optimal wenn man> sich 100% an die Spezifikation hält, inklusive der vorgeschriebenen> Dateisysteme FAT16/FAT32/exFAT.
Welche Spezifikation meinst Du, SDXC?
In der SDHC ist jedenfalls nix von Wear Leveling drin und daher auch
nicht vorgeschrieben. Wenn's ein Hersteller trotzdem implementiert, dann
sieht man das im Datenblatt.
Rufus Τ. F. schrieb:> Die größten Speichermodule, die es in der "klassischen" Bauform> mit 30 Pins gab, waren AFAIK 4-MByte-Module.
16MB gabs auch noch - die AWE32 konnte mit ihren zwei Slots 32MB
fressen.
Johnny B. schrieb:> Welche Spezifikation meinst Du, SDXC?> In der SDHC ist jedenfalls nix von Wear Leveling drin und daher auch> nicht vorgeschrieben.
Die SD Specification in allen Versionen. Das steht allerdings nicht im
öffentlichen (simplified) Teil. Das Wear Leveling ist in der Tat nicht
spezifiziert; es ist allerdings nicht völlig abwegig zu vermuten, dass
das Wear Leveling der Hersteller darauf abgestimmt ist, genau dann gut
zu funktionieren, wenn die Karte nach Spezifikation betrieben wird.
Macht doch was ihr wollt; persönlich verlasse ich mich jedenfalls nie
auf Vermutungen, dass etwas implementiert sein könnte obwohl es nicht
müsste. Vorallem nicht bei seriösen Projekten.
Johnny B. schrieb:> Vorallem nicht bei seriösen Projekten
Windows z.B. (könntr man als seriöses Projekt zählen) weiß überhaupt
nicht wie SD Karten funktionieren und kann da gar kein Wear Leveling
machen. Da SD Karten meistens mit FAT genutzt werden, wird die FAT
selbst sehr häufig überschrieben. Hätten die Karten kein Wear Leveling,
würden diese paar Blöcke sehr schnell kaputt gehen. So etwas würde sich
nicht verkaufen. Es gibt irgendwo eine Website wo jemand SD Karten
seziert hat und einen Controller mit 128KB Programmspeicher vorgefunden
hat; was soll da sonst drin sein außer cleverem Wear Leveling? Wenn man
sich die Timings der diversen FAT Operationen auf SD Karten anschaut
ergeben sich "kuriose" Artefakte; die würde es bei einem dummen flachen
Speicher nickt geben.
Wie machst du denn Wear Leveling? Karte außerhalb der Spezifikation
betreiben und kein FAT nutzen?
@ Johnny B. (johnnyb)
>Macht doch was ihr wollt; persönlich verlasse ich mich jedenfalls nie>auf Vermutungen, dass etwas implementiert sein könnte obwohl es nicht>müsste. Vorallem nicht bei seriösen Projekten.
Also bei keinem DEINER Projekte ;-)
Da es ohnehin ohne konkrete Anwendung ist, wäre ich bei den
Anforderungen etwas flexibler.
Wenn du bei der Kapazität Abstriche machst, kanst du mit SDRAM den Rest
umsetzen und hast weniger Baustellen auf einmal. So paßt z.B. die
Spannung zu dem von dir ausgesuchen Mikrocontroller.
Rufus Τ. F. schrieb:> Gibt's nicht, weil die Speicherinterfaces sehr viel komplexer geworden> sind. Die größten Speichermodule, die es in der "klassischen" Bauform> mit 30 Pins gab, waren AFAIK 4-MByte-Module.
Die Dinger gab's auch mit 16 MB, es gibt 12 Adresspins (= 24 Adressbit).
Hab ich aber nie in der Realität gesehen, schon die 4 MB-Module sind in
meiner Wahrnehmung eher selten.
Man kann aber die 72-pinnigen Module (EDO-DRAM) grundsätzlich genauso
ansteuern, die können bis zu 256 MB pro Modul. Damit kommt man schon
relativ nahe an das ran, was Stefanus möchte.
Stefanus F. schrieb:> sondern> 1GB oder mehr
wo ist das Problem mit SRAM
512MBx8 gibt es doch im 1,27mm Raster, davon einige gestapelt nur die CS
Leitungen extra und du hast deine GB, 2 für 1GB x 8 Bit
https://de.rs-online.com/web/p/speicherbausteine-sram/0538160/
früher TM ('84) hatte ich 6116 o.ä. 2Kx8 14 Stück gestapelt im PC1500
eingelötet, heute genügt ein 32Kx8 für den Maximalausbau.
Mit 512kx8 macht man eine schöne Ramdisk
Falk B. schrieb:> @ Johnny B. (johnnyb)>>>Macht doch was ihr wollt; persönlich verlasse ich mich jedenfalls nie>>auf Vermutungen, dass etwas implementiert sein könnte obwohl es nicht>>müsste. Vorallem nicht bei seriösen Projekten.>> Also bei keinem DEINER Projekte ;-)
Falk, lass mal gut sein mit Deinen Beleidigungen. Es wird langsam
kindisch was du hier abziehst.
Johnny B. schrieb:> Macht doch was ihr wollt; persönlich verlasse ich mich jedenfalls nie> auf Vermutungen, dass etwas implementiert sein könnte
Das sollst du auch gar nicht. Und mußt du auch gar nicht. Der Hersteller
der SD Karten garantiert eine gewisse Lebensdauer - wenn du dich an
die Spezifikation, u.a. des zu verwendenden Filesystems hältst.
Ob er zur Einhaltung dieses Vertrags wear leveling implementiert (zu
99.9% wahrscheinlich) oder nicht, ist dabei seine Sache und für den
Anwender vollkommen nebensächlich.
Es mag ja interessant sein, darüber zu spekulieren oder auch Details
durch reverse engineering heraus zu bekommen. Aber für den praktischen
Gebrauch (vulgo: bestimmungsgemäße Verwendung) von SD-Karten hat das
keinen direkten Nutzen.
Johnny B. schrieb:> Du scheinst 0 Ahnung zu haben und beleidigst trotzdem Leute mit Deinem> Unwissen; in der Spec. zu SDHC wird nirgends vorgeschrieben dass Wear> Leveling implementiert sein muss.
Die SD-Karten-Spezifikation beschreibt die zu verwendenden Dateisysteme.
Da diese keinerlei Wear Leveling vorsehen, ist es offensichtlich, daß
die Karte selbst sich darum kümmern muss -- und das ist bei jeder
Speicherkartentechnik mit integriertem Controller so.
Nur uralte Systeme wie SmartMedia und xD-Card arbeiteten controllerlos.
@ Axel S. (a-za-z0-9)
>Es mag ja interessant sein, darüber zu spekulieren oder auch Details>durch reverse engineering heraus zu bekommen. Aber für den praktischen>Gebrauch (vulgo: bestimmungsgemäße Verwendung) von SD-Karten hat das>keinen direkten Nutzen.
Aber für Johnny B ist der Nutzen immens! Wichtigtuerei und Geschwätz!
Hat der TO das Projekt jetzt schon angefangen? Gibt es erste Ergebnisse,
die wir bestaunen dürfen? Oder müssen wir diese Grunsatzdiskussion über
Sinn und Unsinn einer solchen Aktion weiter führen?
Falk B. schrieb:> @ Axel S. (a-za-z0-9)>>>Es mag ja interessant sein, darüber zu spekulieren oder auch Details>>durch reverse engineering heraus zu bekommen. Aber für den praktischen>>Gebrauch (vulgo: bestimmungsgemäße Verwendung) von SD-Karten hat das>>keinen direkten Nutzen.>> Aber für Johnny B ist der Nutzen immens! Wichtigtuerei und Geschwätz!
Falk, Du als Hobbybystler kannst es Dir vielleicht leisten, dass mal ein
Gerät ausfällt, dann tust du halt einfach eine neue Speicherkarte rein
und dann ist es gut. Die Erde dreht sich weiter, alles ok.
Aber ich entwickle für die Industrie und da wird nun mal eine gewisse
Qualität und Lebensdauer von Baugruppen und Geräten erwartet oder gar
verlangt. Da muss man sich schon sicher sein, dass die verbauten
Komponenten auch den Anforderungen entsprechen und kann sich nicht auf
Vermutungen verlassen.
Im Falle der SD-Karten wurde hier geschrieben, dass die meisten wohl ein
Wear Leveling implementiert haben, was ich auch nicht bezweifle. Für ein
Industrieprodukt würde ich mich dann halt absichern und im Datenblatt
nachschauen ob dies wirklich der Fall ist und dem Einkäufer auch
mitteilen, dass die ausgesuchte und per Datenblatt überprüfte SD-Karte
ohne Abklärungen nicht einfach durch eine andere ersetzt werden darf.
Zu gross ist sonst das Risiko, dass beim Kunden ein Gerät ausfällt und
dies zu immensem Ärger, Schaden und Kosten führt.
Johnny B. schrieb:> Für ein> Industrieprodukt würde ich mich dann halt absichern und im Datenblatt> nachschauen ob dies wirklich der Fall istDas ist ja auch sinnvoll. Aber bei wie vielen Karten bekommt man ein
Datenblatt? Auf FAT zu verzichten und das Wear Leveling irgendwie selbst
zu machen dürfte stark kontraproduktiv sein.
Stefanus F. schrieb:> Dank SommerlochStefanus F. schrieb:> Also einfach nur aus Spaß, ohne> konkreten Bedarf.
Soweit der Ansatz des TO... warum eskalieren die Threads hier immer so
in Grundsatzdiskussionen?
> Hat der TO das Projekt jetzt schon angefangen?
Nein habe ich nicht. Wenn du mitgelesen hast, kennst du auch den Grund.
Nur so zum Spaß ein Fass ohne Boden aufmachen ist nicht mein Ding.
> Oder müssen wir diese Grunsatzdiskussion über> Sinn und Unsinn einer solchen Aktion weiter führen?
Du musst gar nichts, nur irgendwann sterben.
Stefanus F. schrieb:> Nur so zum Spaß ein Fass ohne Boden aufmachen ist nicht mein Ding.
Na ja, Du wolltest doch das Sommerloch auffüllen - und der Sommer ist
groß dieses Jahr! Bloß weil es schwierig wird jetzt gar nichts machen,
ist aber auch langweilig...
;-)
Johnny B. schrieb:> Im Falle der SD-Karten wurde hier geschrieben, dass die meisten wohl ein> Wear Leveling implementiert haben, was ich auch nicht bezweifle. Für ein> Industrieprodukt würde ich mich dann halt absichern und im Datenblatt> nachschauen ob dies wirklich der Fall ist
Das ist - mit Verlaub - Unsinn. Was du im Datenblatt der Karte
nachschlagen mußt, ist ob die vom Hersteller garantierte Lebensdauer
unter Berücksichtigung deines Nutzungsprofils ausreicht. Wie der
Hersteller diese erreicht, ist vollkommen belanglos. Details wird er dir
im Normalfall gar nicht und im besten Fall nur gegen NDA erzählen.
Wear-leveling findet jenseits der Schnittstelle statt, intern. Es ist
aus extener Sicht nicht erkennbar. Daher muß es nicht im Dateblatt
stehen, auch wenn es sich beim Marketing gut macht. Wenn es also genannt
ist, ok. Steht es nicht drin, heißt das noch gar nichts.
Allerdings:
Wenn bestimmte Dateisyteme vorgegeben werden die nicht speziell selbst
schon auf die Eigenheiten von Flash Rücksicht nehmen, ist das ein
starkes, nahezu sicheres Indiz dafür, daß Wear-Leveling vorhanden ist.
Der Controller muß erkennen können welche Sektoren gelöscht/freigegeben
werden. Das gelingt nur, wenn der Kontroller das Dateisystem kennt oder
explizit gelöscht wird, wie bei TRIM. Geschieht es nur implizit, also
wenn "überschrieben" wird, dann sind die Möglichkeiten stark
eingeschränkt und es wird langsam.
Wie auch immer, das Thema ist hier stark OT.
Wie auch immer, zu "Fuß" (Software) ohne DRAM-Schnittstelle in Hardware
sind sogar die alten FPM- und EDO-Bausteine gut zu gebrauchen, die aber
nur noch begrenzt verfügbar sind. Ich habe da einen Vorrat angelegt. Der
Overhead durch das Refresh wird stark überschätzt. Das kann man sehr gut
per Timer erledigen.
S. R. schrieb:> du verwechselst da was. Dein SRAM-Baustein hat nur 512 KB.
stimmt und 2 sind 1MB
ist warm, an GB kommt man so lange nicht ran ausser mit SD flash
Stefanus F. schrieb:> Nein habe ich nicht. Wenn du mitgelesen hast, kennst du auch den Grund.
Hast du mal über EDO-DRAM (also die 72-pinningen SIMMs) nachgedacht? Die
lassen sich wie normales DRAM ansteuern und kommen pro Modul immerhin in
den dreistelligen Megabyte-Bereich.
Stefanus F. schrieb:> Ich wollte schon aktuelle Speichermodule benutzen.
Achso, das hatte ich überlesen. Dann hast du tatsächlich genau garkeine
sinnvollen Möglichkeiten.
Johnny B. schrieb:> Aber Du könntest wirklich eine SATA-Library für den STM32 entwickeln,> das gäbe es bestimmt noch den einen oder anderen Abnehmer dafür und wäre> meiner Meinung nach auch 100 mal sinnvoller als unmengen an SDRAM> anzuschliessen.
Wenigstens bewegt sich SDRAM im Bereich des Möglichen. SATA dürfte man
überhaupt nicht ohne einen externen Controller/FPGA hinbekommen. Allein
wegen den IO-Standards und Frequenzen.
M. H. schrieb:> SATA dürfte man überhaupt nicht ohne einen externen Controller/FPGA> hinbekommen.
SATA lässt sich recht günstig auf PATA adaptieren, und das wiederum kann
mit einem µC angesteuert werden. Mit mäßiger Performance, da natürlich
die verschiedenen UDMA-Modi nur schwer nachzubilden sein dürften, aber
immerhin.
