Forum: FPGA, VHDL & Co. Interface für Character-LCD Modul


von Andreas G. (andy1988)


Lesenswert?

Hallo,
ich habe mir diese Woche ein Spartan 3AN Board gekauft, um mal ein wenig 
mit FPGAs zu spielen. Bisher hab ich einige Howtos, die man im Netz 
verstreut findet durchgearbeitet, um mal ein wenig in die Thematik zu 
kommen.

Mit diesen Howtos habe ich grade das Character LCD auf dem Board zum 
laufen bekommen, was jetzt über eine State Machine definierten Text 
ausgeben kann.
Alle Howtos, die man dazu findet, benutzen aber Statemachines die die 
einzelnen Zeichen durch extra Zustände behandeln.
Das heisst nach der Initialisierungssequenz ist der nächste Zustand 
dafür Zuständig ein 'H' auszugeben, dann ein 'l', nochmal ein 'l' usw. 
bis das Wort "Hallo" zu sehen ist und dann ist Schluss. Das ganze 
funktioniert wunderbar.

Ich möchte das ganze aber als VHDL Modul haben, dass ich dann 
instanzieren kann, um es später wieder verwenden zu können.
Dazu brauche ich dann allerdings irgendwie eine Schnittstelle, über die 
ich dann Daten an das Modul sende, die dann darin verarbeitet werden.
Wie genau macht man sowas?

Ich dachte an einen FIFO-Buffer über ein RAM, welches ein Byte 
Steuerinformationen enthält und danch eventuelle Daten, die auf dem 
Display angezeigt werden sollen. Ich fülle also diesen FIFO-Buffer und 
ziehe an einer Enable Leitung der Instanz. Diese kümmert sich dann um 
die Kommunikation mit dem Display und leert dabei logischerweise 
sukzessive den Buffer.

Ich frage mich allerdings, ob das so überhaupt Sinn macht. Das einzige, 
was das Display-Modul dann nämlich macht ist ja eigentlich die Daten von 
einem RAM in ein anderes zu schieben und Befehle so zu übersetzen, dass 
das Display sie versteht. Also kann ichs ja auch gleich wieder 
weglassen.
Eine andere Lösung dazu ist mir bisher allerdings auch noch nicht 
eingefallen.

Wie macht man sowas also im Normalfall?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> Wie macht man sowas also im Normalfall?
Ich würde das so machen, wie ich es auf uC auch mache:
es gibt ein Modul, das aus einem uC-RAM-Bereich das Display dauernd 
zyklisch updatet (z.B. jeweils nach 5 ms ein Zeichen, das wäre für ein 
2x16 Display dann 160ms Updaterate)
Und es gibt irgendwelche Programmteile, die in den uC-RAM-Bereich den 
gewünschten Displayinhalt schreiben.

So sind meine Programme weitestgehend von der realen Hardware "Display" 
abgekoppelt. Das wurde schon bei den ersten PCs so gemacht (Video-RAM).

von Iulius (Gast)


Lesenswert?

Kommt immer drauf an wie viele Daten du speichern willst und wie sie 
erzeugt werden

Lothars Methode funktioniert z.b. sehr gut wenn du mit einem Softcore 
arbeitest und eine Art zentralen Speicher hast.



Ich weiß grad nicht wie genau das Display auf dem eval board von dir 
arbeitet, aber andere möglichkeiten wären noch :

- lokaler speicher (FF/LUT-Ram) der von außen adressiert werden kann 
(etwa oberhalb des üblichen ram). So spart man sich den zusätzlichen 
requester am zentralen ram. Ich benutze sowas gerne um überflüssiges 
routing quer durch das ganze FPGA (von den display-pins zum ram) zu 
vermeiden.


- display speicher : falls da ein zusätzlicher controller das display 
ansteuert dann hast du warscheinlich die möglichkeit den inhalt 
zurückzulesen und insbesondere nur einzelne zeichen neu zu übertragen 
ohne "aufwändige" Logik im FPGA dafür zu erzeugen.
Das entspricht dann in etwa deinem FIFO Ansatz.


