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.
Unterstützt der STM32F1 überhaupt differentielle Leitungen? Ich halte das Unterfangen auch für sinnlos.
Nimm doch z.B. einen STM32F429 o.ä. statt eines F1, der hat eine SDRAM-Ansteuerung schon eingebaut, mit automatischem Refresh usw.
@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.
Außerdem zeigt Dein Link stinknormale SRAMs - und das ist ja keine Herausforderung für Dich.
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.
Ich schlage vor, Du adaptierst mal einen Ferritkernspeicher an einen Intel 8008. DAS ist retro. Bitte Meldung bei Erfolg. ;-)
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.
Ja. http://www.wolfgangrobel.de/museum/core.htm http://www.wolfgangrobel.de/museum/core2.htm http://www.wolfgangrobel.de/museum/core3.htm http://www.wolfgangrobel.de/museum/soemtron.htm (für A.K.) http://www.wolfgangrobel.de/museum/burroughs.htm http://www.wolfgangrobel.de/museum/core6.htm Und für Deine Adaption sicher interessant: http://www.wolfgangrobel.de/museum/corearduino.htm
Uiuiui, da hast du dir was vorgenommen. Mal DDR3 angenommen: Für die Spannung bräuchtest du erst mal bidirektionale Level-Shifter auf 1,35 oder 1,5V. Dann brauchst du noch LVDS-Transmitter und Receiver. Mit Lochraster wird das eher nix, generell möglich ist es aber. Zu DDR3 schnapp dir halt ein Datenblatt: https://www.micron.com/~/media/documents/products/data-sheet/dram/ddr3/2gb_1_35v_ddr3l.pdf Die Belegung der RAM-Module findet man z.B. hier: https://media.digikey.com/pdf/Data%20Sheets/Micron%20Technology%20Inc%20PDFs/MT8JTF(128,256)64A_RevB.pdf Die Datenblätter sollten die nötigen Informationen enthalten. Wäre interessant, ob es möglich ist. Ich vermute nicht ;-)
Wolfgang R. schrieb: > Ich schlage vor, Du adaptierst mal einen Ferritkernspeicher an einen > Intel 8008. DAS ist retro. Oder gleich ein Delay-Line-Memory ;-)
MiMa schrieb: > Oder gleich ein Delay-Line-Memory ;-) Guter Plan... http://www.wolfgangrobel.de/museum/iskra.htm
Mad schrieb: > Mal wieder rausgehen an die frische Luft! Freak! Erlaubt ist, was Spas macht. Das nennt man Hobby.
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.
:
Bearbeitet durch User
Es gibt noch pseudo-SRAM. Das sind SDRAM-Bausteine die man ansteuern kann als wären es SRAm, d.h. auch es funktioniert so langsam wie man will. Die gibts so bis 8MByte. https://www.mouser.de/search/refine.aspx?Ntk=P_MarCom&Ntt=111588076
Diese pseudo SRAMS sehen ganz nett aus, aber wenn ich davon 1GB kaufe, bekomme ich Ärger mit meiner Frau.
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.
Hmm, ja so kann man das natürlich auch sehen. Eine SD Karte habe ich schon einmal angesprochen, das war hardware-technisch trivial.
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.
SD Karten (egal welche) würden ohne Wear Levelling doch sicher innerhalb der Garantiezeit schon kaputt gehen.
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Ich glaube, du verwechselst da was. Dein SRAM-Baustein hat nur 512 KB. 2048 SRAM-Chips á 512 KB stapelt man nicht "mal eben so" übereinander.
:
Bearbeitet durch User
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 ist Das 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 Sommerloch Stefanus 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.
EDO-DRAM sind doch auch nur noch gebraucht zu haben Ich wollte schon aktuelle Speichermodule benutzen.
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.
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.