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... ...
Leider finde ich nirgens nen Anschlußplan / AppNote dazu (das Init muß ja auch erstmal durchgeführt werden)
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.
Danke Michael werd ich bei Gelegeheit mal austesten!
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? ...
Hast Recht, die Hab ich ganz vergessen. Halt nach dem Berech nach dem Internen 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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.