mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Code(SRAM steuern) verbessern. Arduino mega 2560


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Joschka A. (joschka_a)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.
byte SramRead(unsigned int addr){
  PORTC = lowByte(addr);
  PORTL = highByte(addr);
  DDRB = 0x00;  //I/O Register soll ausgelesen werden
  
  PORTD = 0b00000100; // CE und OE werden auf LOW gesetzt. Siehe Datenblatt
  asm volatile(
    "NOP\n"
    "NOP\n"
  );
  byte temp = PINB;

  PORTD = 0b00000111;
  return temp;
}

Restlicher Code im Anhang.

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann externen SRAM direkt unter C benutzen.
Schau mal ins Datenblatt:
"Figure 9-2. External SRAM Connected to the AVR"

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AD0..7 -> Digital22..29
A8..15 -> Digital37..30 (absteigend!)
ALE    -> Digital39
RD     -> Digital40
WR     -> Digital41

Autor: Beo Bachta (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Maxim B. (max182)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Maxim B. schrieb:
> Es gibt externe SRAM mit SPI-Interface.

Die sind aber langsamer.

Autor: Beo Bachta (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Thomas P. (topla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joschka stellt eine Frage, sein einziger Post hier,
und der Beobachter beobachtet was daraus wird und kommentiert schon mal 
in seinem Namen. Troll-Alarm.

Autor: Beo Bachta (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Carl D. schrieb:
> Troll-Alarm.

Man kann es auch übertreiben.

Die Admins wissen dass es nicht so ist wie du es meinst zu wissen.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter D. (peda)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Falk B. (falk)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
@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.

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

: Bearbeitet durch User
Autor: Falk B. (falk)
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
@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 . . .

Autor: Falk B. (falk)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Mist, hier der ATmega64 mit 64kB SRAM.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: Maxim B. (max182)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maxim B. schrieb:
> Dafür gibt es interne SRAM.

Zeige mir den AVR mit 32 oder 64 KB internem SRAM.

Beitrag #5441368 wurde vom Autor gelöscht.
Beitrag #5441371 wurde vom Autor gelöscht.
Beitrag #5441375 wurde vom Autor gelöscht.
Autor: Maxim B. (max182)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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ß!

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Alle halbwegs modernen Controller mit etwas mehr RAM sind
> also nur für inkompetente Programmierer.

Sie sind für andere Aufgaben.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Maxim B. schrieb:
> Sie sind für andere Aufgaben

Es wurde noch überhaupt nicht gesagt was die Aufgabe ist.

Autor: Maxim B. (max182)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Theor (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Falk B. (falk)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
@ 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!

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Falk B. (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@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.

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maxim B. schrieb:
> AVR hat Register, die kann man als Cash betrachten.

Ich konnte bisher nirgends mit AVR Registern bezahlen...

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 wird

AVR 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.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?"

: Bearbeitet durch User
Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk B. (falk)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
@ 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!

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Maxim B. (max182)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maxim B. schrieb:
> Ich habe keine Absicht, mit passendem Werkzeug jemand zu zwingen, zu
> lesen... Jeder liest freiwillig oder?

Ja, aber einer schreibt Dummfug. ;-)

Autor: Maxim B. (max182)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das genannte SRAM CY62256 mit 32kB kostet 1,99€:

https://www.reichelt.de/DRAM-FRAM-SRAM/CY-62256-NLL-70P/3/index.html?ACTION=3&GROUPID=2954&ARTICLE=188812&START=0&OFFSET=16&;

Hier gibt es ein IC mit 32 kB SRAM und SPI-Schnittstelle... und einem 
Prozessorkern, das nennt sich Mikrocontroller. Kostet 1,83€:
http://de.farnell.com/microchip/atsamd20g18a-mn/mcu-32bit-cortex-m0-48mhz-qfn/dp/2460537

Da eine Firmware drauf flashen welche Zugang zum Speicher via SPI bietet 
und schon hat man Geld gespart! Indem man den AVR auch noch weglässt und 
das komplette Programm auf dem M0 laufen lässt spart man noch mehr Geld 
und Platinenfläche.

Autor: Maxim B. (max182)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

: Bearbeitet durch User
Autor: Maxim B. (max182)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Falk B. (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@Harry L. (mysth)

>Du hast echt NICHTS begriffen!

Sachkenntnis kann jede lebhafte Diskussion nur behindern. ;-)

Autor: Maxim B. (max182)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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... :)

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Maxim B. (max182)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Man kann mit einem Beil Operationen machen. Man kann mit einem Skalpell 
Bäume fällen...

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Maxim B. (max182)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: c-hater (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Maxim B. (max182)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Beitrag #5442338 wurde vom Autor gelöscht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.