Hallo Leute,
ich lese hier schon seit langer Zeit mit und finde es durchaus
interessant hier.
Aktuell habe ich nun auch ein Problem und hoffe ihr könnt mir
diesbezüglich weiterhelfen.
Ich habe ein Board mit einem Lattice XP2-17E und einem LC-Display
welches mittels SPI Schnittstelle verbunden ist, es handelt sich um
einen EA DOGM-163.
Das Display hat dabei die Signale: MOSI, RS, nSS und SCLK und wird mit
3,3V betrieben.
Auf dem Display soll nun ein Text ausgegeben werden, Testweise erst
einmal Hallo. Der verbaute Reset-Taster wird mittels einer Software
Routine entprellt.
Jetzt ist es so, dass ich den FPGA zwar programmieren kann, der Display
jedoch nur leuchtet und offensichtlich nun nicht initialisiert wird. Ich
tüfftel schon seit über einer Woche daran rum und finde den Fehler
nicht.
Ich habe die Dateien hier im Anhang beigefügt und hoffe einer von euch
findet den Fehler und kann mir weiter helfen.
MfG Batzi
Ich würde dir ja raten, Textaus(/ein)gaben (und in deinem Fall auch den
init vom DOGM) grundsätzlich mit einem Softcore zu machen.
Das ist deutlich einfacher+besser wartbar und flexibler.
SPI-Peripheral kannst du dir ja in Hardware dranbauen falls
nötig/gewünscht. Die gibts aber auch schon in fertig z.B. hier:
http://www.lothar-miller.de/s9y/categories/45-SPI-Master
Passende init-Sequenzen für die DOGM finden sich auch hier im Forum
mehrfach soweit ich weiß.
Verstehe ja, dass du das machst um etwas zu lernen, aber die Textausgabe
direkt mit dem FPGA ist nicht so sinnvoll.
Wenn du keinen Softcore benutzen willst, würde ich mir zumindest ein
simples Format übrelegen, um SPI-Frames in einem SRAM Block abzulegen
und dazu ein simples Modul das die Frames nacheinander ausliest und auf
den SPI-Bus gibt.
Das Software-Äquivalent deiner derzeitigen Lösung wäre:
*SPIDR = 'H';
*SPIDR = 'a';
*SPIDR = 'l';
*SPIDR = 'l';
*SPIDR = 'o';
...
und am Anfang nochmal genauso den Init-Code. Auch am Tag der Nudel ist
Spaghetti-Code Mist.
In Software würde man das auch so lösen, dass man Init-Sequenz+Text in
ein Array packt. Das VHDL-Äquivalent dazu ist der SRAM Block.
Batzi schrieb:> Ich tüfftel schon seit über einer Woche daran rum und finde den Fehler> nicht.
Wie sieht die Testbench für die Simulation aus? Gerade ein SPI-Interface
und ein Display lassen sich sehr schön simulieren...
Eine Suche hier im Forum ergibt für die Ansteuerung eines HD44780 das
hier:
Beitrag "[VHDL] 16x2 LCD Textcontroller / HD44780"
Und den
Beitrag "Re: LCD HD44780 Problem"
Die Kommandos und die Daten dann per SPI zu senden ist nur ein
zusätzlicher Zwischenschritt...
BTW:
> top.txt> spi.txt> taktgenerator.txt> entprellen.txt
Meine VHDL-Dateien enden auf *.vhd oder *.vhdl
Das macht sich gut wegen des Syntax-Highlightings hier im Forum.
Danke für deine schnelle Antwort.
Leider bin ich noch recht neu bei VHDL, und hab mir das nur mit Hilfe
von 2 Kollegen zusammen schustern können. Könntest du mir konkret sagen
welchen Teil ich überarbeiten muss? Bzw. wo evtl. der Fehler in meinem
spaghetti code sitzt?
Er lässt sich wunderbar Compilieren oder Fehler jedoch Zeigt er nichts
an.
Der SCLK liegt am Display an, soweit so gut. Er schiebt mir jedoch die
Daten nicht aus den MOSI Port raus. und daran hackts bei mir leider
extrem.
Hallo Lothar,
die *.vhd hab ich hier nochmal hochgeladen, dachte als *.txt ist es
leichter zu öffnen, da wahrsch. nicht jeder ein Programm auf dem
aktuellen PC installiert hat.
Gruß
p.s.: danke für den Post link, hab zwar die suche benutzt das jedoch
nicht gefunden... hab wohl tomaten auf den augen..
Batzi schrieb:> Er lässt sich wunderbar Compilieren oder Fehler jedoch Zeigt er nichts> an.
Mit "Anschauen" ist da nicht viel zu machen. Der "Debugger" für
VHDL-Beschreibungen heißt "Simulator"...
Allerdings ist schon die Takterzeugung bedenklich. Man teilt nicht
einfach Takte herunter, sondern nimmt entsprechende Taktgeneratoren auf
dem FPGA.
Oder für Anfänger: es gibt nur 1 Takt, der kommt vom Oszillator und der
Rest wird mit Clock-Enables gemacht.
> Er schiebt mir jedoch die Daten nicht aus den MOSI Port raus.
Der SS tut aber?
Du gibst in deiner SPI das signal s8_Data aus: pi8_Data => s8_Data,
Aber dem wird nie ein Wert zugewiesen... :-o
Im Anhang mal meine "Testbench", wo ich gleich erkenne, dass da nichts
Sinnvolles passiert...
Hallo Lothar,
vielen Dank für deine bisherige Hilfe und die TB Datei.
Leider bekomme ich auch mit der Simulation keine sinnvollen Werte Raus.
Dass s8_data keinen Wert hat war ein fehler, da sollte s8_Data_init hin,
um wenigstens die Initialisierung des Displays erstmal zum laufen zu
bekommen, jedoch alles ohne Erfolg.
Hab jetzt auch mal nachgemessen. Hab den 250kHz Takt auf einen Seperaten
Pin direkt nach dem Taktgenerator ausgegeben und dort sieht der Takt
super aus. Ein schönes Rechteck mit 250kHz. Leider ist am Display an der
SPI Schnittstelle dann ein Takt von 100MHz um 90° Phasenverschoben und
verzehrt anliegend. Kann mir aber nicht erklären wieso. Der Fehler
müsste in SPI_Ausgabe.vhd sein aber mMn passt die so.
Hoffentlich könnt ihr mir noch weiter helfen.
Gruß
Basti
Batzi schrieb:> Leider bekomme ich auch mit der Simulation keine sinnvollen Werte Raus.
Genau das wäre aber der allererste Schritt. Nichts lässt sich schöner
und einfacher simulieren, als das, was du da vorhast. Also macht es
keinerlei Sinn in der Hardware rumzumessen, wenn noch nicht mal das
gewünschte Verhalten der Schaltung sicherstellen kannst.
> Hoffentlich könnt ihr mir noch weiter helfen.
Welche Warnungen/Infos bekommst du bei der Synthese?
Es ist extrem schlechter schlechter Stil, getaktete und
kombinatorische Prozesse zusammenzumantschen. Da verliert man schnell
mal den Überblick!
Z.B. ist in diesem Fall die Sensitivliste absolut unvollständig! Da
gehört alles rein, was eine Neuberechnung des Prozesses nötig macht:
pi1_SCLK, s1_SCLK_next, pi1_Enable, pi1_Enable2, s1_Blocked, usw.
Aber sicher nicht s1_SCLK_Fall, denn das ist ja ein Ergebnis der
Prozessberechnung!
Und zur Krönung des Ganzen habe wir hier eine (versteckte)
kombinatorische Schleife:
1
process(pi1c_CLK,pi1r_RST,s1_SCLK_Fall)
2
begin
3
:
4
:
5
if(s1_SCLK_Fall='1')then-- das ist KEIN Takt ....
6
ifsi_Count/=0then
7
s8_Data(7downto0)<=s8_Data(6downto0)&'0';
8
si_Count<=si_Count-1;-- ... und HOPPALA, ein amoklaufender Zähler
9
:
http://www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html> Hoffentlich könnt ihr mir noch weiter helfen.
Bring deine Simulation ans Laufen: der Simulator ist der Debugger des
FPGA-Designs (nicht das Oszi und nicht der Logicanalyzer!). Du wirst nur
mit unnötigen Klimmzügen und viel Erfahrung ein Design ohne Simulator
zum Laufen bekommen. Und vor Allem: es ist halb so wild...
