RAM an Mikroprozessor

Doch, der Schmorhaken :-)

Saludos Wolfgang

Die c't hatte mal versucht, eine SD-Karte kaputtzuschreiben, den Versuch dann aber nach 16 Millionen Schreibzugriffen auf denselben Sektor abgebrochen, weil keine Verschlechterung zu erkennen war.

Gruß Henning

Henning Paul :

Ja genau, die waren dass. Naja, auf nur _einen_ Sektor zu schreiben ist natürlich recht sinnlos - wenn das Defektmanagemanagement intern einfach einen der andren 2 Millionen Sektoren verwendet, dann wurde die Karte ja insgesamt nur 8 mal beschrieben - das schafft selbst billigste Chinaware.

M.

Sven Schulz schrieb:

Hallo,

Bankswitching sollte man sich heutzutage nicht mehr antun wenn es sich irgendwie vermeiden lässt. Gleichzeitig schnell adressierbar und wenige Pins zum Anschluß ist ein Widerspruch in sich.

Bye

Die anderen Sektoren aber aber _schon_ belegt und 100% Reservesektoren wird so eine Karte auch nicht haben. In der aktuellen c't ist mal wieder ein Artikel über diese Problematik drin. Theoretisch kann eine Karte Sektoren, die i.d.R. nur gelesen werden auch in "abgenutzte" Sektoren mappen, wenn sie intern eine Statistik über Lese- und Schreibzugriffe führt.

Am Ende ist ja auch nur interessant, was man von außen sieht. Und ein Szenario, bei dem auf den Großteil der Sektoren nur lesend und ein paar wenige (die FAT z.B.) schreibend und das auch noch sehr häufig zugegriffen wird, ist relativ wahrscheinlich.

Gruß Henning

Um da auf 640kByte (ich denke es waren 640KiByte gemeint) zu kommen braeuchte man schon mindestens 10 solcher Chips. Und die verwenden nichtfluechtiges FRAM. Sowas scheint es zwar auch als SRAM zu geben (z.B. ueber Endrich):

Micha

Ist aber eigentlich ganz simpel. Zumindest am 8031 oder AVR sollte das kein Problem sein. Statisches RAM mit 640K aufbauen, zu überschüssigen Adressleitungen direkt an Portleitungen des Prozessors. Bei 1MBit Adressraum benötigt man dann 4 Bit über die man die Bänke á 64KByte umschaltet. Anschluss ansonsten so wie es im Datenblatt steht.

In der Software macht man dann jweils ein Makro oder eine Function zum Lesen bzw. Schreiben aus einem 1MB Adressraum. Da würde ich keine große Fehlerquelle sehen.

Benötigt werden dann 20 Adressleitungen und 8 Datenleitungen, sowie RD* und WR*, also 30 Leitungen + Stromversorgung zum RAM, eventuell nur 22 wenn man den DEMUX auf die Speicherkarte setzt.

Ist natürlich aufwendiger als eine Lösung mit nem seriellen RAM, aber wesentlich schneller.

Gruß

Sftefa DF9BI

Hallo Sven,

Der Markt wartet auf Leute wie Dich. Realisier das Teil und werde reich. Ein Problem siehst Du dabei offensichtlich nicht. Andere schon, aber das war schon immer ein unnötiges Innovationshemmnis.

Sven Schulz schrieb:

Das mit dem seriellen RAM sollte ja nach den zahlreichen Antworten jetzt wohl gestorben sein. Eine Alternative zu ARM könnte vielleicht ein M16c, M32c oder gar R32c Derivat sein, die haben ein SRAM Interface (können aber auch ohne arbeiten), einige haben auch ein DRAM interface. R32c gibts mit 176kB RAM und 1M Flash on Board. Adressraum kannste je nach Typ zwischen 1MB 16MB oder 4GB wählen. Schau halt mal bei Renesas, vielleicht ist auch was bei den H8- oder SH-Typen dabei.

Jörg.

Hallo Sven,

:-)

Was macht man eigentlich, wenn man z.B. mit einem Traktor an einem Formel-1 Rennen teilnehmen will

Um die Strassenlage zu verbessern würden sich breite Slicks anbieten, müssten aber auf die Standardfelgen passen.

und nach Möglichkeit auch selber fahren (wäre ja doch ein bischen gefährlich, nicht ;-)

Irgendwie erinnert mich die Geschichte an die Story mit dem Hammer, wo dann alles irgendwie nach Nägeln aussieht.

Marte

a) unterstützen die von dir genannten Controller (und die zugehörigen Compiler) keine geeigneten Datentypen für entsprechend breite Adressen, du musst also die gesamte Pointerarithmetik "zu Fuss" machen.