Zu beachten sind also wie immer die Umgebung und die Anforderungen.

von Andreas G. (andy1988)


Lesenswert?

Danke für eure Tipps.

> Ich weiß grad nicht wie genau das Display auf dem eval board von dir
> arbeitet [...]
Auf dem Board ist so ein 2x16 Zeichen Character LCD mit HD44780 
kompatiblem Displaycontroller.

> - lokaler speicher (FF/LUT-Ram) der von außen adressiert werden kann
> (etwa oberhalb des üblichen ram). So spart man sich den zusätzlichen
> requester am zentralen ram. Ich benutze sowas gerne um überflüssiges
> routing quer durch das ganze FPGA (von den display-pins zum ram) zu
> vermeiden.
Ich habe noch überhaupt keinen RAM. Der fiese DDR2-Chip ist mir momentan 
auch noch etwas zu hoch. Da reden wir dann in ein bis zwei Wochen noch 
mal drüber ;)

> - display speicher : falls da ein zusätzlicher controller das display
> ansteuert dann hast du warscheinlich die möglichkeit den inhalt
> zurückzulesen und insbesondere nur einzelne zeichen neu zu übertragen
> ohne "aufwändige" Logik im FPGA dafür zu erzeugen.
> Das entspricht dann in etwa deinem FIFO Ansatz.
Wie gesagt: Das Display hat einen eigenen Controller. Ich werd in das 
FIFO Befehle und eventuelle Operanden schieben. Was der Aufrufer dann 
will, schiebt er da rein, zieht ein STROBE Signal nach oben und das 
ganze Timing-Geraffel wird dann von meinem Modul erledigt. Irgendwann 
geht dann auch ein BUSY-Signal wieder auf Low und man kann getrost 
wieder in der FIFO rummatschen.
Klappt bei nem LPT-Port schließlich auch so ;)

> Zu beachten sind also wie immer die Umgebung und die Anforderungen.
Sagen wir mal so: Noch hab ich gar keine Anforderungen, ausser die 
Möglichkeit Text etwas dynamischer auf dieses Display zu bekommen, um 
dadurch einigermaßen VHDL und den Umgang mit FPGAs zu lernen ;)
Irgendwann wird es wohl mal darauf hinauslaufen, dass ich das LCD mal 
von einem Softcore aus anspreche, aber das dauert noch ein wenig.



Nach etwas Googlen habe ich ein Übungsblatt der Uni Potsdam gefunden: 
http://www.cs.uni-potsdam.de/techinf/lehre/SS08/SoC/ue/uebung2.pdf
Ich probiere mich grade an dem FIFO-Buffer und werde den dann mal ans 
LCD schrauben.

Spätestens, wenn ich das Display fertig habe und mal was per VGA 
ausgeben will, werde ich dann mal etwas Video RAM springen lassen. ;)

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> Ich probiere mich grade an dem FIFO-Buffer...
Wie gesagt: meines Erachtens der falsche Weg. Damit mußt du in allen SM, 
die was von dem Display wollen, eine Wartemimik einbauen. Das wäre etwa 
das Konzept:
1
          _________      _____________________
2
  D   ---|         |--D-| Display Controller  |
3
         | DP-RAM  |    | gibt jeweils nach   |--- Display
4
  A   ---|         |--A-|_5ms_ein_Zeichen_aus_|
5
         | 32Bytes |
6
  Wr  ---|_________|-- Rd='1'

Damit wäre z.B. der Anschluss eines anderen Displays ganz einfach 
möglich, indem "nur" der Display-Controller angepasst wird. Das 
Interface zur Applikation hin bleibt das selbe.

> Klappt bei nem LPT-Port schließlich auch so ;)
Da hängt allerdings auch ein PC mit Interupts und Pipapo mit dran... :-o

