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.
1 | if(hsync = '0') then |
2 | pstate <= '1'; |
3 | pixel_count <= pcount; |
4 | elsif(rising_edge(video_clk)) then |
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:
1 | if(rising_edge(video_clk)) then |
2 | if(hsync = '0') then |
3 | pstate <= '1'; |
4 | pixel_count <= pcount; |
5 | else
|
6 | if vsync = '0' then |
7 | :
|
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.
> Die Flanke des HSYNC kommt mit der fallenden Flanke des Taktes.
Wie steil und sauber ist die HSYNC-Flanke (gemessen)?
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
Angehängte Dateien:
-
takt_gut.jpg
330 KB -
takt_schlecht4.jpg
220 KB
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.