Bevor ich mein Problem schildere schicke ich voraus, dass ich mit
Quartus II v8.1 Web Edition, dem the Altera DE2 Board (besonders mit dem
ADV7181B Video Decoder) und dem PAL-Ausgang einer Panasonic Digital
Camera arbeite.
Um mich in das Thema einzuarbeiten, wollte ich einfach die Clock Zyklen
zählen, die PAL-Zeile dauert. Das habe ich mit einem sehr einfachen
Counter, welcher mit HSYNC zurückgesetzt wird und seinen Endwert auf den
roten LED’s anzeigt, auch hinbekommen. Die Simulation funktionierte auch
einwandfrei. Aber wenn ich versuche meine Hardware auf den FPGA zu laden
passiert Folgendes: Es gibt LEDs die durchgängig leuchten und welche die
sehr schnell blinken. Wenn ich nur die betrachte die durchgängig
leuchten, dann zeigt mein Counter die richtige Länge einer Zeile an.
Aber ich kann ja die blinkenden nicht außer acht lassen. Sollte nicht
jede Zeile eines PAL-Signals die gleiche länge haben? An was könnte das
liegen – an meiner Programmierten Hardware (im Anhang), dem Decoder
Schaltkreis oder gar meiner Camera?
Ich bin etwas verzweifelt, weil das Problem mir eigentlich so einfach
erschien, aber mich schon eine ganze Weile gefangen hält. Ich freue mich
wirklich sehr über jede Hilfe.
MfG Alex
Ich sehe den Fehler auch nicht auf Anhieb,
Es ist mehr eine Denksportaufgabe.
versuche es mit dem Prinzip "Teile und herrsche."
Ein Prozess für den horizontalen Counter und einen zweiten Prozess für
den vertikalen Counter.
Da wird es gleich übersichtlicher.
René
Danke für die schnelle Antwort. Ich hab das vorher schon einfach
probiert und hätte wirklich besser gleich die andere Datei hochladen
sollen.
Leider kommt es da bei mir auf das selbe Problem heraus.
Ich hab hab wirklich keine Idee mehr woran das liegen könnte. Laut
Datenblatt vergehen 1728 Takte bis zum nächsten HSYNC Impuls. Da ich
während des HSYNC Impulses keine Takte zähle, bleiben bei mir demzufolge
1726 Takte. Wie gesagt, ich komme auch auf die Anzahl, aber eben nur
wenn ich nur die dauerhaft leuchtenden LEDs betrachte alle anderen
blinken ganz schnell. Das würde ja bedeuten, dass zwischendrin Zeilen
mit anderen Längen auftreten und das macht aber ja keinen Sinn.
Vielleicht hat ja jemand schon ähnliche Probleme mit dem Decoder
gemacht. Oder es ist wirklich der PAL Ausgang der Camera, der den
Decoder dazu bringt, dass er so komisch reagiert. Aber andererseits kann
ich mir das auch nicht vorstellen.
Der Decoder läuft auch mit den Grundeinstellungen.
Ein Klassiker: Ein asynchroner Reset ist schlecht.
Wenn das zudem noch ein funktionales Signal ist, entspricht das einer
Statemachine mit einem asynchronen Eingang. Sieh dir mal die Erklärung
dazu an:
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
Fazit: Es ist Zufall, was passiert, wenn hsync = '1' wird...
Warum machst du es nicht so:
Vielen Dank für die Antwort. Ich habe es auf jeden Fall jetzt einmal so
gemacht, wie du mir vorgeschlagen hast. Leider komme ich erst morgen
wieder an das Board ran. Ich werde dann Bescheid geben, ob es so
funktioniert hat.
Ich hab es jetzt auf das DE2 Board gespielt und es funktioniert zwar
wesentlich besser, aber immer noch nicht einwandfrei.
Das heißt im Prinzip, dass der Kontrast zwischen den LEDs größer
geworden ist. Allerdings blitzen die "falschen" LEDs immer noch auf.
Hat vielleicht irgendwer noch eine andere Fehlerstelle gesehen? Oder hab
ich gar einen neuen Fehler rein gemacht?
Vielen Dank für eure Zeit.
> Hat vielleicht irgendwer noch eine andere Fehlerstelle gesehen?
Ich würde mal eine Flankenerkennung auf den Hsync setzen, und dann von
Flanke zu Flanke zählen:
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung> Allerdings blitzen die "falschen" LEDs immer noch auf.
Bist du sicher, dass nicht doch mal zwischendurch unterschiedlich lange
Sync-Impulse kommen? Z.B. durch den vsync, denn der kann dir das Zählen
unterbrechen:
if vsync = '0' then
if hsync = '0' then
Danke Lothar, dass sieht wirklich schon viel besser aus.
Ich hab einfach das edge_detect Design von dir genommen und den
Rise-Ausgang im Schematic an mein Design (l_counter_micro_2.vhd)
angekoppelt. Und jetzt halten die LEDs verhältnismäßig ruhig.
Verhältnismäßig bedeutet hier, dass er offensichtlich zwischen den
Werten 1725 und 1726 hin und her springt. Ich bin mir nicht ganz sicher
woran das liegen könnte.
Ich verstehe ehrlich gesagt auch noch nicht so richtig, wieso es nicht
schon vorher funktioniert hat. Die Systematik ist doch die Gleiche
geblieben. Es liegt quasi ausschließlich an der Synthese?
Hi... ich mache momentan auch eine Bildverarbeitung mit einem FPGA
(Virtex5). Am Anfang wollte ich mir auch meine Pixel und Linien
mitzählen, da ich kein schönes stehendes Bild hatte. Und siehe da, ich
hatte den selben Effekt wie du, meine Pixelwerte schwankten leicht. Dies
lag aber nicht an der Synthese, sondern an meinem Aufbau (Leitung vom
Sensor zum FPGA Board). Habe diesen geändert und schon funktionierte
alles. eventuell hast du ja ein ähnliches Problem? Wie überträgst du
deine Sensordaten?
mfg
matzunami
> Ich bin mir nicht ganz sicher woran das liegen könnte.
Wie steil sind die Flanken des HSYNC? Zu welchem Zeitpunkt kommt die
Flanke des HSYNC? Evt. zusammen mit der Taktflanke?
Nimm mal testweise die falling_edge(video_clk)...
An Lothar:
Ich hab nach Simulation schon vermutet, dass die Zeit, die der
RISE-Impuls stehen bleibt, vielleicht etwas knapp werden könnte und habe
in deinem edge detector auf falling_edge umgesattelt. Das Ergebnis war
identisch - keine Besserung.
Die Rise/Fall Time der Ausgänge beträgt laut Datenblatt 1 ns. Die Flanke
des HSYNC kommt mit der fallenden Flanke des Taktes.
An Matzunami:
Ich kann an dem Routing nichts machen. Ich nutze das vorgefertigte DE2
Board von Altera. Und falls du den Weg von meiner Kamera zum Board
meinst - da kann ich auch nicht viel machen. Ich hab leider nur diese
Eine und dazu nur dieses eine Kabel.
Leider komm ich so ohne Weiteres nicht da ran. Ich versuche das mal
herauszubekommen.
Danke noch mal, und wenn jemandem noch etwas auffällt, dann würde ich
mich freuen, wenn er es sagt.
MfG Alex
So, dann will ich die Sache hier mal etwas abrunden. Ich hab mir heute
mal den Takt und HSYNC mit einem Oszi angeguckt und sehr erstaunliche
Erkenntnisse erlangt.
Altera hat das DE2 Board in zwei Revisionen herausgebracht. Die
unterscheiden sich äußerlich nur durch einen anderen Typ von
Kondensatoren. Ist ja auch egal.
Auf jeden Fall sieht es wohl so aus, dass bei der älteren Revision (mit
der habe ich gearbeitet) der Takt absolut asynchron zum HSYNC läuft.
Wenn ich auf eins der beiden Signale getriggert habe ist das andere
immer davon gelaufen.
Glücklicherweise waren im Labor auch Boards der zweiten Revision
vorhanden und bei denen kommt der HSYNC genau mit der fallenden
Taktflanke. Ich hab das bei mehreren Boards ausgetestet.
Quintessenz also, bei den Boards der ersten Revision haut da irgendwas
nicht hin. Ich kann mir auch gar nicht vorstellen wie das gehen soll, da
ja das HSYNC Signal im Decoder mit dem selben Takt erzeugt wird.
Das passt auch alles genau zu meinem Ergebnis. Da mein Counter ja
offensichtlich 1726 +- 1 angezeigt hat.
Auf jeden Fall bin ich sehr dankbar für den Hinweis, die Signale zu
messen und hab mir jetzt ein Board der zweiten Revision mitgenommen :)
MfG
Alex
PS: ich hab mal trotzdem schnell die zwei Bilder angehängt. Die
Bezeichnungen sprechen für sich.
