Ich habe ein Programm zur ansteuerung von einem SRAM-Chip
geschrieben(Anhang) und möchte gerne eure Meinung und
Verbesserungsvorschläge dazu.
# Technische Daten
BOARD: ARDUINO MEGA 2650
CHIP: ATmega2650
SRAM: CY 62256 NLL-70P
Datenblatt SRAM:
http://ecee.colorado.edu/~mcclurel/Cypress_SRAM_CY62256.pdf
# Portbelegung
- PortC = A0 - A7 (PC0-PC7)
- PortL = A8 - A14 (PL0-PL6)
- PortD = ¬CE (PD0), ¬OE (PD1), ¬WE (PD2)
- PortB = I/O0 - I/O7
# Read Funktion
Die "NOP"s sind da um die ladezeit vom SRAM(70ns)abzuwarten.
Bei 16MHz => T=62,5ns muss ich min. 2 Tackte warten.
1
byteSramRead(unsignedintaddr){
2
PORTC=lowByte(addr);
3
PORTL=highByte(addr);
4
DDRB=0x00;//I/O Register soll ausgelesen werden
5
6
PORTD=0b00000100;// CE und OE werden auf LOW gesetzt. Siehe Datenblatt
Selbst kleine STM32 haben mehr integriertes SRAM... Mach aus dem "asm"
mal ein "asm volatile" damit das nicht wegoptimiert wird.
Warum ist die Adresse ein vorzeichenbehafteter Integer? Gibt es negative
Adressen?
Joschka A. schrieb:> Ich habe ein Programm zur Ansteuerung von einem SRAM-Chip> geschrieben
Und was ist daran jetzt besser als die Nutzung des beim ATMega2560
vorhandenen externen Memory-Interfaces?
Thomas
Beim benannten Board sind sämtlich Pins, die für das externe
Speicherinterface benötigt werden, auf Digital<n> Leitungen rausgeführt.
Also nur anschliessen, einschalten in einer der Init-Sections und
Compiler/Linker per Section-Attribut/Linkerscript dazu bekommen, daß die
gewünschten Daten dort absegelt werden.
Thomas P. schrieb:> Und was ist daran jetzt besser als die Nutzung des beim ATMega2560> vorhandenen externen Memory-Interfaces?
Bei der Definition von Atmel braucht es ein externes Latch zum
Zwischenspreichern der (niederwertigen) Adresse.
Das kann man sich eben sparen wenn man genug Portleitungen
frei hat. Viel langsamer wird es auch nicht sein da man sich
so das Addressmultiplexen spart (was ja auch Takte kostet).
Hallo,
das Latch macht den Kohl auch nicht fett und die übliche Nutzung der
Ram-Zugriffe ist für mich lesbarer.
Spätestens in C will ich den Ram auch dem Compiler/Linker bekanntmachen,
sonst kann ich ihn nicht ohne größeres Nachdenken nutzen.
Zu Fuß habe ich das nur mit einem Mega16 mal gemacht, aber da, um die
ROMs eines DDR-Schachcomputers auszulesen.
Gruß aus Berlin
Michael
Joschka A. schrieb:> Ich habe ein Programm zur ansteuerung von einem SRAM-Chip> geschrieben(Anhang) und möchte gerne eure Meinung und> Verbesserungsvorschläge dazu.
Für mich ist Verwendung von so einem Chip fragwürdig. Es gibt externe
SRAM mit SPI-Interface. Das ist viel praktischer, auch wenn man genug
freie Ports hat: die Platte wird deutlich einfacher zu machen.
Michael U. schrieb:> und die übliche Nutzung der> Ram-Zugriffe ist für mich lesbarer.
Und was für dich gilt, gilt auch für den TO, nicht wahr?
Michael U. schrieb:> Spätestens in C will ich den Ram auch dem Compiler/Linker bekanntmachen,> sonst kann ich ihn nicht ohne größeres Nachdenken nutzen.
Und genau das was du willst, will auch der TO, nicht wahr?
Michael U. schrieb:> das Latch macht den Kohl auch nicht fett
Und wenn er das nicht will / nicht kann?
Beo Bachta schrieb:> Bei der Definition von Atmel braucht es ein externes Latch zum> Zwischenspreichern der (niederwertigen) Adresse.
Ist ein Argument, aber ob man nun ein Latch einsetzt oder 8 zusätzliche
Leitungen routet/verdrahtet, ist wohl annähernd auswandsneutral.
> Das kann man sich eben sparen wenn man genug Portleitungen> frei hat. Viel langsamer wird es auch nicht sein da man sich> so das Addressmultiplexen spart (was ja auch Takte kostet).
Gut, wenn man mit Ports nur so um sich schmeißen kann, mag das eine
Lösung sein. Beim Anschluss mit Latch benötigt ein Zugriff 2 Takte (ohne
Waitstate) und das sieht beim geposteten Code deutlich aufwendiger aus.
Und das ist für mich schon viel langsamer.
Thomas
Das Nucleo-F401RE Board für 12€ hat ähnlich viele Pins wie der Arduino
Mega, dafür aber 96 KB SRAM intern im Controller - mehr als doppelt so
viel wie der Arduino Mega + SRAM IC. Würde das die Sache nicht stark
vereinfachen?
Joschka stellt eine Frage, sein einziger Post hier,
und der Beobachter beobachtet was daraus wird und kommentiert schon mal
in seinem Namen. Troll-Alarm.
Hallo,
Beo Bachta schrieb:> Carl D. schrieb:>> Troll-Alarm.>> Man kann es auch übertreiben.>> Die Admins wissen dass es nicht so ist wie du es meinst zu wissen.
Du nimmst Dir im Post
Autor: Beo Bachta (Gast)
Datum: 31.05.2018 19:28
das Recht heraus, im Namen des TO zu urteilen. Ich meine, das sollte der
TO selber machen.
Gruß aus Berlin
Michael
Beo Bachta schrieb:> Und wenn er das nicht will / nicht kann?
Was soll der Sarkasmus?
Er hat Verbesserungsvorschläge erbeten und das ist eben die Nutzung
des Memoryinterfaces.
Ein Zugriff dauert dann nur 3 Zyklen inclusive Autoincrement.
Wenn das keine Verbesserung ist, dann weiß ich auch nicht.
S. R. schrieb:> Maxim B. schrieb:>> Es gibt externe SRAM mit SPI-Interface.>> Die sind aber langsamer.
Nicht viel langsamer.
Z.B. mit 23LCV1024 kann man Autoinkrement benutzen und blockweise
schreiben und lesen. SPI schafft es, Byte in 18 Takten zu übertragen.
Aus dem Programmtext von TO sieht man, daß dort die NOP-Verzögerungen
vorgesegen sind. Vielleicht wird es mit SPI-SRAM sogar schneller...
Für wenige Daten, die schnellere Zugriffszeit brauchen, gibt es interne
SRAM. MEGA2560 hat 8 K SRAM.
Dafür kann man 23LCV1024 mit Li-Batterie als schnelle EEPROM betrachten.
Außer Batterie braucht man dann nichts, da ganze Logik schon integriert
ist.
Maxim B. schrieb:>>> Es gibt externe SRAM mit SPI-Interface.>> Die sind aber langsamer.> Nicht viel langsamer.
Naja, SPI taktet bitweise mit maximal dem halben CPU-Takt.
Mit einem Latch bekommst du byteweise und vollen CPU-Takt.
> SPI schafft es, Byte in 18 Takten zu übertragen.
Mit einem zusätzlichen Waitstate (langsamer RAM) sind es nur 3 Takte und
das NOP fällt auch weg.
@Maxim B. (max182)
>>> Es gibt externe SRAM mit SPI-Interface.>>> Die sind aber langsamer.>Nicht viel langsamer.
EHEBLICH langsamer! Aber unser neunmalkluger Maxim weiß es ja besser!
>Z.B. mit 23LCV1024 kann man Autoinkrement benutzen und blockweise>schreiben und lesen. SPI schafft es, Byte in 18 Takten zu übertragen.
Tja, ein externer SRAM schafft das in 3-4 CPU-Takten. UNd vor allen
transparent! Interner wie externer SRAM-Zugriff sieht für den Compiler
und damit Programmier identisch aus. Einfach und fertig. Selbst in ASM!
Ein Zugriff auf einen externen, seriellen RAM muss man IMMER manuell
über Funktionsaufrufe organisieren. Und diese Funktion braucht mehr als
nur die 18 SPI-Takte, auch noch ein paar Befehle fürs Speichern der
Daten, Schleifenkonstrukt etc. Da ist man für EINZELzugriffe mal ganz
fix bei 30-40 Takten und mehr. Also locker Faktor ZEHN langsamer!
>Für wenige Daten, die schnellere Zugriffszeit brauchen, gibt es interne>SRAM. MEGA2560 hat 8 K SRAM.
[ ] Du kennst alle Anwendungen der AVR-Welt.
S. R. schrieb:> Naja, SPI taktet bitweise mit maximal dem halben CPU-Takt.> Mit einem Latch bekommst du byteweise und vollen CPU-Takt.
1. bei "nativen" Ext-RAM-Interface braucht man NOP für Verzögerungen.
2. einige hier wollen gar ohne Latch, das bedeutet alles im Programm
machen: ein paar CPU-Takte für untere Hälfte von Adresse, dann noch so
viel für obere Hälfte, dann in DATA-Port noch Byte schreiben, danach WR
mit NOP-Verzögerung (oder DATA-Port für Eingang umschalten, RD mit
NOP-Verzögerung).
SPI-RAM: Einmal!!! Adresse schicken und danach x kbytes von Daten lesen
oder schreiben.
Ich nehme an, die Zugangsgeschwindigkeit wird vergleichbar, aber
SPI-Variante hat viel kleinere und auch einfachere Platte.
Versucht mal selber eine Platte zu ätzen, wo so viele Leitungen für
Parallel-SRAM notwendig sind! Das ist natürlich möglich, aber wozu solch
Masochismus? Es geht viel viel einfacher.
Wenn statt 4-5 (oder auch 12-16) Takte pro Byte 18 gebraucht werden,
wird das in dem realen Programm kaum zu merken, es sei denn, Programm
macht nichts anderes nur schreibt und liest in/aus Ext-SRAM, sonst gar
nichts macht..
@Maxim B. (max182)
>SPI-RAM: Einmal!!! Adresse schicken und danach x kbytes von Daten lesen>oder schreiben.
Nennt sich Blockzugriff bzw. neudeutsch Burst access und ist der Trick
aller SD-RAMs. Dumm nur, wenn man den nicht nutzen kann, weil man weit
verteilte Einzelzugriffe braucht.
>Ich nehme an, die Zugangsgeschwindigkeit wird vergleichbar, aber>SPI-Variante hat viel kleinere und auch einfachere Platte.
Interessiert im Zeitalter von Multilayer keinen. Und selbst einen
ATxmega kriegt man mit 16 MB SD-RAM auf LEICHT auf 4 Lagen hin,. Been
there, done that. Mit sportlichem Ehrgeiz vielleicht sogar auf 2. Siehe
Anhang, die Innenlagen sind ausgeblendet, sind nur GND/VCC.
>Versucht mal selber eine Platte zu ätzen, wo so viele Leitungen für>Parallel-SRAM notwendig sind! Das ist natürlich möglich, aber wozu solch>Masochismus? Es geht viel viel einfacher.
Schwachsinn. ATmega64 mit 64kB SRAM ist auf 2 Lagen ohne viel Stress
machbar. Siehe Anhang.
>Wenn statt 4-5 (oder auch 12-16) Takte pro Byte 18 gebraucht werden,>wird das in dem realen Programm kaum zu merken, es sei denn, Programm>macht nichts anderes nur schreibt und liest in/aus Ext-SRAM, sonst gar>nichts macht..
Und das Gesülze geht weiter. Naja, was soll man auch machen, wenn man
weder Durchblick noch handfeste Argumente hat . . .
Maxim B. schrieb:> 1. bei "nativen" Ext-RAM-Interface braucht man NOP für Verzögerungen.
Nein, man trägt im XMEM ein, wieviele Waitstates der Zugriff braucht.
Du vergisst, dass wir nicht von einem manuellen SRAM-Zugriff (mit
Pins, Latch usw) sprechen!
Falk B. schrieb:> Dumm nur, wenn man den nicht nutzen kann, weil man weit> verteilte Einzelzugriffe braucht.
Dafür gibt es interne SRAM. Externe SRAM ist nicht dafür gedacht,
interne zu ersetzen.
S. R. schrieb:> Zeige mir den AVR mit 32 oder 64 KB internem SRAM.
Wenn man so viel SRAM für die Aufgaben braucht, die man mit AVR machen
will - dann liegt das Problem nicht in SRAM sondern woanders. Z.B. man
könnte Programmlogik nachbessern.
Falk B. schrieb:
> ATmega64 mit 64kB SRAM ist auf 2 Lagen ohne viel Stress> machbar.
Machbar - ich sage auch nichts anderes. Aber SPI-SRAM ist viel einfacher
nutzbar mit für Praxis beinahe gleicher Geschwindigkeit. Und 128
kbytes-SRAM braucht statt 27 oder 28 Signalleitungen nur vier!
Falk B. schrieb:
> Interessiert im Zeitalter von Multilayer keinen.
Multilayer ist für Profi gedacht. Ich habe nie gehört, daß ein Hobbyist
zu Hause eine Platte mit mehr als 2 Kupferschichten geätzt hat. Wer aber
das versuchen will, auch mit metallisierten Bohrungen, dann viel Glück.
Und wer 1 Stück bei Chinesen bestellen will, dem wünsche ich auch viel
Spaß!
Maxim B. schrieb im Beitrag #5441368:
> Wenn man so viel interne SRAM braucht, dann liegen die Gründe dafür> sicher woanders. Z.B. daß man das Programmieren noch nicht genug gut> gelernt hat.
Definitiv. Alle halbwegs modernen Controller mit etwas mehr RAM sind
also nur für inkompetente Programmierer. Und wer für größere Datenraten
oder Grafiken große Puffer braucht macht auch was falsch.
Dr. Sommer schrieb:> Maxim B. schrieb:>> Sie sind für andere Aufgaben>> Es wurde noch überhaupt nicht gesagt was die Aufgabe ist.
Na, wenn man AVR statt PC einsetzen will, so etwa mit Windows 10, dann
stimmt, dann braucht man viel SRAM...
Ansonsten gibt es Aufgaben, wofür AVR geeignet ist, und es gibt
Aufgaben, wofür AVR nicht sinnvoll ist.
Maxim B. schrieb:> Dr. Sommer schrieb:>> Maxim B. schrieb:>>> Sie sind für andere Aufgaben>>>> Es wurde noch überhaupt nicht gesagt was die Aufgabe ist.>> Na, wenn man AVR statt PC einsetzen will, so etwa mit Windows 10, dann> stimmt, dann braucht man viel SRAM...>> [...]
Jetzt reisst mir aber auch bald der Faden, bei Deinem Gefasel.
Niemand wird angesichts einer bestimmten Aufgabe ernsthaft zwischen PC
und AVR abwägen. Niemand!
So. Und jetzt herzlich willkommen in meinem CSS-File. Das ist ja nicht
zum Aushalten, was Du da von Dir gibst.
Theor schrieb:> Niemand wird angesichts einer bestimmten Aufgabe ernsthaft zwischen PC> und AVR abwägen. Niemand!
Das freut mich.
Habe ich dich richtig verstanden, daß du auch der Meinung bist, AVR hat
ganz bestimmte Einsatzgebiet und nicht alles ist sinnvoll, mit AVR zu
machen?
Große Systeme mit vielen Chips mit Parallelinterface gehören sicherlich
nicht zu dem, was man mit AVR machen sollte - obwohl rein rechnerisch
die Leistung von AVR Leistung von Z80 weit übersteigt, und mit Z80
machte man ja auch Hauscomputer.
Einfache kleine Geräte mit hauptsächlich seriell verbundenen externen
Chips, das gehört schon zu AVR. Gestern sollte man alles mit 8 bit
machen. Heute gibt es Mikrocontroller mit 32 bit, die für kompliziertere
Aufgaben, die viel RAM brauchen, viel besser passen.
Ich sage hier in keiner Weise, daß man nicht experimentieren sollte. In
keinem Fall! Wenn man dadurch Spaß bekommt, kann man meinetwegen ein
Computer mit SN74-Serie alleine machen. Warum nicht, wenn das Spaß
macht?
Aber vernünftiger wäre es, ein Computer HEUTE doch nicht aus SN7400 und
sogar nicht mit Z80 machen, sondern mit heute existierenden Prozessoren.
Noch eins: Mikrocontroller haben so viele Möglichkeiten, ihre Pins
unterschiedlich einzustimmen, nicht zuletzt um Leitplatten einfacher
machen zu können. Das sollte man auch nutzen. SPI ist gerade dafür
gedacht, auch I2C, um für einfache Aufgaben nicht unbedingt xxx Linien
ziehen zu müssen. Das sollte man auch benutzen.
Deshalb meine Kritik an TO: er hat es ausprobiert, wie man externe RAM
mit AVR bedienen kann. Das ist für Einstudieren gut und lobenswert.
Praktische Sinn hat das aber kaum: alle Aufgaben, die viel RAM brauchen,
kann man anders oder mit anderen Mitteln viel besser erledigen.
Hallo,
Maxim B. schrieb:> Falk B. schrieb:>> Dumm nur, wenn man den nicht nutzen kann, weil man weit>> verteilte Einzelzugriffe braucht.>> Dafür gibt es interne SRAM. Externe SRAM ist nicht dafür gedacht,> interne zu ersetzen.
das hat Atmel aber wohl völlig anders gesehen...
Des ext_Ram-Interface dient zur Erweiterung des internen SRAM um max.
32kB.
Ohne jede programmtechnische Einschränkung und linearem Adressraum
zusammen mit dem internen Ram.
Gruß aus Berlin
Michael
@ Michael U. (amiga)
>das hat Atmel aber wohl völlig anders gesehen...>Des ext_Ram-Interface dient zur Erweiterung des internen SRAM um max.>32kB.
Nö. Je nach AVR-Typ gehen da 50-60kB zusätzlich, denn außen dem internen
RAM + IO-Registern ist der 64kB Adressraum leer!
Falk B. schrieb:> Nö. Je nach AVR-Typ gehen da 50-60kB zusätzlich
interessant, aber ehrlich ich brauche auch mehr als 2KB SRAM aber die 16
KB eines ATmega1284p habe ich nie ausreizen können, ich bitte um
Beispiele wo auf dem AVR mehr gebraucht wird.
In der Arduino Umgebung gibts ja Alternativen, jetzt z.B. ESP32
Maxim B. schrieb:> Große Systeme mit vielen Chips mit Parallelinterface gehören sicherlich> nicht zu dem, was man mit AVR machen sollte
Warum nicht? Wo es doch ein Parallelinterface gibt?
> Einfache kleine Geräte mit hauptsächlich seriell verbundenen externen> Chips, das gehört schon zu AVR.
Warum? Wo es doch ein Parallelinterface gibt?
Du argumentierst wie eine Großmutter: Sowas tut man nicht, das gehört
sich nicht, das macht man einfach nicht. Gründe gibt es keine, ich bin
einfach davon überzeugt und was ich sage, ist richtig.
Nenne doch mal einen vernünftigen Grund!
"Es geht auch anders" ist kein vernünftiger Grund, sondern ein netter
Hinweis.
Vor allem ist es kein Grund, wenn du eine Lösung vorschlägst, die in
vielen Bereichen deutlich schlechter ist als das, was bereits
existiert. Und vor allem weder die Frage beantwortet, noch das Problem
löst.
> Noch eins: Mikrocontroller haben so viele Möglichkeiten, ihre Pins> unterschiedlich einzustimmen, nicht zuletzt um Leitplatten einfacher> machen zu können. Das sollte man auch nutzen.
Warum sollte ich etwas tun, was garnicht mein Ziel ist?
> SPI ist gerade dafür gedacht, auch I2C, um für einfache Aufgaben> nicht unbedingt xxx Linien ziehen zu müssen. Das sollte man auch> benutzen.
Wer hat denn überhaupt behauptet, dass das Problem darin besteht, eine
Leiterplatte mit möglichst wenigen Linien zu fertigen?
> Praktische Sinn hat das aber kaum: alle Aufgaben, die viel RAM brauchen,> kann man anders oder mit anderen Mitteln viel besser erledigen.
Das ist schlichtweg falsch.
Joachim B. schrieb:> die 16> KB eines ATmega1284p habe ich nie ausreizen können
Genauso.
Wenn ich mehr brauche, dann schalte ich 23LCV dazu.
In Computer ist das ja auch so: es gibt Cash L1, L2, manchmal auch L3,
es gibt DRAM und es gibt Festplatte. Die ersten sind am kleinsten und am
schnellsten, die letzteren am langsamsten und am größten.
AVR hat Register, die kann man als Cash betrachten.
AVR hat SRAM, das wird Stufe zwei, da für alle Operationen sowieso
Register benutzt sein müssen.
Externe RAM kann man als Stufe 3 betrachten. Ähnlich wie in Computer: um
einen Datenblock zu bearbeiten, sollte man den in interne SRAM kopieren.
Dann die Bytes einzeln in Register kopieren, dort sollte eigentliche
Bearbeitung stattfinden. Soweit fertig, in interne SRAM zurück ausladen.
Ist Block bis zu Ende fertig, kann man es in externe RAM zurück
kopieren.
Man kann auch nächste Stufe eingliedern: eine SD-Karte. Dort wird
Zugriff noch langsamer, die Blöcke noch größer und auch Kapazität.
So sollte Speicherstruktur eines größeren Projekts mit AVR aussehen.
Hier ist ersichtlich, daß externe RAM nicht so schnell sein muß, wie
interne. Man macht ja auch keine Computer, wo Prozessor GB-Cash L1 hat!
Oft gibt es noch einen Grund, keine zu schnelle externe Geräte zu
verwenden: EMI. Solange Operationen intern bleiben, kommt nichts auf
Pins. Wenn aber in externe SRAM geschrieben oder gelesen wird, haben wir
xx mal Sender-Antenne. Auch hier ist natürlich von Vorteil, 4 Antennen
(SPI) statt 30 Antennen zu haben.
@Joachim B. (jar)
>interessant, aber ehrlich ich brauche auch mehr als 2KB SRAM aber die 16>KB eines ATmega1284p habe ich nie ausreizen können, ich bitte um>Beispiele wo auf dem AVR mehr gebraucht wird.
Siehe mein Beispiel, der ATmega64 arbeitet hier als DMX-Rekorder, der
mit 22kB/s DMX-Daten auf SD-karte schreibt. Da diese je nach Typ 100ms
und mehr "Gedenkpause" einlegen kann, wenn neue Sektoren gelöscht werden
müssen, muss man die Daten in einem FIFO zwischenpuffern. Und die
100ms sind eher ein Optimum, bei meinen Test mit billigen NoName Karten
war es deutlich mehr, eher 500ms++.
Außerdem, Speicher kann man immer sehr schnell vollkriegen, ganz egal ob
kB, MB oder GB. Steuer ein mittelgroßes Grafik-LCD mit einem AVR an,
schwups brauchst du viel Speicher.
Falk B. schrieb:> Je nach AVR-Typ gehen da 50-60kB zusätzlich,
Auf einem ATmega8515 sind es über 63 KB.
Joachim B. schrieb:> ich bitte um Beispiele wo auf dem AVR mehr gebraucht wirdAVR CP/M. Farbgrafik ab 320x240. Analyse längerer Datenreihen
(Tagesmittel, Wochenmittel).
Es gibt genug Beispiele, die allein wegen des mangelnden RAMs nicht oder
nur umständlich auf AVRs lösbar sind, trotz Rechenleistung und I/O satt.
Lies mal hier im Forum.
S. R. schrieb:> AVR CP/M. Farbgrafik ab 320x240.
OK Grafik habe ich nur indirekt genutzt, Text auf Grafikdisplay touch
TFT
Ich habe aber nicht die Pixel zwischengespeichert sondern den Text und
statt vor dem Neuschreiben nicht das ganze Display gelöscht sondern den
alten Text in schwarz überschrieben an gleicher Position um dann den
Text in der gewünschten Farbe zu aktualisieren, das spart Zeit und
Speicher.
Beitrag "Re: Welches Touchscreen modul ist für einen Arduino UNO R3 geeignet?"
S. R. schrieb:> Es gibt genug Beispiele, die allein wegen des mangelnden RAMs nicht oder> nur umständlich auf AVRs lösbar sind, trotz Rechenleistung und I/O satt.> Lies mal hier im Forum.
In allen diesen Fällen kann man externe SPI-RAM als Puffer verwenden. Es
ist nicht essentiell, für alle 64-128 kbytes byteweise Zugriff zu haben
(obwohl auch SPI-SRAM das kann, nur ein bißchen langsamer, als
blockweise).
Interface für externe Speicher kann man als Überbleibsel von
51-Mikrocontrollern betrachten. Dort war das immer da, obwohl nicht alle
Chips ohne internen Programmspeicher waren.
Erste 51-Kontroller ohne Interface war 2051, pinkompatibel zu späteren
AVR ATtiny2313. Ich habe noch mit 2051 gespielt... Die ersten AVR, so
wie 8515, hatten Interface für externe SRAM, da sie zu wenig interne
SRAM hatten (z.B. 512 bytes). Aber je weiter, um so weniger war das
aktuell. Heute haben nur die größeren AVR solch Interface. Alle mit
28/32 und 40/44 Pin haben das nicht mehr. Weil einfach nicht mehr
notwendig.
Hallo,
Falk B. schrieb:> Nö. Je nach AVR-Typ gehen da 50-60kB zusätzlich, denn außen dem internen> RAM + IO-Registern ist der 64kB Adressraum leer!
Du hast völlig Recht mit Deiner Korrektur. Habe ich sogar mal ziemlich
ausgereizt, 32k Parallel-Flash und 32k SRAM.
Joachim B. schrieb:> interessant, aber ehrlich ich brauche auch mehr als 2KB SRAM aber die 16> KB eines ATmega1284p habe ich nie ausreizen können, ich bitte um> Beispiele wo auf dem AVR mehr gebraucht wird.> In der Arduino Umgebung gibts ja Alternativen, jetzt z.B. ESP32
2 alte Beispiele: MP3-Player mit 90S8515, MAS3507 und 6GB 2,5" HD im
Amiga-FastFileSystem. Beim Start habe ich alle Titel und deren
Startsektoren der HD eingesammelt, um schnelles Blättern durch die
Titelliste wärend des Spielens zu ermöglichen. An AVR mit mehr Ram war
da noch nicht zu denken.
Heute macht das logischweise ein ESP32 und der dekodiert das MP3 auch
noch in Software dabei...
Etwas (wohl für immer) unvollendetes noch, wo ein Mega1284 gerade
reichen würde: die Emulation eines C= 1541-Laufwerks von einer SD-karte.
Also nur das Laufwerk am Original-Floppy-Rechner emulieren. Dazu sind
schon rund 8k Ram für den Trackbuffer nötig und SD-Routinen, Display
usw. wollen ja auch noch etwas.
Vielleicht mache ich das aber auch nochmal weiter, ist kein
Softwareproblem, sondern der Bau des Adapters um die Leiitungen von den
VIA-Ports zu holen...
Gruß aus Berlin
Michael
Hallo,
Maxim B. schrieb:> Heute haben nur die größeren AVR solch Interface. Alle mit> 28/32 und 40/44 Pin haben das nicht mehr. Weil einfach nicht mehr> notwendig.
die kleinen AVR hatten noch nie eins. Der erste war der 90S8515. Der
Mega8515 hat es behalten, der Mega162 auch. Das war auch der letzte, bei
dem ich es tatsächlich genutzt habe. Bei den anderen Serien habe ich
mich nichtmal dafür interessiert, ob sie eins hatten.
Gruß aus Berlin
Michael
Maxim B. schrieb:
Langsam tuts weh, hier mitzulesen....
Willst oder kannst du nicht begreifen, daß die einzige Gemeinsamkeit bei
via Memory-Interface angebundenem Speicher und ext. SPI-RAM die Tatsache
ist, daß es sich dabei um einen flüchtigen Speicher (aka RAM) handelt?
Das via Memory-Interface angebundene RAM kann ein Compiler direkt und
ohne Klimmzüge als Stack und Heap nutzen.
Das geht mit KEINEM der von dir vorgeschlagenen Speicher.
Wenn du glaubst, daß nicht zu benötigen, mangelt es dir offenbar an
Erfahrungen und/oder Fantasie.
@ Harry L. (mysth)
>Wenn du glaubst, daß nicht zu benötigen, mangelt es dir offenbar an>Erfahrungen und/oder Fantasie.
Keine Sorge, das kompensiert er mühelos mit Tunnelblick und
missionarischem Eifer ;-)
Parallel angesteuerte SRAMs sind TEUFELSZEUG!!! Hinfort!
Serial forever!
Michael U. schrieb:> Etwas (wohl für immer) unvollendetes noch, wo ein Mega1284 gerade> reichen würde: die Emulation eines C= 1541-Laufwerks von einer SD-karte.> Also nur das Laufwerk am Original-Floppy-Rechner emulieren. Dazu sind> schon rund 8k Ram für den Trackbuffer nötig und SD-Routinen, Display> usw. wollen ja auch noch etwas.> Vielleicht mache ich das aber auch nochmal weiter
ach ja die guten alten Zeiten, meinen PET2001 habe ich verkauft als er
noch Wert hatte, er machte Spass aber ich wollte nicht sammeln.
In den '80er hatte ich viel mit dem PC1500 gemacht Ports extern ADC DAC
und in um 2005 angefangen PC1500 auf Ebay zu sammeln um wieder
anzufangen, aber als wieder mal Alkaline und NiCd ausgelaufen sind habe
ich alles verschrottet, die Restlebenszeit reicht nicht und man fragt
sich wozu?
Michael U. schrieb:> Der erste war der 90S8515. Der> Mega8515 hat es behalten, der Mega162 auch.
Alle schon alt. Für neue Entwicklungen passen die kaum mehr.
Harry L. schrieb:> Langsam tuts weh, hier mitzulesen....
Ich habe keine Absicht, mit passendem Werkzeug jemand zu zwingen, zu
lesen... Jeder liest freiwillig oder?
Falk B. schrieb:> Parallel angesteuerte SRAMs sind TEUFELSZEUG!!! Hinfort!> Serial forever!
So könnte ich nicht sagen. Mit 51-Serie war parallele RAM sehr gut am
Platz: die hatten nur 128 oder 256 Bytes intern... So vor 20 Jahren...
Hast du vielleicht nicht bemerkt: heute sind sogar Festplatten schon
lange seriell.
Maxim B. schrieb:> Ich habe keine Absicht, mit passendem Werkzeug jemand zu zwingen, zu> lesen... Jeder liest freiwillig oder?
Ja, aber einer schreibt Dummfug. ;-)
Harry L. schrieb:> Willst oder kannst du nicht begreifen, daß die einzige Gemeinsamkeit bei> via Memory-Interface angebundenem Speicher und ext. SPI-RAM die Tatsache> ist, daß es sich dabei um einen flüchtigen Speicher (aka RAM) handelt?
Nicht ganz. Das ist eine Zwischenstufe. Von einer Seite ist SPI-RAM viel
schneller bei WR als Flash, hat auch keine 100 000 oder 1000 000 mal
Grenze. Von anderer Seite ist solche RAM sehr leicht mit Batterie zu
puffern, bei 23LCV ist ganze notwendige Logik drin. So kann man diese
Variante als nichtflüchtige schnelle und langlebige Flash betrachten und
gleichzeitig auch als SRAM-Puffer.
> Das via Memory-Interface angebundene RAM kann ein Compiler direkt und> ohne Klimmzüge als Stack und Heap nutzen.>> Das geht mit KEINEM der von dir vorgeschlagenen Speicher.
Wenn man viel SRAM mit direktem Zugang braucht, dann ist AVR falsch am
Platz. Das ist so etwas, wenn man täglich von Leipzig nach Berlin und
zurück mit dem Fahrrad zu Arbeit fährt... Man kann das sicher auch,
sogar gut für Gesundheit, aber...
So etwa vor 20 oder 25 Jahren habe ich mit Parallel-SRAM nichtflüchtige
RAM gebaut. Das war für Experimente mit 51-Serie gedacht, als
Programmspeicher. Das ging. Alles war machbar, alles arbeitete
befriedigend (ich hatte damals auch Interface für Kassettenrekorder
realisiert. Wenn man Zeit hat, ist alles möglich) . Aber das war auch
annähernd nicht so bequem, wie mit 23LCV: ich sollte selber um korrektes
Abschalten ohne Datenverlust sorgen. Und hier ist alles drin! Hat man in
System noch eine Uhr, so bekommt man Li-Batterie für Puffer gratis!
Damals war Platte auch selbstgemacht. Aber ich versuche es immer, die
Platte so einfach wie nur möglich zu machen. Gerade weil ich früher jede
Platte so lange basteln sollte.
Aber ich habe nichts dagegen: wenn jemand glaubt, es ist besser,
einfache Programm und kompliziertere Platte haben - solche
Aussichtspunkt kann auch existieren... Besonders wenn das nur als
Projekt auf dem Papier oder auf dem Steckbrett bleibt.
Maxim B. schrieb:> Aber ich habe nichts dagegen: wenn jemand glaubt, es ist besser,> einfache Programm und kompliziertere Platte haben
Noch einfacher ist es einen Controller zu nehmen, welcher integriertes
batteriegestütztes SRAM hat. Einige STM32 haben hier 4kB (wird über
separaten Pin versorgt). Ist zwar nicht ganz so viel, aber für ein paar
Einstellungen sollte es gut reichen. Das lässt sich übrigens auch super
komfortabel im Programm ansteuern, man kann die Variablen einfach da
rein legen.
Maxim B. schrieb:> Von einer Seite ist SPI-RAM viel> schneller bei WR als Flash,
Was faselst du da von Flash?
Es geht um RAM - kennst du den Unterschied?
Maxim B. schrieb:> Aber das war auch> annähernd nicht so bequem, wie mit 23LCV: ich sollte selber um korrektes> Abschalten ohne Datenverlust sorgen. Und hier ist alles drin! Hat man in> System noch eine Uhr, so bekommt man Li-Batterie für Puffer gratis!
Du hast echt NICHTS begriffen!
Du hast Recht: STM32 paßt besser für die Zukunft als AVR. AVR wird
bestimmt immer mehr als eher Übecontroller benutzt, und dann wird AVR
gar eingestellt...
Harry L. schrieb:> Was faselst du da von Flash?> Es geht um RAM - kennst du den Unterschied?
Es geht um externe Speicher. Interne und externe - kennst du den
Unterschied?
Das sind verschiedene Arten. Verschiedene Philosophie. Will man sie
verwechseln - wie sagt ein bekannter Tontechniker, es gibt keine
Audiopolizei... :)
Maxim B. schrieb:> STM32 paßt besser für die Zukunft als AVR
Es soll sogar Leute geben, die einen STM32 mit ext. RAM ausstatten....
Solche pauschalisierten Aussagen sind einfach Bullshit!
Maxim B. schrieb:> Das sind verschiedene Arten. Verschiedene Philosophie.
QUATSCH!!!
Der einzige Unterschied sind ggf erforderliche Waitstates, da der
Zugriff auf den internen Speicher meist schneller ist.
Aus Compiler-Sicht gibts da keinen Unterschie - vorauisgesetzt, der
Speicher ist linear im Adressraum der CPU abgebildet.
Und genau Letzteres geht eben mit seriellen Speicher bei der CPU um die
es hier geht nicht.
Harry L. schrieb:> Solche pauschalisierten Aussagen sind einfach Bullshit!
Deine Latein verstehe ich kaum.
Harry L. schrieb:> QUATSCH!!!> Der einzige Unterschied sind ggf erforderliche Waitstates, da der> Zugriff auf den internen Speicher meist schneller ist.
Es geht hier eher um Unterschied zwischen Mikrocontroller und Prozessor
für Computer.
Maxim B. schrieb:> Es geht hier eher um Unterschied zwischen Mikrocontroller und Prozessor> für Computer.
Schon wieder vollkommener Bullshit!
Lies mal den Titel des Thread!
Ausserdem ist der Unterschied viel kleiner als du glaubst.
Harry L. schrieb:> Ausserdem ist der Unterschied viel kleiner als du glaubst.
Mach wie du willst. Willst du Computer mit AVR, warum sollte das mein
Problem sein?
Maxim B. schrieb:> Wenn man viel SRAM mit direktem Zugang braucht, dann ist AVR falsch am> Platz.
So ein Blödsinn. Man muß einfach nur einen AVR nehmen, der genau das
vorsieht. Zufällig ist der Mega2560 des TO genau so einer, es gibt aber
auch noch andere, die das können...
Sowohl den Controller als auch den RAM hat der TO also richtig gewählt,
er ist nur zu blöd, beides richtig zu benutzen. Und du wohl definitiv
auch...
Es gibt prinzipiell zwei Möglichkeiten, ihn "richtig" (also effizient)
zu benutzen, bei beiden muss man nur die unteren acht Bit des
Adressbusses an die dafür vorgesehenen Pins des Controllers legen. (Und
natürlich auch den Steuerbus des RAMs mit den dafür vorgesehenen Pins
des Controllers verbinden).
Der Rest des Adressraums kann wahlweise durch Banking erschlossen werden
(alle Adressbits>7 werden explizit über Portausgaben angesteuert) oder
halt unter Benutzung eines zusätzlichen Hardware-Latches zum
Demultiplexing der controllerseitig vorgesehen Adressierung von externem
Speicher bis zur 64k-Grenze.
Und, last but not least: natürlich ist auch ein Mischform möglich, wenn
es mehr als 64k Speicher werden sollen. Eine Grenze nach oben besteht
für das Paging allein durch die Zahl der verfügbaren Pins des
Controllers.
c-hater schrieb:> Der Rest des Adressraums kann wahlweise durch Banking erschlossen werden
Banking ist schlechteste, was aus dem PIC nur kommen könnte.
Wenn ich mal zu der Idee käme (im Leben kann ja vieles passieren),
extern parallel SRAM zu benutzen, dann hätte ich entweder
Hardware-eigene RAM-Interface im Kopf (mit Latch) oder volle
Programmsteuerung (aber in diesem Fall hätte ich bestimmt SPI-RAM
gewählt). Oder (jetzt werde ich wohl von allen Seiten gegriffen)
parallele RAM mit 2x MCP23S17 oder MCP23017 als Interface.
Hälfte von Adresse per Hardware und Hälfte im Programm - das ist
schlechteste Idee aus allen möglichen.
Wir Organisten nennen das "Werk-Prinzip". Entweder - oder, keine
Zwischenstufen. Entweder spielst du Hauptwerk, oder Brustwerk. Entweder
ist ein Register gezogen, oder nicht gezogen.
Maxim B. schrieb:> Banking ist schlechteste, was aus dem PIC nur kommen könnte.
Banking hat mit einem PIC nichts zu tun.
Ja ich weiß, es gibt PICs mit Banking. Darum geht es aber nicht.
Du verwechselst da was. Absichtlich.
Maxim B. schrieb:> Hälfte von Adresse per Hardware und Hälfte im Programm - das ist> schlechteste Idee aus allen möglichen.
Es gibt Probleme und es gibt Lösungen.
Und manchmal passen Probleme und Lösungen wunderbar zusammen.
Egal, ob die Lösung oder das Problem hässlich sind.
Wie bei Menschen auch.
Maxim B. schrieb:> Wir Organisten nennen das "Werk-Prinzip". Entweder - oder, keine> Zwischenstufen. Entweder spielst du Hauptwerk, oder Brustwerk. Entweder> ist ein Register gezogen, oder nicht gezogen.
Schuster, bleib bei deinen Leisten.
Organist, bleib bei deinen Orgeln.
Thread beobachten
Seitenaufteilung abschalten