Was ist besser: FRAM oder MRAM? Ich überlege es, in einem Projekt ca. 512-1024kb SPI-Speicher zu verwenden. Die Frage nur, welchen?
Man sollte bei dem verlinkten Dokument nicht übersehen, dass diese Gegenüberstellung von einem Hersteller angefertigt wurde, der MRAMs verkauft. Überraschung: hier ist MRAM deutlich besser bewertet als FRAM...
Wolfgang R. schrieb: > Man sollte bei dem verlinkten Dokument nicht übersehen, dass diese > Gegenüberstellung von einem Hersteller angefertigt wurde, der MRAMs > verkauft. Überraschung: hier ist MRAM deutlich besser bewertet als > FRAM... Das ist zweifellos richtig. Man muss schon auf die einzelnen Punkte, die einem wichtig sind, noch näher eingehen.
Dort steht, MRAM ist einfach CMOS und FRAM ist komplizierter in Herstellung. Dann die Frage: warum kostet MRAM ca. 2x gegen FRAM?
> Überraschung: hier ist MRAM deutlich besser bewertet als FRAM...
Ja, vor allem sehe ich eher FRAMs in Schaltungen als MRAMs.
Ich meine mich z.B dunkel zu erinnern das eines der Probleme
bei MRAMs ein hoher Strombedarf war. Ist das noch so?
Vanye
Vanye R. schrieb: > Ich meine mich z.B dunkel zu erinnern das eines der Probleme > bei MRAMs ein hoher Strombedarf war. Ist das noch so? Ja, der ist schon deutlich höher, insbesondere beim Schreiben.
Maxim B. schrieb: > Dort steht, MRAM ist einfach CMOS und FRAM ist komplizierter in > Herstellung. Dann die Frage: warum kostet MRAM ca. 2x gegen FRAM? Weil der Verkaufspreis und die Herstellungskosten nicht das gleiche sind.
Hallo, MRAM soll ja langfristig SDRAM ersetzen. Wenn ich das so lese ist MRAM in allen Belangen gegenüber FRAM überlegen. Die Anfälligkeit gegenüber starken Magnetfelder von MRAM widerlegt elektronikpraxis. Falls das doch relevant wäre nimmt man was anderes. So lese ich das heraus. https://www.elektronikpraxis.de/auswahlkriterien-fuer-nicht-fluechtige-speichertechnologien-a-119208/ https://www.elektronikpraxis.de/speicher-pcm-reram-fram-und-mram-im-aufwind-a-abb81bfa0e8b2e9adfa2cdb7ffb0d648/ Zum TO. Schau auf die Kosten wenn der Rest egal ist. Warum soll man in der Firma anders handeln als privat? Notwendige Eigenschaften, dann kommt der Preis. Außer das ist dermaßen billig, dann kann man die Goldvariante nehmen. :-)
H. H. schrieb: > Das ist zweifellos richtig. Man muss schon auf die einzelnen Punkte, die > einem wichtig sind, noch näher eingehen. Der wichtigste Punkt bei FRAM ist immer noch die beschränkte Zyklenzahl. Heutige Bausteine erreichen da durchaus amtliche Werte, aber als RAM-Ersatz taugt das Zeug nicht. Und aufpassen: lesen ist bei FRAM destruktiv. D.h. jeder Lesezugriff löst auch einen Schreibzugriff ("refresh") aus.
Soul E. schrieb: > Der wichtigste Punkt bei FRAM ist immer noch die beschränkte Zyklenzahl. Cypress gibt z.B. beim FM24C16 10^12 Cycles an, kein Vergleich zu den bei Flash üblichen 10^5. Mit Wear Leveling kõnnte man im praktischen Einsatz noch mehr rausholen. Soul E. schrieb: > als RAM-Ersatz taugt das Zeug nicht. Nichtflüchtiges RAM ist ohnehin problematisch, solange die Hardware es nicht sicher verschlüsselt. Soul E. schrieb: > Und aufpassen: lesen ist bei FRAM destruktiv. Das relativiert sich allerdings mit einem Cache.
Hmmm schrieb: > Soul E. schrieb: > Cypress gibt z.B. beim FM24C16 10^12 Cycles an, kein Vergleich zu den > bei Flash üblichen 10^5. Mit Wear Leveling kõnnte man im praktischen > Einsatz noch mehr rausholen. Richtig. Aber die 10^12 beim FRAN sind lesen&schreiben, die 10^5 beim Flash sind nur Schreibzyklen, lesen darf man Flash beliebig oft. Das muss einem klar sein. > Das relativiert sich allerdings mit einem Cache. Ja, so hat man bei jedem Einschalten genau einen Verschleißzyklus, und dann reichen die 10^12 verdammt lange.
Bei zerstörendem Lesen hätte ich immer ein ungutes Gefühl. Was passiert, wenn zufällig beim Lesen die VCC einbricht. Haben die FRAM einen internen Pufferkondensator und ein funktionierendes early power fail detection?
Peter D. schrieb: > Bei zerstörendem Lesen hätte ich immer ein ungutes Gefühl. Was passiert, > wenn zufällig beim Lesen die VCC einbricht. > Haben die FRAM einen internen Pufferkondensator und ein funktionierendes > early power fail detection? Nein. Das musst Du extern vorhalten. Der Elko muss genügend Reserve liefern, so dass ein Schreibvorgang beendet werden kann. Ist ja bei EEPROM (bzw NVRAM-Emulation im FlashROM) nicht anders. Wenn es für einen Schreibvorgang reicht, reicht es für den Refresh natürlich auch.
> Ist ja bei EEPROM (bzw NVRAM-Emulation im FlashROM) nicht anders.
Und FRAMs sind VIEL schneller wie EEPROMs. Vermutlich reicht
da der uebliche 100nF bereits aus.
Vanye
Soul E. schrieb: > Ist ja bei > EEPROM (bzw NVRAM-Emulation im FlashROM) nicht anders. Da ist aber ein deutlicher Unterschied, EEPROM, Flash lesen ist nicht zerstörend. Wenn z.B im FRAM gerade der Bootloader ausgeführt wird und sich zerstört, dann wars das. Im Flash dagegen kann maximal das Laden der Applikation unterbrochen werden, aber die Page mit dem Bootloader bleibt immer intakt.
> Wenn z.B im FRAM gerade der Bootloader ausgeführt wird und sich > zerstört, dann wars das. Ich hab noch kein FRAM mit QSPI fuer das Systemrom gesehen. :-) Ueblicherweise sind das doch kleiner Dinger wo die Parameter drin liegen. Aber klar, wenn man sich besonders ungeschickt anstellt kann man sich ins Knie schiessen. Vanye
Vanye R. schrieb: > Ich hab noch kein FRAM mit QSPI fuer das Systemrom gesehen. :-) Es gibt µC mit FRAM statt Flash, z.B. den hier: https://www.ti.com/product/MSP430FR2355
Soul E. schrieb: > Hmmm schrieb: >> Soul E. schrieb: >> Cypress gibt z.B. beim FM24C16 10^12 Cycles an, kein Vergleich zu den >> bei Flash üblichen 10^5. Mit Wear Leveling kõnnte man im praktischen >> Einsatz noch mehr rausholen. > > Richtig. Aber die 10^12 beim FRAN sind lesen&schreiben, die 10^5 beim > Flash sind nur Schreibzyklen, lesen darf man Flash beliebig oft. Das > muss einem klar sein. Harald K. schrieb: > Vanye R. schrieb: >> Ich hab noch kein FRAM mit QSPI fuer das Systemrom gesehen. :-) > > Es gibt µC mit FRAM statt Flash, z.B. den hier: > > https://www.ti.com/product/MSP430FR2355 Interessant: TI gibt hier 2^15 Schreibzyklen an. Über Lesezyklen wird nichts gesagt (auf der Übersichtsseite). Und wenn man dann ins Datenblatt schaut findet sich plötzlich folgendes: Read and write endurance = 10^15 cycles.
:
Bearbeitet durch User
Loco M. schrieb: > Und wenn man dann ins Datenblatt schaut findet sich plötzlich folgendes: > Read and write endurance = 10^15 cycles. Wenn man jetzt mal annimmt, dass wir eine Schleife haben, die zu 10^6 Lesezugriffen pro Sekunde auf eine Speicherstelle führt, sind das immer noch 10^9 Sekunden Lebensdauer, also knapp 32 Jahre. Und wenn dann die ersten Bits kippen, ist auch noch ECC dabei.
Angehängte Dateien:
Hmmm schrieb: > Wenn man jetzt mal annimmt, dass wir eine Schleife haben, die zu 10^6 > Lesezugriffen pro Sekunde auf eine Speicherstelle führt, sind das immer > noch 10^9 Sekunden Lebensdauer Bei externen FRAM sieht es nicht so gut aus, weil immer eine ganze "Row" gelesen und refresht wird.
Gibt es eigentlich schon dokumentierte Fälle von Problemen mit FRAM Datenintegrität im uC Bereich? Einige der groesseren MSP430 sind lediglich mit FRAM ausgestattet. Sind die schon irgendwo unangenehm aufgefallen? Der MSP430 wäre dann sozusagen ein Extremfall, weil sich da die FW im FRAM befindet und im Zuge der Code Ausführung andauernd angesprochen wird.
Gerhard O. schrieb: > Gibt es eigentlich schon dokumentierte Fälle von Problemen mit FRAM > Datenintegrität im uC Bereich? https://www.ti.com/lit/an/slaa526a/slaa526a.pdf Das Dokument ist zwar schon etwas angestaubt (2014), aber damals hatte es TI zumindest noch nicht geschafft, ein FRAM kaputtzulesen/-schreiben, siehe 2.3. Bauform B. schrieb: > Bei externen FRAM sieht es nicht so gut aus, weil immer eine ganze "Row" > gelesen und refresht wird. Auch dazu steht zu den MSP430 etwas Interessantes drin: "The number of instructions executed cannot be directly related to the number of FRAM accesses on the MSP430FRxx device. This is because the FRAM controller uses a four-word two-way associative cache to buffer instructions prior to execution. Therefore, instructions are fetched 64 bits at a time and executed from cache memory until a cache miss occurs." Zusammengefasst muss man sich also schon verdammt viel Mühe geben, um genug FRAM-Refreshes zu provozieren, dass das FRAM möglicherweise vor dem Testenden stirbt.
In Datasheet habe ich nicht 10^12 sondern 10^14 oder 10^15 gesehen. Dort gibt es auch Berechnungen, wie lange eine FRAM-Zelle lebt, wenn man sie immer liest/schreibt. FM25W256: 100 trillion (10^14) read/writes, Time to Reach Endurance Limit for Repeating 64-byte Loop: SCK Freq (MHz) -> 10, Endurance Cycles/sec: 18660, Endurance Cycles/year: 5.88 × 10^11, Years to Reach Limit: 170.2 CY15B108QN: 1000 trillion (10^15) read/writes, SCK Freq (MHz) -> 10, Endurance Cycles/sec: 18380, Endurance Cycles/year: 5.79 × 10^11, Years to Reach 1015 Limit: 1727 In dem Gerät wird SCK 8 oder 10 MHz. Ich denke, ich werde immer nur Blocks je 8 Bytes schreiben und lesen. Immer gleiche Zelle werde ich ohne Pause nicht beschreiben, 1727 Jahre, aber auch 170 Jahre lang zu leben habe ich wenig Hoffnung...
:
Bearbeitet durch User
Maxim B. schrieb: > In Datasheet habe ich nicht 10^12 sondern 10^14 oder 10^15 gesehen. Das wurde wohl nach und nach immer weiter nach oben korrigiert. Im Infineon-Datenblatt von 2018 steht 10^14, im Cypress-Datenblatt von 2013 10^12, und im Ramtron-Datenblatt von 2000 steht 10^10. Maxim B. schrieb: > 1727 Jahre, aber auch 170 Jahre lang zu > leben habe ich wenig Hoffnung... Ja, in der Praxis dürfte das unter "hält ewig" fallen.
Meine Frage bezog sich darauf, was passiert, wenn gerade beim internen Refresh nach dem Lesen die VCC ausfällt. Muß man mit einer externe Beschaltung dafür sorgen, daß lange genug Spannung anliegt?
H. H. schrieb: > Cheops wäre anderer Meinung. Noach lebte 950 Jahre. Heute ist Mensch aber kleiner und schwächer geworden. Ich arbeite mit dem Stoff, den ich habe :)
Peter D. schrieb: > Muß man mit einer externe Beschaltung dafür sorgen, daß lange genug > Spannung anliegt? dV=T*I/C Mit 100 ns, 100 mA und 100n bekommen wir dV=0,1 Volt, das sollte nicht so kritisch sein...
Peter D. schrieb: > Bei zerstörendem Lesen hätte ich immer ein ungutes Gefühl. Du darfst dann auch keine NAND-Flashs verwenden. Maxim B. schrieb: > wie lange eine FRAM-Zelle lebt, wenn man sie immer liest/schreibt. Viel spannender ist aber eigentlich, wie lange eine FRAM-Zelle lebt, wenn man zwischendruch mal einen kompletten Aus-Ein-Zyklus einschiebt.
:
Bearbeitet durch Moderator
Ich frage mal anders: wäre FRAM als Speicher für Daten unsicherer als eine SD-Karte? Um etwas zu der Sache zu kommen: ich überlege jetzt über ein MIDI-"Tonbandgerät". Keine besonders anspruchsvolle Aufgabe. Statt üblicher SD-Karte möchte ich FRAM oder MRAM einbauen. Speichern möchte ich in einem internen Format, wo gewöhnliche 0x9n und 0x8n Befehle 8 Bytes verbrauchen.
:
Bearbeitet durch User
Lothar M. schrieb: > Peter D. schrieb: >> Bei zerstörendem Lesen hätte ich immer ein ungutes Gefühl. > Du darfst dann auch keine NAND-Flashs verwenden. Bei NAND-Flash ist das Lesen zerstörend?
Hmmm schrieb: > Maxim B. schrieb: >> In Datasheet habe ich nicht 10^12 sondern 10^14 oder 10^15 gesehen. > > Das wurde wohl nach und nach immer weiter nach oben korrigiert. Im > Infineon-Datenblatt von 2018 steht 10^14, im Cypress-Datenblatt von 2013 > 10^12, und im Ramtron-Datenblatt von 2000 steht 10^10. > > Maxim B. schrieb: >> 1727 Jahre, aber auch 170 Jahre lang zu >> leben habe ich wenig Hoffnung... > > Ja, in der Praxis dürfte das unter "hält ewig" fallen. Nö, wenn der mit vollem Speed läuft und immer wieder in einer Schleife (wie bei vielen Implementierungen üblich) der Speicher gelesen wird, dann ist der schon nach knapp 2 Jahren dahin. https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/132022/fram-endurance
Uwe D. schrieb: > Nö, wenn der mit vollem Speed läuft und immer wieder in einer Schleife > (wie bei vielen Implementierungen üblich) der Speicher gelesen wird, > dann ist der schon nach knapp 2 Jahren dahin. Es ist mir aber schwer, eine Anwendung zu finden, wo eine Zelle ununterbrochen zwei Jahre lang so schnell wie nur möglich gelesen wird. Schon allein weil SPI etwas Zeit für Datenaustausch braucht, würde ich so oft notwendige Byte intern in SRAM halten und nur gelegentlich mit FRAM synchronisieren. Vielleicht sind solch Befürchtungen für FRAM rechtfertigt, wenn FRAM statt parallel SRAM verwendet wird? Das ist aber bei mir nicht der Fall. Ich möchte FRAM/MRAM für langfristigen Speichern von Daten verwenden, die aber möglichst schnell und für Praxis unbeschränkt oft geändert sein sollten. Geschwindigkeit ist von Natur aus wegen MIDI-Eigenschaften sowieso beschränkt. 100x oder auch 1000x von gewöhnlichen FLASH ist mir zu wenig, auch typische Schreibzeiten von FLASH. Aber 100 Bytes pro ms würde mir schon reichen... Eine Viscount-Orgel schickt über MIDI zuerst Registrierungen in 0xf0.....0xf7 Sendungen (zum Unterschied von Life werden die am Ende von X.mid gespeichert). Das sollte schneller geschrieben/gelesen werden als gesendet, pro Byte also schneller als 320 us. Was danach kommt, ist Tastenspiel selbst, und ein Mensch kann von Natur aus sowieso nicht so schnell Orgeltasten drucken... Nun denke ich, daß FRAM und MRAM beide für die Aufgabe gleich gut sind... Da ich kaum mehr als einige Exemplare machen möchte, ist mir Preis fast egal. So denke ich, für Versuchzwecke kann ich billigere FRAM nehmen und für endgütige Variante danach eine Bank aus MRAM. Ja, so viel Aufwand, nur um in Urlaub gehen zu dürfen! :)
:
Bearbeitet durch User
Uwe D. schrieb: > Nö, wenn der mit vollem Speed läuft und immer wieder in einer Schleife > (wie bei vielen Implementierungen üblich) der Speicher gelesen wird, > dann ist der schon nach knapp 2 Jahren dahin. Lies den Thread einfach mal komplett: Beitrag "Re: FRAM oder MRAM?"
Warum ich das überhaupt selbst machen möchte: ein System von einem Ingenieurbüro wird sowieso ab 1500 € und weiter nach oben kosten. Dabei kann ich bei Selbstbau unseren Bedarf besser berücksichtigen. Fertige MIDI-Aufnahmen brauche ich dabei nicht, da ich selber spielen kann.
Angehängte Dateien:
-
IS25LP128F-JBLA3.png
62 KB
Maxim B. schrieb: > Geschwindigkeit ist von Natur aus wegen MIDI-Eigenschaften > sowieso beschränkt. 100x oder auch 1000x von gewöhnlichen FLASH ist mir > zu wenig, auch typische Schreibzeiten von FLASH. Aber 100 Bytes pro ms > würde mir schon reichen... > pro Byte also schneller als 320 us. Was ist gewöhnliches Flash? Die gewöhnlichen IS25LP sind dafür schnell genug, siehe Bild. Der Nachteil gegenüber FRAM: die müssen vorher gelöscht werden und das dauert schon mal eine halbe Sekunde. Das Programm muss also immer für genügend freie Sektoren sorgen. Das sollte kein Problem sein, wenn man zwei Chips spendiert. Zum Trost gibt es viel mehr Megabytes pro SO-8. Edit: und es gibt mehr als einen Hersteller.
:
Bearbeitet durch User
Hmmm schrieb: > Uwe D. schrieb: >> Nö, wenn der mit vollem Speed läuft und immer wieder in einer Schleife >> (wie bei vielen Implementierungen üblich) der Speicher gelesen wird, >> dann ist der schon nach knapp 2 Jahren dahin. > > Lies den Thread einfach mal komplett: > > Beitrag "Re: FRAM oder MRAM?" Den Link aus dem TI Forum hatte ich beigefügt, weil der Mensch von TI bestätigt hat, das man den MSP430 „totlesen“ kann. Er schrieb aber auch, Zitat: /„ However, not all FRAM technologies are destructive on read. 1T1C or 2T2C cells are, 1T cells aren't. 1T cells use a field effect transistor where the gate insulation was replaced by a ferroelectical material. It is programmed by a gate-source voltage and keeps its state when you read it by applying a source-drain voltage.“/
Maxim B. schrieb: > Uwe D. schrieb: >> Nö, wenn der mit vollem Speed läuft und immer wieder in einer Schleife >> (wie bei vielen Implementierungen üblich) der Speicher gelesen wird, >> dann ist der schon nach knapp 2 Jahren dahin. > > Es ist mir aber schwer, eine Anwendung zu finden, wo eine Zelle > ununterbrochen zwei Jahre lang so schnell wie nur möglich gelesen wird. > Schon allein weil SPI etwas Zeit für Datenaustausch braucht, würde ich > so oft notwendige Byte intern in SRAM halten und nur gelegentlich mit > FRAM synchronisieren. Da hast Du natürlich recht. Meine Anmerkungen bezogen sich auf den MSP43O mit FRAM im Chip. Und FRAM ist auch beim Lesen destruktiv, jedenfalls bei den meisten Produkten am Markt.
Uwe D. schrieb: > Den Link aus dem TI Forum hatte ich beigefügt, weil der Mensch von TI > bestätigt hat, das man den MSP430 „totlesen“ kann. Ja, in einem gezielt konstruierten Szenario, das Cache Misses provoziert, bekommt man sehr viele Lesezugriffe hin. In der Praxis macht der Code aber etwas mehr, so dass viel vom Cache abgefangen wird und auch die Cache Misses sich verteilen. Und selbst dann sind die 10^15 Zugriffe noch ein theoretischer Wert, weil es in der Praxis offenbar noch nicht geschafft wurde, FRAM wirklich kaputtzulesen.
Moin, Ich habe daheim eine MSP430 FRAM Version schon jahrelang in Betrieb und übe beim Abschalten keinerlei Vorsichtsmaßnahmen und gehe damit wie mit jeden anderen uC um. Bis jetzt ist noch nichts passiert. Ich weiß nicht ob man hier wirklich zu viel Angst zu haben braucht. Speziell für den Amateurbetrieb, wo man sich darum selber kümmern kann. Ich glaube, der Maxim sollte sich da keine grauen Haare wachsen lassen. Ansonsten bin ich der Meinung, daß T.I. nicht ein solches Produkt auf den Markt werfen würde, wenn es derart fehleranfällig wäre. Ich denke man sollte diese Dinge im richtigen Maß sehen. Wenn da die vorgeschriebenen elektrischen Bedingungen wie ausreichende Stützkondensatoren, Brownout Detektor eingeschaltet, erfüllt sind, ist die Wahrscheinlichkeit einer FRAM Korruption höchstwahrscheinlich astronomisch klein. Diesbezügliche vorhandene Errata und Ratschläge könnte man vorsichtshalber auch noch konsultieren bzw. annehmen. Gerhard
:
Bearbeitet durch User
Der genannte use case des TO war nicht Programmspeicher in einem Mikrocontroller, sondern externer Datenspeicher für eine Orgel. Selbst wenn man da zweimal täglich den kompletten Katalog einliest, sollten die 10^15 Zyklen mehr als reichlich bemessen sein. Sehr wichtige und häufig gelesene Daten (das Inhaltsverzeichnis) kann man ja zusätzlich mehrfach ablegen und mit einer Prüfsumme sichern. Das sollte man bei EEPROM oder FlashEE-Emulation auch machen.
Bauform B. schrieb: > Die gewöhnlichen IS25LP sind dafür schnell > genug, siehe Bild. Der Nachteil gegenüber FRAM: die müssen vorher > gelöscht werden und das dauert schon mal eine halbe Sekunde. Das > Programm muss also immer für genügend freie Sektoren sorgen. Ich möchte alles möglichst einfach haben. Will Mikrocontroller was schreiben, dann schreibt es das einfach so und gut... So etwa wie bei 23LCV1024 Auch will ich kein FAT u.Ä., einfach alles zusammen halten, am Anfang von Stück wird Blockadresse (da alles ja mit 8-Bytes-Blocks) von dem nächsten notiert. Wird etwas gelöscht, dann verschiebt sich alles, was danach steht, um Gelöschtes zurück. Hier ist das Löschen von Blocks und Sectoren schon etwas störend...
:
Bearbeitet durch User
Maxim B. schrieb: > Bauform B. schrieb: >> Die gewöhnlichen IS25LP sind dafür schnell >> genug, siehe Bild. Der Nachteil gegenüber FRAM: die müssen vorher >> gelöscht werden und das dauert schon mal eine halbe Sekunde. Das >> Programm muss also immer für genügend freie Sektoren sorgen. > > Ich möchte alles möglichst einfach haben. Will Mikrocontroller was > schreiben, dann schreibt es das einfach so und gut... So etwa wie bei > 23LCV1024 > > Auch will ich kein FAT u.Ä., einfach alles zusammen halten, am Anfang Wie bekommst Du die Daten vom PC/Netzwerk, seriell? Zumindest brauchst Du ja ein bissel Organisation des Speichers…
Uwe D. schrieb: > Wie bekommst Du die Daten vom PC/Netzwerk, seriell? Zumindest brauchst > Du ja ein bissel Organisation des Speichers… Ich denke, vielleicht werde ich Reservekopien über SD-Karte machen. Die Dateien einfach als *.txt. Aber das ist nicht besonders wichtig für das Gerät. Erste Version bestimmt ohne dieser Möglichkeit. Als Anzeige möchte ich TFT-Modul auf ILI9341 nehmen, gewöhnlich gibt es dort auch SD-Karten-Steckdose. Die könnte benutzt werden. *.mid - Dateien sind zwar für diesen Zweck gedacht. Aber die Datei bleibt sowieso Orgelgebunden, da Kanäle und Registrierungen (die über 0xf0...0xf7 übertragen werden) von Instrument zu Instrument anders sind. So ist Speichern von Dateien auf dem Computer nur für Reservekopien sinnvoll.
:
Bearbeitet durch User
Maxim B. schrieb: > Ich denke, vielleicht werde ich Reservekopien über SD-Kard machen. Falls Du das später verkaufen willst, denk an die Patent-Problematik bei SD-Cards.
Hmmm schrieb: > Maxim B. schrieb: >> Ich denke, vielleicht werde ich Reservekopien über SD-Kard machen. > > Falls Du das später verkaufen willst, denk an die Patent-Problematik bei > SD-Cards. Verkaufen werde ich das in keinem Fall. Höchstens einige für Freunden oder Kollege schenken. Aber auch das nur bedingt: 1. die meisten Orgeln haben doch Pfeifen und eine mechanische oder pneumatische Traktur, die kann man mit so einem Gerät sowieso nicht bedienen. 2. manche Kollegen haben Vorurteile gegen elektronischen Orgeln. Ich selbst denke so: wenn ich zwischen einer guten Schleiflade und einer guten Elektronik wählen sollte, dann wähle ich eine Schleiflade. Wenn ich aber zwischen einer schlecht funktionierenden Pneumatik und einer guten Elektronik wählen sollte, dann lieber Elektronik. Elektronik rettet auch bei Kammermusik, wenn akustische Orgel wie oft höher gestimmt wird.
:
Bearbeitet durch User
Maxim B. schrieb: > Uwe D. schrieb: >> Wie bekommst Du die Daten vom PC/Netzwerk, seriell? Zumindest brauchst >> Du ja ein bissel Organisation des Speichers… > > Ich denke, vielleicht werde ich Reservekopien über SD-Karte machen. Die > Dateien einfach als *.txt. Aber das ist nicht besonders wichtig für das > Gerät. Erste Version bestimmt ohne dieser Möglichkeit. > Als Anzeige möchte ich TFT-Modul auf ILI9341 nehmen, gewöhnlich gibt es > dort auch SD-Karten-Steckdose. Die könnte benutzt werden. Du könntest eine einfache serielle Schnittstelle einbauen (USB) und den Datentransfer mit dem X- oder Y-Protokoll erledigen, da brauchst Du Dich nicht mit Dateisystemen im beschränkten MC herumschlagen und kannst nach Deinem Gusto die Dateien im FRAM ablegen.
Beitrag #7610409 wurde vom Autor gelöscht.
Uwe D. schrieb: > Du könntest eine einfache serielle Schnittstelle einbauen (USB) Auch möglich, einfach über zweite USART und UART/USB über ein Terminal die Daten als txt in Computer zu speichern... Ich denke, diese Frage ist nicht von so großer Bedeutung. Ich weiß nicht, warum heute wollen so viele alles über Computer und Internet machen... Ich denke, ohne ist oft viel besser :) Zu meinem Ziel gehört es ja nicht die Musterbeispiele in *.mid zu produzieren und zu verkaufen. Deshalb ist Nachbessern mit Computer überflüssig, es reicht einfach mehr oder weniger sauber zu spielen. Ich überlege übrigens mit dem zweiten USART HC-12 Modul zu bedienen. Mit dem Quarz 8 oder 16 MHz kann ich 31250 bod MIDI fehlerfrei und 38400 bod für HC12 mit -0,16% haben. Oder mit dem Quarz 14745,6 kHz 38400 bod fehlerfrei und 31250 bod mit +0,03% genau. In der ods-Tabelle bedeutet Kdel=0,5 2x Einstellung für USART. Aber auch das ist nicht so wichtig zuerst... Im Moment arbeite ich mit einem MIDI-Ableser, um genau zu wissen, was und wann von der Orgel wirklich über MIDI geschickt wird. Z.B. ein Pfarrer unten: der will "ein bißchen schneller" oder "ein bißchen leiser" haben. Oder "ein bißchen sanfter Register". Ich muß genau wissen, was ich dafür per MIDI genau für diese Orgel schicken sollte. Ein paar typischen Registrierungen statt die bei der Aufnahme fixiert wurden. Oder auch nicht... Auch noch notwendig zu entscheiden: wird ATMega mit 3,3 Volt und somit 8 MHz betrieben oder doch 16 MHz und 5 Volt. Letztere braucht zusätzliche IC für Pegelwandler, ermöglicht aber schnellere Arbeit, was für TFT wichtig wäre...
:
Bearbeitet durch User
Maxim B. schrieb: > Ich denke, ohne ist oft viel besser :) Für den Lerneffekt sicher. Aber das, was Du vorhast, klingt nach einem MIDI-Sequencer, das würde man heutzutage wohl eher mit einem Smartphone mit MIDI-Interface lösen, da hast Du dann nicht nur quasi endlos Speicher, sondern auch einen fertigen Touchscreen. Maxim B. schrieb: > 31250 bod Herr Baudot rotiert gerade in seinem Grab.
Hmmm schrieb: > Herr Baudot rotiert gerade in seinem Grab. Macht nichts, ich habe gewöhnt. Beerdigungen zu spielen gehört bei mir zu Alltag :) MIDI-Sequencer, die ich als Programm gesehen habe, die können alle sehr gut die Files verändern (was ich gar nicht brauche), aber als Player sind die unbequem. Außerdem bearbeiten die MIDI im Sinn Tasten drucken und besondere Befehle wie 0xf0...0xf7 verstehen die nicht besser als WinHEX. Ich kann mir es schwer vorstellen, wie ein Pfarrer in Gottesdienst HEX liest, wenn er etwas leiser braucht :) Ich brauche etwas, was Kommunikation auf Niveau Taste - Register möglich macht. Ohne über MIDI-Kanal oder über Systemcode zu denken. Ein Beispiel: EG324. Vorspiel (immer nur einmal), SatzA, SatzB. Auf dem Bildschirm: EG324. Zweite Säule: Wiederholungen. Z.B. 3 (dann die Folge: Vorspiel - SatzA - SatzB - SatzA - Schluß). Dritte Säule: Transponieren, HT (von der Variante in EG). 4 Säule: Registrierung: Ur-Registrierung, Variante A, Variante B, Variante C, Variante D... Oben rechts in % noch eine Anzeige von Geschwindigkeit, die immer schnell per einen Schieber (Poti) geändert sein kann, um an Gemeindegesang zu passen. Mehr braucht ein Nichtmusiker nicht, alles Andere wird nur stören... Außer voller Liste von Werken die Listen, um ein paar GD oder Andachten zusammen zu setzen. Dort werden die notwendigen Wiederholungen, Transposition und Registrierung angegeben. Bei der Aufnahme werden Vorspiel und alle Sätze separat aufgenommen. Ich glaube, ein B-Musiker kann nach ein paar Versuchen einmal fehlerfrei spielen, um ohne Edition zurecht zu kommen? :) So sehe ich das jetzt :)
:
Bearbeitet durch User
Hmmm schrieb: > Herr Baudot rotiert gerade in seinem Grab. Damit Herr Baudot besser schläft... Wahrscheinlich doch 5 Volt-Variante: mit 5 Volt arbeitet auch MIDI-Schnittstelle besser als mit 3,3 Volt, deshalb sowieso 5 Volt wünschenswert. Und wie bei Amateuren üblich: wenn zusätzliche IC Eigenschaften von Schaltung verbessern kann, dann einfach machen, nicht überlegen...
:
Bearbeitet durch User
Maxim B. schrieb: > Macht nichts, ich habe gewöhnt. Beerdigungen zu spielen gehört bei mir > zu Alltag :) Interessant, es geht also um die ganz grossen Orgeln. Maxim B. schrieb: > MIDI-Sequencer, die ich als Programm gesehen habe, die können alle sehr > gut die Files verändern (was ich gar nicht brauche), aber als Player > sind die unbequem. Ich meinte, dass Du ebenfalls ein Smartphone verwenden könntest, dann brauchst Du nur ein MIDI-Interface und kannst den Rest per Software machen. Das macht es aus der Hardware-Perspektive weniger spannend (selbst das MIDI-Interface gibt es fertig zu kaufen), aber dafür wird der Kreis der potentiellen Nutzer deutlich grösser. Maxim B. schrieb: > Wahrscheinlich doch 5 Volt-Variante: mit 5 Volt arbeitet auch > MIDI-Schnittstelle besser als mit 3,3 Volt, deshalb sowieso 5 Volt > wünschenswert. Denk auch von vornherein an das Thema Gehäuse. Die Elektronik an ein Standardgehäuse anzupassen, ist bei kleinen Stückzahlen deutlich günstiger als der umgekehrte Weg.
Angehängte Dateien:
-
Ind2023_.jpg
75 KB -
Mi_.jpg
72 KB -
PL02_k.jpg
110 KB
Hmmm schrieb: > Ich meinte, dass Du ebenfalls ein Smartphone verwenden könntest, dann > brauchst Du nur ein MIDI-Interface und kannst den Rest per Software > machen. Leider kann ich nicht alles erlernen. Wenn AVR ich recht oder schlecht schon programmieren kann, dann noch mit etwas Anderem beginnen... Irgendwann muß ich noch Orgel spielen :) > Interessant, es geht also um die ganz grossen Orgeln. Nicht immer. Es gibt auch kleine Orgeln mit nur einem Manual und Pedal und nur 8 Register. Es gibt Friedhofkapellen ohne Instrument oder gar ohne Strom... In vielem ist das Leben in Land besser als in einer Großstadt. Aber... > Denk auch von vornherein an das Thema Gehäuse. Ich denke. Prototyp möchte ich einfach auf einer Platine machen. Wenn alles mehr oder weniger läuft, mache ich eine Variante in Gehäuse. So etwa sieht die Platine aus, um MIDI zu lesen. Dazu gehört noch eine kleine Platine mit Optokoppler und Buchsen. HEX-Drehschalter wählt auch ein von beiden Quarze, für 16 MHz und für 14,7456 MHz.
:
Bearbeitet durch User
Hmmm schrieb: > Falls Du das später verkaufen willst, denk an die Patent-Problematik bei > SD-Cards. Worin soll die bestehen?
Thorsten S. schrieb: > Hmmm schrieb: >> Falls Du das später verkaufen willst, denk an die Patent-Problematik bei >> SD-Cards. > > Worin soll die bestehen? https://www.sdcard.org/developers/use-and-licensing/ Je nachdem, wen man fragt, soll die Ansteuerung per SPI davon nicht betroffen sein: https://en.wikipedia.org/wiki/SD_card#Openness_of_specification
> Je nachdem, wen man fragt, soll die Ansteuerung per SPI davon nicht > betroffen sein: Es gibt auch noch eMMC! Aber angesichts des vermuteten Nutzungsprofils ist es vollkommen birnig sich Gedanken um die Haltbarkeit eines Frams zu machen, kaufen, nutzen und gluecklich sein. Und die Bedenkentraeger unter uns koennen ja auch einfach SRAM nutzen und das nur beim abschalten speichern. Vanye
Ich glaube, eine SD-Karte ist die einfachste Möglichkeit, eine Datei zwischen Gerät und Computer auszutauschen, ohne Risiko Computer kaputt zu machen.. Verkauf ist nicht geplant. Ich verdiene mein Geld anders: ich spiele :) P.S. vielleicht sollte ich mal XMega ausprobieren? 32 MHz mir 3V3, sowieso brauchen MRAM und TFT 3V3 auch. Und MIDI-Buchsen von einem 3V3/5V Wandler speisen? Z.B. ATXMEGA256A3U-AU
:
Bearbeitet durch User
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.