www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Frage zu Ressourcen (Grafkdisplay 240x128)


Autor: Robert (Gast)
Datum:

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

Autor: Michael U. (Gast)
Datum:

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

Autor: Robert (Gast)
Datum:

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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

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

Autor: Hannes Lux (hannes)
Datum:

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

...

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider finde ich nirgens nen Anschlußplan / AppNote dazu (das Init muß 
ja auch erstmal durchgeführt werden)

Autor: Michael U. (Gast)
Datum:
Angehängte Dateien:

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


Autor: Fritz (Gast)
Datum:

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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Michael werd ich bei Gelegeheit mal austesten!

Autor: Michael U. (Gast)
Datum:

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

Autor: Fritz (Gast)
Datum:

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

Autor: Michael U. (Gast)
Datum:

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

Autor: Fritz (Gast)
Datum:

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

Autor: Robert (Gast)
Datum:

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



Autor: Michael U. (Gast)
Datum:

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





Autor: Michael U. (Gast)
Datum:

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

Autor: Robert (Gast)
Datum:

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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

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

Autor: Hannes Lux (hannes)
Datum:

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

...

Autor: Robert (Gast)
Datum:

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

Autor: Hannes Lux (hannes)
Datum:

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

...

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Recht, die Hab ich ganz vergessen. Halt nach dem Berech nach dem 
Internen SRAM.

Autor: Michael U. (Gast)
Datum:

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

Autor: Robert (Gast)
Datum:

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

Autor: Michael U. (Gast)
Datum:

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

Autor: Robert (Gast)
Datum:

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

Autor: Michael U. (Gast)
Datum:

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

Autor: Oliver (Gast)
Datum:

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

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.