Hallo an alle!
Ich möchte gerne eine Ausgabeeinheit erstellen. Das ganze soll so
aussehen. Ich hab ein Grafikdisplay mit 240x128P mit einem T6963c
Controller. Diesen Controller soll ein µC (Mega8515 oder Mega162)
angesteuert. werden. Die eigentlich zum anzeigenen gedachten Daten
bekommt dieser µC über Rs232. Soweit so gut.
Nur wie schaut es mit den Ressourcen aus?? Schafft das so ein µC ohne
zusätzlichen SRAM??
Deswegen hab ich an die µCs Gedacht, da diese ein XMEM Interface für
exteren Ram haben.
Nun zu meinem nächsten Problem. Da die beiden µCs nur maximal 64kB
adressieren können, bin ich beschränkt (CPLD will ich keinen verwenden).
iCh bekomme aber 128kB SRAM. Kann ich den trotzdem verwenden??
Welche Tips könnt ihr mir noch für das Projekt geben??
Danke im Voraus
Gruß Robert
Hallo,
zum Ram: wenn Du 128kB hast, legst Du die höchste Adress-Leitung fest
auf L oder H und benutzt nur die Hälfte -> 64kB. Du kannst die auch an
ein Portpin legen und dann damit zwischen 2 64kB-Bänken umschalten. Da
muß Du dann natürlich selber aufpassen, daß Deine Schreib- Lesebefehle
die gewünschte Bank benutzen.
zum Display: das hat ja seinen Ram und die möglichen Geschwindigkeiten
beim Aktualisieren sind ohnhin begrenzt, Filme wirst Du also kaum
abspielen wollen. ;)
Es hängt also sehr davon ab, was Du eigentlich darstellen willst, wie
oft und vor allem wieviel des Display-Inhalts verändert werden muß.
Da ja auch die serielle Schnittstelle Grenzen setzt, sehe ich von der
Seite wenig Probleme.
Gruß aus Berlin
Michael
Hi Michael,
Danke für Antwort zum Ram.
Das Meiste was angezeigt wird, ist natürlih Text. Aber auch klaine
monochrome Bitmap Grafiken. DIese bekommt der µC eben über die Serielle
Schnittstelle.
Jedoch bin ich mir nicht sicher, ob 16k Flash für alles reichen. Vor
allem für die Grafikroutinen. Wird das ausreichend sein?
mfg Robert
Was ich mich shconmal gefragt hab ist, ob man sonen Display nicht
vieleicht ans XMEM hängen kann und dann halt auf das Display wie auf den
SRAM zugreifen kann (halt der "Externe RAM" das Display ist ... sone Art
MemmoryMappedIO)
Läubi Mail@laeubi.de wrote:
> Was ich mich shconmal gefragt hab ist, ob man sonen Display nicht> vieleicht ans XMEM hängen kann und dann halt auf das Display wie auf den> SRAM zugreifen kann (halt der "Externe RAM" das Display ist ... sone Art> MemmoryMappedIO)
Dafür sind sie gebaut, diese Displays...
...
Hallo,
@Läubi:
ja, geht ohne Probleme, bei mir bis ca. 10MHz Clock. Mit 16MHz stimmte
irgendwie das Timing nicht mehr, es gab Pixelfehler, egal, mit welcher
Wait-Einstellung.
Bustreiber haben auch nicht geholfen.
Ansonsten: was für ein Anschlußplan?
Daten an Daten, RD an RD, WR an WR, CE an eine der oberen 8
Adressleitungen.
EXTMEM ein und der Zugriff geht eben mit sts/lds.
Die Registeradressen sind Rechenaufgabe, jenachdem, welches Adressbit Du
nimmst.
Im Anhang hängt eine alte Experimetier-Source, da sind 8k Ram und das
Display dran, mußt Du Dich allerdings mal durchgraben.......
Gruß aus Berlin
Michael
Wenn es schnell werden soll, betreibe den internen Speicher nur
schreibend und halte ein Abbild der Bits/Bytes im µP. Das Rücklesen aus
dem T6963 dauert einfach zu lange.
Hallo,
@Fritz:
das ist so eine Sache, die ich nicht verstehe.
Was soll ich aus dem Display auslesen müssen?
Ich zeige auf dem Display Sachen an, die sich aus meinem Programmlauf
ergeben. Einen Wert z.B. als Balkengrafik. Ich habe also diesen Wert,
eine Routine macht den Balekn auf dem Display draus.
Der Wert ändert sich und ich lasse einen neuen Balken malen.
a) was interessiert mich, wie der alte Balken aussah? Wenn ich den alten
Wert noch brauche, merke ich mir diesen eben.
Ich würde z.B. ja auch keinen Wert auf einem gemalten Kreisumfang
irgendwie auslesen wollen, weil ich nicht wüßte, wozu.
Die einzige Ausnahme, die ich mir erklären könnte, wäre ein Spiel mit
Kollisionsabfragen der Objekte. Nur ob ich das auf einem AVR mit einem
T6963c unbedingt machen wollte?
Gruß aus Berlin
Michael
> das ist so eine Sache, die ich nicht verstehe.
Wenn man z.B. Koordinaten anzeigt und beschriftet, ist es meines
Erachtens sinnvoll, die auszugebende Kurve durch XOR mit den vorhanden
Pixeln anzuzeigen. Eine nochmalige Ausgabe löscht dann die Kurve, läßt
den Rest aber unverändert. Wenn man dieses XOR im Speicher des µP
durchführt, geht es schneller, als das Display-RAM zu lesen und neu zu
schreiben.
Klar kann man alles erneut ausgeben, dauert dann eben länger.
Hallo,
die Frage, die sich mir da immer stellt: hat es in der konkreten
Anwendung irgendeinen praktischen Nutzen, daß es schneller geht.
Wenn der AVR sich sowieso die meiste Zeit langweilt, habe ich nichts
davon, wenn er sich noch etwas mehr langweilt. ;)
Displayausgaben kann ich in solchen Anwendungen meist nicht so schnell
ablesen, daß es Sinn macht, allzuoft zu aktualisieren, ich will ja von
der Anzeieg auch noch was lesen können.
Bei meinen Versuchen habe ich statische Anzeigen (Koordinatenraster des
Oszi usw.) als selbstdefinierte Textzeichen im Textlayer. Der
Grafiklayer wird zeigt nur die Kurve und wird immer komplett gelöscht.
Ich hätte lieber einen 2. Grafiklayer aufgemacht, dann müßte ich aber
meinem Display erst etwas mehr als seine jetzigen 8kB Ram verpassen.
Gruß aus Berlin
Michael
> die Frage, die sich mir da immer stellt: hat es in der konkreten> Anwendung irgendeinen praktischen Nutzen, daß es schneller geht.
Gegenfrage: hast Du schon mal eine Laufschrift auf solch einem Display
gemacht, und ist sie gelaufen oder geruckelt ? Hast Du schon mal
EKG/Blutdrucksignale als 'rollende' Kurve angezeigt ?
Verwendest Du lieber einen C-Compiler oder eine BASIC-Interpreter für
Deine Programme ? Versuchst Du Deine Variablen möglichst als char oder
int zu halten oder ist Dir float lieber ?
Wenn man es braucht, dann ist schneller eben besser :-)
Wenn nicht, dann ist es egal.
Der Thread hat sich ja richtig entwickelt ;)
Eine Frage hab ich dann noch. Wenn ich das Display auch an XMEM
Interface hänge, hab ich 2 2 Geräte laufen (Display und SRAM).
Funktioniert das??
Kann ich 2 Geräte am Bus verwenden, oder muss da ein CPLD her??
Wenn ja, wie schaut hierfür der genaue Schaltplan aus?
Danke im Voraus
Gruß Robert
Hallo,
@Fritz:
nein, weder Laufschrift noch EKG, für beides fehlte mir bisher
Notwendigkeit oder Interesse.
Damit der Kram nicht ruckelt, ist ja pixelweises verschieben nötig. Das
ist bei der Organisation des Display-Rams sowieso etwas aufwändiger.
"Ruckeln" wird es je nach Displaygröße dabei immer etwas, der Versatz um
einen Pixel ist optisch meist schon zu groß. Andererseits liegt Ruckeln
oft garnicht daran, sondern daran, daß die Refreshs nicht absolut
gleichmäßig erfolgen. Das Auge empfindet auch sehr kleine
Unregelmäßigkeiten sofort als Ruckler während ein gleichmäßiges
Verschieben um zu große Beträge eher als Flimmern wahrgenommen wird.
Es wäre aber auch dann vermutlich eher die Frage von Ram am AVR, um
Rechnereien zum Löschen/Setzen dort möglichst zeitgünstig zu
organisieren. Der Zugriff auf das Display-Ram ist ohnehin durch das
Display begrenzt, der ist merklich langsamer als es der AVR könnte.
Nein, kein C und kein Basic, nur Assembler.
War auch mehr eine allgemeine Frage, es interessierte mich einfach.
Wo es nötig ist, wird man es logischerweise machen müssen.
Gruß aus Berlin
Michael
Hallo,
@Robert:
die Begrenzung liegt nur im verfügbaren Adressraum und im externen
Dekodieraufwand.
32k Ram und dieses Display erfordern nur einen Inverter an A15.
Ram z.B. vor den Inverter, damit Adressen 0000 - 0FFF.
Display CE hinter den Inverter, damit Adressen 8000 - FFFF.
Wenn jetzt z.B. C/D des Display an A14 hängen, ist auf allen Adressen
zwischen 8000 - BFFF C/D auf 0 und zwischen C000 und FFFF ist C/D auf 1.
Wenn Du z.B. einen 74HCT138 an A13,A14,A15 hängst, bekommst Du 8
Bereiche zu je 8kb die Du mit den Adressen selektieren kannst, da können
dann eben z.B. auch 48kB Ram und drei Displays dranhängen. ;)
Gruß aus Berlin
Michael
Hallo Michael,
Danke für die Erklärung. Ganz verstanden hab ich es noch nicht. Werd mir
das heut mal genau überlegen.
Eine Frage hab ich noch. Welchen Vorteil bringt es mir wenn ich das
Display Memory Mapped an den µC anhänge?
Gruß Robert
DU kannst auf das Display dan einfach wie auf das Interne Ram zugreifen.
D.h. deine SOftware muß sich nicht um das Adressen an den Port ausgeben,
wackeln an WR etc kümmern, das macht alles der AVR für dich und sogar
schneller als in Software :)
> Eine Frage hab ich noch. Welchen Vorteil bringt es mir wenn ich das> Display Memory Mapped an den µC anhänge?
Wie Läubi schon schrieb... Dazu kommt noch, dass Du mehrere Dinge an das
Speicher-Interface gleichzeitig anschließen kannst, also RAM, ein oder
mehrere Displays. Die Auswahl erfolgt dann durch die Adressbereiche.
Gedacht war das ursprünglich für klassische Computer (Prozessor, RAM,
ROM, CTC, I/O über Bus in separaten ICs), da konnte man das Display wie
einen stinknormalen I/O-Baustein anschließen (Adressdecoder
vorausgesetzt), was den Aufbau vereinfachte.
...
Ich werde das Memory Mapped an den Controller anschließen :)
So wie Michael gesagt hat mit dem 74HCT138.
Aber so wie du gesagt hast, könnnen nur 2 Displays angeschlossen werden,
oder?
Mir reicht ein Display. Dann kann ich ja 56kB Ram und 8kB für das
Display machen, oder??
Nur wie schließe ich das genau an??
Für den SRAM hab ich derzeit einen 8 Bit Latch (74HCT573) der mir die
Adressen zwischen speichert. (hängt an A0 - A7). A8 - A12 gehen direkt
zu den Adressleitungen des SRAMs.
AN A13, A14, A15 kommt der Line Decoder (74HCT138). Nur wohin gehen
jetzt diese Ausgänge genau. Wie wird das Display dann angeschlossen??
Wohin gehört der Datenbus.
RD und WR sin klar, die kommen zu WR und RD am AVR. Wohin ghört C/D bei
der VAriante mit dem 74HCT138??
CE ist am XMEM Interface nicht angeschlossen, oder? Die liegt auf einem
normalen i/O Pin, oder?
Ich will halt dass Adr. 0000 - DFFF dem SRAM gehören und E000 - FFFF dem
Display.
Sorry für die vielen Fragen ;)
Danke im Voraus
mfg Robert
> Ich will halt dass Adr. 0000 - DFFF dem SRAM gehören und E000 - FFFF dem> Display.
Ab Adresse 0000? Und was ist mit Registern, I/O und internem SRAM?
...
Hallo,
um die Adressen und Register kümmert sich das XMEM-Interface alleine.
Daten vom Display parallel zu den Ram-Daten.
CE vom Display an den passenden Ausgang des 138 (für E000-FFFF eben O7).
C/D an eine Adressleitung, wenn Du z.B. A0 (am Ram!) nimmst, sind alle
geraden Adressen eben C/D = 1, alle ungeraden 0.
Für den CS vom Ram brauchst Du noch etwas Zusatzlogik, in einfachsten
Fall einen Inverter an O7 vom 138...
Einfache dürfte in genau diesem Fall sein, nur die Adressen von F000 -
FFFF für das Display auszublenden.
Ein 74 HCT20, ein Gatter mit den 4 Eingängen mit an A15,A14,A13,A12.
Dann ist der Ausgang L, wenn alle Eingänge H sind (F-Bereich). Der
Ausgang ist CE vom Display.
Das 2. Gatter mit allen Eingängen parallel an den Ausgang von Gatter 1
als Inverter, das ist CS für das Ram.
Gruß aus Berlin
Michael
Hi Michael,
Jetzt verstehe ich schon mehr ;) Müsste man aber nicht F000 - FFFF für
den RAM ausblenden?? 0000 - EFFF ist für den RAM und F000 - FFFF ist für
das Display? Oder sind die EIngänge Active Low?
Wohin gehört bei der Variante mit dem NAND Gatter der C/D Pin des
Displays?
Gruß Robert
Hallo,
das Ram fühlt sich angesprochen, wenn sein /CS auf L ist.
Damit der Ausgang des 2. Gatters eine HC20 auf L geht, müssen alle
Eingänge auf H sein (Datenblatt greifen, Wahrheitstabelle studieren).
Wenn alle parallel am Ausgang des ersten Gatters liegen und dort auch
/CE vom Display dranhängt, ist also immer entweder Display Ram
angesprochen.
Wann wer dran ist, entscheiden die Eingänge des ersten Gatters.
Die müssen ALLE auf H sein, damit der Ausgang auf L (Display /CE).
Wenn einer der Eingänge auf L ist, bleibt der Ausgang auf H und der
Ausgang des 2. geht auf L -> /CS des Ram.
Eine mögliche Variante für C/D hatte ich oben schon beschrieben.
Mal Dir den Kram mal auf ein Blatt, schreibe die Bitkombinationen ran
und verfolge die Zustände. ;)
Gruß aus Berlin
Michael
Hallo,
Den HC20 verstehe ich. Ich dachte nur, der SRAM ist aktiv wenn ein High
Pegel anliegt. Das ist nun klar.
Wenn ich C/D An A0 am AVR hänge, ist bei alles ungeraden Adressen, CD
auf high, oder?
Das verstehe ich eben nicht. Mit C/D lege ich fest, ob das nächste Byte
ein Steuerkommando oder ein Datenbyte ist, oder?
Was bringt es mir genau wenn das auf A0 liegt. Muss dies überhaupt über
das XMEM Interface angesteuert werden?
Danke im Voraus
mfg Robert
Hallo,
"Das verstehe ich eben nicht. Mit C/D lege ich fest, ob das nächste Byte
ein Steuerkommando oder ein Datenbyte ist, oder?"
Naja.... vielleicht liegt es nur an der Ausdrucksweise. ;))
Der Zustand von C/D sagt dem Display, ob anliegende Byte Kommando oder
Daten ist.
Merkst Du den Unterschied?
Wenn A0 an C/D liegt und Du schreibst an Adresse F000 ergibt sich
folgender Zustand:
A15...A12 = H -> also Display CD auf L
A11....A1 = L -> interesieren das Display nicht, sind nicht
angeschlossen.
A0 = 0 -> C/D Display auf 0, also Datenbyte
D0....D7 = die Daten
Der Zustand besteht, bevor /WE oder /RD aktiv wird und entscheidet, ob
gelesen oder geschrieben wird.
Ist es ein STS $F000,123 wird /WR aktiv und das Display liest das Byte
und nimmt es als Datenbyte.
Ist es LDS wird /RD aktiv und das Display legt die Daten auf den
Datenbus.
Den Ram interessiert das Ganze wegen dem negierten /CE des nicht, der
hat /CS auf H.
Wenn Du STS $F0001,123 machst, was macht das Display wohl dann? :)
Gruß aus Berlin
Michael
Ist es
Solange du die eigentlichen Grafikdaten nur von der UART ans Display
durchreichen willst, reicht ein Mega162 locker. Das Grafikdisplay hat
eigenes Ram (sollte es zumindest...), und wenn du nicht gerade
superschnelle bewegte Grafiken darstellen willst, reicht es völlig aus,
die Daten byte- oder blockweise aus dem Displayram zu lesen, zu
modifizieren, und wieder zurückzuschreiben. Und 16MB wollen selbst mit C
erstmal mit Code gefüllt sein.
Wenn du allerdings tatsächlich unbedingt :-) ein Speicherabbild des
Displays im Controller-eigenen SRAM halten MUSST, dann brauchst du
zusätzliches SRAM. Der Mega kommt mit nur 1kB, 240*128 ergeben aber
3840Byte.
Oliver
