Hallo, hab ja schon entdeckt hier so einige das 7€-Pollin-Display mit einem Atmel Chip ansteuern und das wohl recht gut geht. Ich wollte das nun mit dem Pollin CPLD tun und stoße dabei auf ziemliche Probleme. Der Code befindet sich im Anhang. Bitte nicht vom Namen irritieren lassen ;) Jedenfalls scheint sich irgentwas zu tun : - nach Modus select und den display/cursor high/low initialisierungen blinkt das display komplett schwarz. danach sollten eigentlich immer zeichen ausgegeben werden, das passiert jedoch nicht, der bildschirm bleibt leer. nach dem ausschalten sieht man manchmal den textmodus mit wirren zeichen. Takte/verzögerungen habe ich mitlerweile schon einige durchprobiert, lediglich das auslesen des busy states noch nicht, was andere in der realisierung für den atmel aber auch nicht getan haben... pins sollten auch stimmen... weiß halt einfach nicht wo ich weiter machen kann. Vielleicht hat ja jemand eine Idee wo der Fehler liegen könnte. Hier noch das Datasheet vom Controller : http://www.lcd-module.de/eng/pdf/zubehoer/hd61830.pdf
ich musste gerade feststellen das eigentlich keiner der Pins bis auf die nummer 18 zum Ausschalten die richtige Funktion aufweist. Irgentwie lassen alle das Display nur flackern. Blöde Frage : kann es daran liegen das das Display 5V für die Signale braucht, der cpld aber nur 3,3V liefert ? im datenblatt steht : V-ih (input high ?) : (0,7->1.0)*vdd bei 5V VDD wäre das 3,5V und somit leicht über dem was der cpld liefert... leider ist mir das bis eben nicht aufgefallen, aber ich bin mir auch nicht sicher das dies der Grund ist. Falls ja, gibts da irgenteine lösung ?
> bei 5V VDD wäre das 3,5V Das ist knapp, sollte aber bei zimmertemperatur noch funktionieren... > aber ich bin mir auch nicht sicher das dies der Grund ist. Sieh dir mal das Timimg von RS und ENABLE genauer an... RS sollte vor und nach einem Wechsel von ENABLE stabil anstehen. Ich bin nicht sicher, ob dein Code das macht... Hast du den schon mal simuliert und das Timing angeschaut? BTW: Einen Zähler machst du am einfachsten mit einem integer, dann wird das für Menschen leichter lesbar:
1 | SIGNAL counter : integer range 0 to 10000000 := 0; |
2 | :
|
3 | zaehler: process(clk) |
4 | BEGIN
|
5 | IF RISING_EDGE(clk) THEN |
6 | if counter<10000000 then |
7 | counter <= counter + 1; |
8 | else
|
9 | counter <= 0; |
10 | end if; |
11 | END IF; |
12 | end process zaehler; |
13 | :
|
14 | if counter=0 then |
PS:
1 | init: process(clk,counter,status) |
2 | begin
|
3 | IF RISING_EDGE(clk) THEN |
In diesem Prozess ist nur der clk interessant, weil nur eine Änderung von clk den Prozess neu berechnen muss. Korrekt wäre also das:
1 | init: process(clk) |
2 | begin
|
3 | IF RISING_EDGE(clk) THEN |
Danke schonmal für die Antwort, dann habe ich erstmal noch Hoffnung :) Das Timing ist erstmal garnicht das Problem, vermute ich zumindest, hab das ganze auch schon seehr langsam laufen lassen, also das alle werte über viele ms stabil waren. Mir macht eher sorgen das bis auf "dis_off" keiner der pins die richtige funktion zeigt, die verschaltung aber stimmt (hab nachgemessen) insbesondere das bei ALLEN pins (bis auf dis_off) das display nur flackert, aber auch nicht immer. wegen den tipps : ich nutzte erst seit dem erwerb des pollin boards vor ein paar tagen vhdl, vorher nur verilog. Man möge es mir verzeihen :)
Bin jedes Pins von vorne bis hinten auf high/low durch und die einzige reaktion ist das flackern aller pixel bzw die art das flackern nach dem abschalten desc pld. scheinbar ist es mir sogar möglich zwischen character-modus und graphic-modus umzuschalten, zumindest ändert sich danach sporadisch die aufgabe von wirren zeichen auf wirre linien, alles aber erst nach dem abschalten des cpld. Daraus schließe ich das die belegung prinzipiell richtig ist und auch manchmal die richtige reaktion hervorruft, scheinbar aber nicht stabil. Das Display fliegt demnach erstmal in eine Kiste. Vielleicht krame ich es mal wieder hervor wenn ich über nen günstigen Atmel stolpere. Trotzdem nochmal danke für die Tipps.
Iulius schrieb: > Daraus schließe ich das die belegung prinzipiell richtig ist und auch > manchmal die richtige reaktion hervorruft, scheinbar aber nicht stabil. Das Display hat doch keine "pins" wo sich dan zufällig was tut, sondern du mußt dem Schon korrekte Komandos senden > Das Display fliegt demnach erstmal in eine Kiste. Vielleicht krame ich > es mal wieder hervor wenn ich über nen günstigen Atmel stolpere. Wie günstig muß er den sein laut Datenblatt des Controllers hat der doch einen Simplen 8bit Datenbus da tut es auch ein Mega88 für < 2€ oder was ist das besondere an dem Display? Ansteuerung mit einem CPLD macht aber nun wirklich garkeinen Sinn.
Geht ja nicht darum das Display auf Teufel komm raus in Betrieb zu nehmen sondern eher dem CPLD eine Möglichkeit der Anzeige zu geben, 8 LEDs sind da ziemlich mager und über uart wie bisher auch nicht so das Wahre. Die sache ist aber auch das mich atmels eigentlich nicht wirklich interessieren. Ist halt sequentiell und assembler, oder noch schlimmer c und gerade davon will ich ja abstand haben (muss schon so genug mit c/c++ arbeiten) wegen dem display : ja das sollte schon eine konkrete belegung sein, aber wenn egal wie die belegung ist einfach nur das bild flackert ? zumindest bei dauerreset müsste er sich anders verhalten als bei nicht dauerreset. oder bei rs und rw auf 1, wo nur vom display gelesen wird, dürfte garkeine reaktion am bild kommen. auch chip enable ist dem völlig egal, er reagiert immer egal ob dort 1 oder 0 liegt. da chip enable low aktiv ist schließe ich daraus das ich nicht dauerhaft high anlegen kann. Kann mMn eigentlich nur zu wenig Spannung oder ein Defekt sein.
Angehängte Dateien:
-
RS-Timing-verletzt.gif
7,2 KB
> Das Timing ist erstmal garnicht das Problem
Du kannst die Signale so langsam wie du willst umschalten. Wenn du aber
ENABLE und RS gleichzeitig umschaltest, ist das Timing verletzt. Siehe
die steigende Flanke von ENABLE in der Waveform.
Das Datenblatt fordert auf Seite 1329 eine Setup-Zeit tAB von mindestens
140ns.
Iulius schrieb: > Geht ja nicht darum das Display auf Teufel komm raus in Betrieb zu > nehmen sondern eher dem CPLD eine Möglichkeit der Anzeige zu geben, 8 > LEDs sind da ziemlich mager und über uart wie bisher auch nicht so das > Wahre. Was möchtest du den auf dem Display anzeigen? Der CPLD ist doch garnicht so groß als das man da sinnvoll ein Grafik LCD mit füllen könnten. Es ibt ja auch noch 7seg Anzeigen z.B. die man recht einfach an nen CPLD ranhängen kann. > Die sache ist aber auch das mich atmels eigentlich nicht wirklich > interessieren. Naja gut es gibt noch andere Controller ;) > Ist halt sequentiell und assembler, oder noch schlimmer c und gerade > davon will ich ja abstand haben (muss schon so genug mit c/c++ arbeiten) Okay aber auch im CPLD wirst du erstmal sequentiell die Inistialisierung durchlaufen müssen und dann sequentiell Daten hinsenden sonst zeigt es nicht sinnvolles an. > wegen dem display : ja das sollte schon eine konkrete belegung sein, Sollte? Im Datenblatt von Pollin steht doch die Belegung. Wie genau hast du das den verdrahtet? > aber wenn egal wie die belegung ist einfach nur das bild flackert ? > zumindest bei dauerreset müsste er sich anders verhalten als bei nicht > dauerreset. Nö, das sezt idR nur den Displaycontroller zurück der RAM oder ähnliches wird nicht beeinflußt, Dauerreset sollte man aber auch nicht machen. > auch chip enable ist dem völlig egal, er reagiert immer egal ob dort 1 > oder 0 liegt. Was heißt den reagieren? Ohne vernünftige Initialisierung ist das Verhalten eher zufällig... > da chip enable low aktiv ist schließe ich daraus das ich nicht dauerhaft > high anlegen kann. Wenn es da Probleme gibt hast du einen verdrahtungsfehler, CE = High bedeutet nur das der Chip nicht auf Befehle reagiert und der Datenbus auf HIGH-Z ist, da darf man also getrost HIGH und LOW anlegen solange man will. > Kann mMn eigentlich nur zu wenig Spannung oder ein Defekt sein. Ich vermute eher verdrahtungs oder verständnis Fehler, ein LCD Controller ist keine LED wo es nur an/aus gibt sondern da ist einfach nen uC drinn und wenn der falsche oder garkeine Befehle kriegt verhält er sich halt u. U. seltsam. Auch wenn du AVRs nicht "magst" aus welchem Grund auch immer empfehle ich dir das Display erstmal mit nem uC in Betrieb zu nehmen und zu versuchen es dann auf den CPLD zu transformieren. Ich wrde auch einfach mal behaupten das dein CPLD viel zu schnell ist für das Display.
Hier http://bascom-forum.de/index.php?topic=2469.0 Steht das das Display nach dem Anschalten angeblich flimmern soll + ein paar Links die dir vieleicht weiterhelfen.
ich hab schon alle sources in c/asm durchgesehen die ich im netz finde konnte und anhand dessen auch meinen code aufgebaut. die pins sind alle korrekt verkabelt, hab das ausgemessen am board, es stimmt. enable und rs hab ich auch schon unabhängig gemacht, das ändert garnichts. allgemein ändert die high/low belegung der pins nichts, das flackern ist immer gleich, selbst wenn ich alle outputs fix mache. Bis auf den Display_off pin halt, der schafft es wirklich das display auszuschalten. dann aber wieder macht es trotzdem manchmal das richtige (z.b. den grafikmodus wechseln) Da die Schaltung aber deterministisch ist... kann höchstens mal noch mit echten 5v testen wie es an reset usw reagiert, vermute aber das die reaktion wohl kaum = 0 ist. Das wäre doch witzlos - alle 4-5 versuche wird der grafikmodus einwandfrei gewechselt, sonst nicht - flackern tut es die ganze zeit - chip_select/reset/enable ist der pegal egal, der moduswechsel funktioniert unabhängig von deren belegung manchmal. spätestens bei chip_select auf inaktiv dürfte das doch nicht mehr sein. scheinbar kann der inaktiv pegel (high) aber nicht erreicht werden. oder auch beim reset : low = reset -> wenn nie stabil high erreicht werden kann, dann kommt eben ständig ein reset. Das macht für mich einwandfrei Sinn. Das reset/enable/chip_select usw alle egal sein sollen für die initialisierung halte ich hingegen für unwarscheinlich. >> Was möchtest du den auf dem Display anzeigen? Der CPLD ist doch garnicht >>so groß als das man da sinnvoll ein Grafik LCD mit füllen könnten. warum das denn ? Da passt problemlos z.b. ein kleines Spiel rein oder man zeigt die Daten an die über die uart kommen oder eben ein kleiner 8bit prozessor usw. 144 makrozelle wovon höchstens 40 fürs display wegfallen, da ist schon noch einiges an platz. Zumal ich dann die 8 leds abschalten könnte, wodurch der mehrverbrauch noch geringer ist. taktcounter kann man sich mit der uart teilen, etc. Das mag blöd klingen, aber viele Funktion auf kleinen Chip zu bekommen, da habe ich mehr Freude dran als Assembler/C Code für einen fertigen Chip zu schreiben. Und ansonsten hab ich immernoch meinen großen FPGA(leider auch 3,3V max) der sich auch über ein display freuen würde wenn mal grad kein Monitor in der Nähe ist.
> Da passt problemlos z.b. ein kleines Spiel rein oder man zeigt die Daten > an die über die uart kommen oder eben ein kleiner 8bit prozessor usw. Dass wir uns da mal nicht täuschen :-o Jedes einzelne Zeichen, das du ausgeben willst, muß irgendwie gespeichert werden. Und das geht nur über Register und die Produktterme. Also bist du schneller am Ende der Fahnenstange, als dir (derzeit) bewusst ist. > 144 makrozelle wovon höchstens 40 fürs display wegfallen, da ist schon > noch einiges an platz. Da hast du gerade mal noch 100 FFs über, das ist gelinde gesagt "wenig"... > enable und rs hab ich auch schon unabhängig gemacht, das ändert > garnichts. Hast du das Simuliert, oder rätst du im Trüben? > Und ansonsten hab ich immernoch meinen großen FPGA(leider auch 3,3V max) > der sich auch über ein display freuen würde wenn mal grad kein Monitor > in der Nähe ist. Dann steuert sich das FPGA das Display selber an. Auf dem Ding sind wesentlich mehr Ressourcen als auf einem CPLD... BTW: meinen großen FPGA --> mein großes FPGA
Ein Display mit eigenem Controller mit einem CPLD anzusteuern halte ich auch für etwas sinnlos, denn alleine schon die Statemachine für die Init ist ziemlich aufwendig wie du gerade merkst, und da sind noch keine Daten auf dem Display. Besser ist daher ein controllerloses Display wie die 320x240 Teile die es auch günstig bei Pollin gibt. Man benötigt dann nur noch 9600 Bytes RAM, aber das hat das Pollinboard. Die dazu notwendige Datenrate von rund 700kByte/s ist für einen CPLD auch lächerlich gering, so dass noch ausreichend Speicherbandbreite für andere Sachen zur Verfügung steht. Zur Ansteuerung benötigt man nur noch 2-3 Zähler anhand denen man die Syncsignale und Speicheradressen ableitet und man muss die Bytes noch in 2 Nibble aufspalten. Im Vergleich zu der Statemachine die den LC7981 ansteuert aber sehr einfach.
Naja man könnte die Statemaschine auch im SRAM ablegen... aber wie gesagt die 144 Makrozellen sind schneller voll als einem lieb ist. > flackern tut es die ganze zeit Nochmal das wird vermutlich ewig Flackern egal welche Zustände (außer Reset) du an den Pins hast solange das Ding nicht ordentlich initialisiert ist. Dann passieren halt merkwürdige Sachen, das hatte ich bei meinem Grafik LCD auch weil ich den Reset nur mit nem Pullup versehen hatte und nicht mit RC Kombination. > chip_select/reset/enable ist der pegal egal, der moduswechsel > funktioniert unabhängig von deren belegung manchmal Der Controller verhält sich nur undefiniert wenn er ohne Reset/Init irgenwas an den Datenleitungen erhält wo auch noch Setup/Hold Zeit verlezt wird. > scheinbar kann der inaktiv pegel (high) aber nicht erreicht werden Du kannst Pullups auf 5V vorsehen, der CPLD ist 5V tollerant an den IOs. > Das mag blöd klingen, aber viele Funktion auf kleinen Chip zu bekommen, > da habe ich mehr Freude dran als Assembler/C Code für einen fertigen Ist ja okay ich hab auch gerade für nen 72 Macrozellen FPGA nen Design entworfen für einen LA Vorsatz das war auch mal eine nette Sache und da mußte ich auch quetschen was das Zeug hält, aber hier wirst du nachher nur das LCD ansteuern könne und das wars weil dan einfach nix mehr in den CPLD reinpasst. > Und ansonsten hab ich immernoch meinen großen FPGA(leider auch 3,3V max) Da brauchst du dann aber unbedingt Pegelwanler, der FPGA wirs vermutlich nicht mögen wenn er 5V abbekommt.
>>Nochmal das wird vermutlich ewig Flackern egal welche Zustände (außer >>Reset) du an den Pins hast solange das Ding nicht ordentlich >>initialisiert ist Nein, wenn ich den cpld ausschalte oder das kabel abziehe flackert es nicht mehr, dann ist der effekt ein anderer (z.b. steifen im grafikmodus oder wirre zeichen im textmodus. das flackern kommt nur wenn der cpld dran ist, wie gesagt egal was an den pins liegt. Dennoch ist er nicht völlig unempfänglich, sonst würde ja der Moduswechsel nicht funktionieren. Oder auch das ausschalten über den befehl, das geht manchmal und manchmal nicht. >> Jedes einzelne Zeichen, das du ausgeben willst, muß irgendwie gespeichert werden richtig, dafür gibts den sram. >> Hast du das Simuliert, oder rätst du im Trüben? hab das enable als weiteren zähler entworfen und immer den enable ausgang auf "01" bzw "10" umgeschalten(erst high dann low) während rs auf "00" umschaltet. simuliert hab ichs aber nicht, sondern direkt auf die leds gelegt. Kanns ja nochmal in der Simulation laufen lassen. >> Besser ist daher ein controllerloses Display wie die 320x240 Teile die >> es auch günstig bei Pollin gibt Ich weiß welches du meinst, aber mich schreckt die Beschreibung dabei doch sehr ab. Die Schaltbilder dort sind schon sehr aufwendig für meine Verhältnisse und soviel Equippment/Lötfertigkeiten habe ich nicht. Wenn ich einfach nur die Pins aufs board legen müsste, ok. Aber noch ~20V zur vergügung stellen und Dioden vor die Ausgänge, haufenweise Widerstände usw, das übersteigt meine Fähigkeiten, muss ich offen zugeben. Das ansprechen selbst wäre natürlich viel angenehmer. Eine VGA Ansteuerung habe ich auch hinbekommen, da wäre das nicht sonderlich schwerer. Aber ohne einen brauchbaren Anschluss/Stromversorgung muss ich da passen. Bei mir ist nicht viel mit Elektrotechnik-Fertigkeiten. Alles was über definierte H/L Zustände hinausgeht, da bin ich überfordert. >> Du kannst Pullups auf 5V vorsehen, der CPLD ist 5V tollerant an den IOs. tut mir leid, damit kann ich nicht viel anfangen. meinst du damit 5V über nen widerstand auf die pins geben (z.b. von unter dem board) ?
Iulius schrieb: > meinst du damit 5V über nen widerstand auf die pins geben (z.b. von > unter dem board)? Eine Seite des Widerstandes (etwa 10k Ohm) an die 5V Versorgung des Boardes das andere Ende an den Pin (z.B. RS). An RESET des Displays würd ich noch nen Kondesator so ~1µF dranhängen. > das flackern kommt nur wenn der cpld dran ist, wie gesagt egal was an > den pins liegt. Ich würde sicherstellen das du den RW Pin auf jedenfall mit nem Pullup versiehst wie oben beschrieben. Hast du schonmal das SRAM benuzt? Schreiben und Lesen?
>> Hast du schonmal das SRAM benuzt? Schreiben und Lesen?
ja das funktioniert wunderbar, warum ?
wegen dem pull-up :
wie funktioniert das dann ?
wenn ich auf 1 schalte liegen 5V an und sonst nichts ?
Oder andersrum ?
kann mir das irgentwie nicht so richtig vorstellen.
Und kann ich alle 14 pins bedenkenlos an den spannungswandler des boards
hängen ?
Iulius schrieb: >>> Hast du schonmal das SRAM benuzt? Schreiben und Lesen? > > ja das funktioniert wunderbar, warum? Das Display funktioniert im Prinzip wie das SRAM mit dem unterschied das es noch das Registerselect gibt, sosnt hättest deine Code erstmal damit testen können. > wegen dem pull-up : > > wie funktioniert das dann ? > > wenn ich auf 1 schalte liegen 5V an und sonst nichts ? > Oder andersrum ? Du steuerst deine Pins dann ganz normal an der Pullup ist zusätzlich. Wenn der Pin auf GND geht wird sich auch nahezu GND einstellen da der Strom sich den Weg des geringsten Widerstandes sucht. Wenn du ne '1' Ausgibst (3,3V) oder besser ein 'Z' wird der Pullup dafür sorgen das der Pegel auf 5V ansteigt. Normalerweise würde jezt der Strom über die Schutzdioden abfließen, da der CPLD aber 5V kompatibel ist wird statdessen nahezu 5V an dem Pin erscheinen. > Und kann ich alle 14 pins bedenkenlos an den spannungswandler > des boards hängen ? Worst-Case solte sein wenn du den Pin auf GND legst dan fliest ein Strom von I = 5V/R das mit 14 Multiplizieren und schauen ob der Spannungsregler das packt. Da du aber im normalfall eh nie alle Pins statisch auf GND legst geht sogar noch etwas mehr. http://www.rn-wissen.de/index.php/Pullup_Pulldown_Widerstand Der uC pin ist dein Display, der CPLD ist der "Schalter"
ok, dann muss ich erstmal widerstände zusammensuchen. wie ich das display anspreche bin ich mir schon bewusst, bis auf den kleinen fehler im code oben mit rs und enable sollte das auch klar werden, denn der rest scheint wohl zu stimmen. (zumindest wurde nichts anderes in sachen funktionalität bemängelt) gibts eigentlich auch eine möglichkeit die widerstände nicht an das board sondern an das display anzubringen ? hab das display an einem seperaten netzteil das 5V 150mA liefert( + widerstand vor dem pin2) damit ich es unabhängig vom cpld nutzen kann. Da könnte ich doch auch von diesem netzteil abgreifen und auf die pins des display gehen, oder ? Achja, vielleicht noch eine letzte Frage : müssen es 10k widerstände sein ? oder gehts auch niedriger/höher ?
Du kannst auch die 5V vom Display nemen, GND beider Schaltungen muß aber verbunden sein, sosnt geht garnix. Widerstände könnne im Bereich 1k-100k variiert werden aber irgenwas in der Gegend von 10k ist ganz brauchbar ggf mußt du mit der Geschwindigkeit runtergehen. Noch eine Sache wie schnell wird der CPLD getaktet? Weil der Displaykontroller nur etwa 1-2 Mhz verdauen kann wenn ich das im Datenblatt richtig verstehe.
Auf die Pullups kannst du eigentlich verzichten, das Display ist TTL kompatibel, alles ab 2,2V wird also als high erkannt. 3,3V reicht also bei weitem aus.
hab beim takt schon alles probiert von 1hz bis 1mhz(16mhz -> teiler 16) hoch. hat sich aber nix verändert. >> das Display ist TTL >>kompatibel, alles ab 2,2V wird also als high erkannt. 3,3V reicht also >>bei weitem aus. laut datenblatt ist das nicht so : minimum 0,7*VDD. Aber du scheinst von den displays ja auch eine menge zu besitzen, deswegen weiß ich nun nicht was stimmt. ich werde das mit 5V morgen jedenfalls mal testen bezüglich der reset/enable eingänge usw im vergleich zu 3,3v. wenn sich was verändert, dann probiere ich es mit 14 * pull-up. Wenn nicht gebe ich auf, denn dann kann ich es mir nicht mehr erklären. Eine reaktion unabhängig von chip_select macht einfach keinen Sinn. mit fehlendem chip_select(also dauerhaft inaktiv) dürfte auch kein moduswechsel möglich sein, aber das Gegenteil ist der Fall. Das ist für mich derzeit das K.O.-Kriterium. Falsche pinbelegung ist ausgeschlossen, der wert liegt auch am entsprechenden displaypin an und egal ob high(3,3v) oder low, es ist immer empfänglich für Befehle. Das heißt für mich das a) entweder inaktiv (high) nicht einwandfrei erkannt wird b) irgentwas anderes kaputt ist. Fall a) werde ich morgen testen. Wenn jemand eine andere Idee hat bin ich gerne offen dafür. Ich wüsste jedoch nicht was das sonst auslösen könnte. Falsche belegungen an den anderen pins sind zwar theoretisch möglich(wobei sich dann fragt warum das Modusumschalten manchmal funktioniert), würden aber nicht die Funktion vom chip_select beeinträchtigen. Weiß auch nicht woran ich mich sonst im Moment halten sollte.
Iulius schrieb: > laut datenblatt ist das nicht so : minimum 0,7*VDD. > > Aber du scheinst von den displays ja auch eine menge zu besitzen, > deswegen weiß ich nun nicht was stimmt. Ich gehe immer vom Datenblatt des LCD Controllers (also in dem Fall vom LC7981) aus. Das sagt Low: max 0,8V, high: min 2,2V. Datenblätter von LCDs sind nämlich, was die Infos rund um den LCD Controller angeht nicht selten recht ungenau, unvollständig bis falsch. Erst recht wenn das Datenblatt von Pollin oder von sonst wo, nicht vom originalen Hersteller stammt. Ich habe auch schon solche Displays an einem 3,3V µC betrieben, das ging problemlos. Reset kannst du fest auf 5V, RW fest auf GND anschließen. Damit hast du 2 Leitungen und somit 2 Fehlerquellen weniger.
Hmm, schade, das wäre eigentlich meine letzte Hoffnung gewesen. reset und rw hab ich ja schon so gesetzt (siehe dem code). und wie gesagt, liegt alles genau so am display wie es oben eingetragen ist, also die pins stimmen. Wie gesagt, das chip_select macht mir zu schaffen. Solange das nicht einwandfrei abschalten kann tippe ich auf ein Problem außerhalb des vhdl codes, wo auch immer das liegen mag.
Leg doch den ChipSelect mal auf 5V und meß gegen die Datenpins. Sowohl gegen GND als auch gegen 5V darf kein nierohmiger Durchgang sein.
Angehängte Dateien:
-
display.jpg
250 KB
(sorry für das schwammige bild, handykamera+spiegeldisplay...) Es läuft ! Wenn ich jetzt sage woran es lag, naja warscheinlich wäre jeder hier vor mir drauf gekommen. Die Ursache : das verwendete "5V" netzteil lieferte satte 4,3V sobald das display eingeschaltet wurde. Jetzt hängt es direkt am Pollin-board und läuft einwandfrei. Danke nochmal an alle die mitgeholfen haben für die viele Geduld. Und noch ein großes Dankeschön an Lothar Miller. Ohne den Tipp der Abhängigkeit von rs und enable hätte ich warscheinlich heute wieder den code aus dem Eingangspost verwendet und wäre gescheitert. Falls jemand auch diese Kombination aus pollin board und display aufbauen will kann ich gerne das gesamte projekt inklusive uart und software zum übertragen zur verfügung stellen damit man die init routine nicht in hardware abbilden muss.
> Die Ursache : das verwendete "5V" netzteil lieferte satte 4,3V sobald > das display eingeschaltet wurde. Und vermutlich mit saftigem Brumm (3,6-5,0V = Mittelwert 4,3V) ... > das gesamte projekt inklusive uart und software zum übertragen Pack das Ganze zusammen und poste es hier. Es ist immer schön, ein funktionierendes Beispiel zur Hand zu haben ;-)
Brumm(en)?
Nein, eigentlich nicht.
Hat auch früher immer getaugt wenn ich mal 5v brauchte, nur hier halt
nicht, deshalb habe ich garnicht damit gerechnet.
Zumal, wenn es zumindest sporadisch funktioniert rechnet man ja nicht
mit einem Fehler bei der Versorgung (ich zumindest nicht)
>> Pack das Ganze zusammen und poste es hier.
ok, mache ich heute noch. Werde auch noch ein paar Kommentare einfügen.
So hier dann mal das ganze Paket. leider läuft die Ausgabe derzeit nur sequentiell weil ich durch irgenteinen doofen Fehler meinen ganzen softcore zerschossen habe, aber was solls. Zum Testen und Erweitern ist es denke ich brauchbar.
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.