von Iulius (Gast)


Lesenswert?

Der controller wäre ja auch beim fifo interface austauschbar :
einfach eine Adresse und das Zeichen definieren das geschrieben werden 
soll und den Rest erledigt das Modul.


>> Damit mußt du in allen SM,
>> die was von dem Display wollen, eine Wartemimik einbauen.

und ansonsten musst du eine Verteilung der Ressource Ram vornehmen was 
aufs gleiche hinaus läuft.


Deswegen macht es ja auch einen riesen Unterschied ob man jetzt einfach 
nur die Zeichen/Befehle z.b. von einer Uart zugeschoben bekommt oder ggf 
ein multisoftcoresystem auf das display zugreifen will.



>> Ich habe noch überhaupt keinen RAM

dein Spartan hat intern Ram verbaut und zwar garnicht mal so wenig, 
zumindest für diese Anwendung hier.

Der ist auch viel leichter anzusprechen als der DDR2 ;)

von Ralf (Gast)


Lesenswert?

Hallo,

Ich habe ebenfalls ein Spartan 3AN-Board. Ich finde
den Ansatz von Lothar Miller am besten. Eventuell
könntest du den doppelten Speicher (Blockram) für
das Anzeigemodul reseverien, also 64 Byte, jeweils
ein Byte für das Charakterzeichen und ein Byte für
das Attribute (unterstichen, blinkend oder ähnlich).
Das hat den Vorteil daß du komplett unabhangig von
eigentliche Timing bist. Deine Applikation
schreibt einfach die Zeichen in den Blockram, der
Rest macht dann die Anzeige-Block.


Gruß

Ralf


ps: Mich würde interessieren, wenn du zum DDR2-Speicher
kommst. Den versuche ich nähmlich ebenfalls in Betrieb
zu nehmen. Den Logikteil habe ich zwar schon, es scheitert
aber leider am Timing.

von Andreas G. (andy1988)


Lesenswert?

Lothar Miller schrieb:
> Wie gesagt: meines Erachtens der falsche Weg. Damit mußt du in allen SM,
> die was von dem Display wollen, eine Wartemimik einbauen
Hast recht. Ist doch uncool. Eben wegen dem Warten. Mit der Lösung des 
Grafikrams wäre das ganze transparent. $stuff reinpumpen und gut ists.

Iulius schrieb:
>>> Ich habe noch überhaupt keinen RAM
>
> dein Spartan hat intern Ram verbaut und zwar garnicht mal so wenig,
> zumindest für diese Anwendung hier.
>
> Der ist auch viel leichter anzusprechen als der DDR2 ;)
Und genau dazu habe ich mir mal ne Application Note besorgt: 
http://www.xilinx.com/support/documentation/application_notes/xapp463.pdf
Großer Spaß! Simuliert auch schon. Ich werd das ganze dann mal 
verdrahten und testen.

Ralf schrieb:
> ps: Mich würde interessieren, wenn du zum DDR2-Speicher
> kommst. Den versuche ich nähmlich ebenfalls in Betrieb
> zu nehmen. Den Logikteil habe ich zwar schon, es scheitert
> aber leider am Timing.
So weit bin ich noch nicht. Ich wollte erstmal mit dem Display, PS/2, 
Drehgeber und VGA rumspielen. Das sind alles recht einfache Sachen, die 
ich schonmal mit nem AVR zusammengeschraubt habe oder, im Falle von VGA, 
verstehe, wie das Zeug funktioniert. Sich als blutiger Anfänger mit 
einer unbekannten Technologie auf einer neuen Plattform zurechtzufinden 
kann mitunter extrem frustrierend sein ;)

Aber zum DDR2 Geraffel gibts auch ne Application Note:
http://www.xilinx.com/support/documentation/application_notes/xapp458.pdf

Vielleicht hilft es dir ja in irgendeiner Weise weiter.

Bitte 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
Noch kein Account? Hier anmelden.