b) ist ein Bankswitching bei jedem (Byte-)zugriff extrem lahm. Man wird also versucht sein, dies etwas höher im Programm zu machen, mit entsprechenden Folgen, falls man sich irgendwo mal vertut.

c) scheitert dein Ansatz, sobald Interrupts ins Spiel kommen.

"nur" ist gut. ;)

Für einen 8051 mag ich das bezweifeln. Allein schon die Zeit, bis du mit dem Teil eine 20Bit-Adresse zusammengefummelt hast... in der Zeit hat ein Hardware-SPI die Adresse auch rausgeschoben.

Hergen

Marte Schwarz schrieb:

Hallo,

wenn alle Adressierungsarten vollständig unterstützt werden sollen, dann muß der µC für mehr als 64 K auch eine Arithmetik der nötigen Breite haben, für 1 MB z.B. 20 Bit.

Bye

Wieso das? GCC unterstützt 32 Bit Integer. Das sollte als Adresspointer ausreichen. Im übrigen hängt das vom konkreten Problem des OP ab, ob das geht, oder nicht.

Das ist exakt ein Assembler Befehl, sowohl beim 8031 als auch beim AVR.

Solange ich in den INT-Routinen nicht auf den externen Speicher zugreife (oder wenn ich das ausschließlich in einer INT-Routine mache), ist das überhaupt kein Problem. Selbst wenn der INT zwischen dem Bankswitching und dem Speicherzugriff passiert. Ansonsten muss man eben in der Hauptroutine die INTs kurzzeitig unterdrücken.

Dasselbe "Problemchen" hat man übrigens auch bei einer Lösung mit seriellem RAM.

Auch mit SPI musst du die Adresse, bzw. die Pageadresse irgendwo hinschreiben. Und ob ich die auf einen Port oder in ein SFR schreibe ist wurscht.

Gruß

Stefan DF9BI

Naja so schlimm ist das auch nicht. Innerhalb einer Page geht der Zugriff sehr schnell. Man muß halt zusätzlich Kompromisse eingehen was jemand der mit einem 8 Bitter 640K braucht sicher tun wird.

Man muß nur das Pageregister am Anfang sichern und am Ende rücksichern. Das ist genau ein Port-read mit anschließendem push. Am Ende dann pop und Port-write.

Da der 8051 standardmässig mit Addresslatch arbeitet braucht man 20 IOpins.

Rechne intern mit einer 24-bit addresse. Die ist schon "fertig". ausserdem dauert es z.b. bei einem AVR mit 16 MHZ auch mindestens 6 us also

Sven Schulzschrieb: "

Bankswitching

Da sind leider einige Widersprüche drin. RAM seriell zu verwenden ist eher speziell und kaum in Anwendung. Der Controller wurde nicht dafür entwickelt, weil dass viel zu langsam wird. Für sowas müstest Du selbst Routinen in Software entwickeln und das würde noch langsamer. Einzig per DMA ganze Speicherblöcke von der SPI in den internen RAM kopieren und damit arbeiten würde in Bezug auf Geschwindigkeit noch Sinn machen. Du würdest also Deine Daten z.B. von einer Flashcard in den RAM kopiern, die Daten dann bearbeiten und die Ergebnisse per DMA wieder auf die Card schreiben. Damit bist Du bei Deinen Daten aber auch auf die Größe des internen RAM festgelegt. Ein M32 hat z.B. 48K RAM und die könnte man in ca. 12ms übertragen.

Wenn es denn parallel sein soll, dann muss man sich Bankswitching heute aber auch nicht mehr antun. Es gibt Controller wie den M16C, die linear 1MB adressieren.

Um welche Stückzahlen geht es denn?

mfG Dirk

"Dirk Ruth" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

Bankswitching

Ich dachte an ein Stück, zum basteln. Macht das einen Unterschied ob nun ein Stück oder eine Million Stück?

Sven

"Marte Schwarz" schrieb im Newsbeitrag news:fdqcgv$qev$ snipped-for-privacy@news2.rz.uni-karlsruhe.de...

alles irgendwie nach Nägeln aussieht.

Wie geht die Geschichte?

sven

"Uwe Hercksen" schrieb im Newsbeitrag news: snipped-for-privacy@mid.dfncis.de...

irgendwie vermeiden lässt. Gleichzeitig schnell

Sehe ich nicht so, das mit dem Widerspruch. Nur weil bestimmte Dinge nicht im Katalog bestellbar snd, heißt es noch nicht das die Aufgaben unlösbar sind.

Sven

Das nicht. Aber es ist ja wohl logisch dass eine serielle Speicheranbindung *immer* langsamer ist als eine parallele. Ob du die gleiche Menge Wasser nun durch zwei Rohre oder durch 20 Rohre quetschst macht ja zeitlich einen ziemlichen Unterschied...