Forum: Digitale Signalverarbeitung / DSP / Machine Learning BF609 mit MT9V024 mono nur jedes zweite Bild wird eingelesen


von Tim F. (borger)


Lesenswert?

Hallo liebes Forum,
habe da ein Problem mit meinem Blackfin BF609 EZ-KIT.
Ich habe einen MT9V024 mono chip von Aptina angeschlossen,
über das EI-3 Kamera Erweiterungsboard.
Er schickt 60 Bilder die Sekunde mit 752x480 Pixel.
Angeschlossen ist der Chip am EPPI1 des BF609.
Die Bilder sollen durch die EPPI1 in die PVP und danach per DMA in den 
externen Ram.
Wenn der DMA-prozess fertig ist, gibt es einen Interrupt,
der die Speicherbank umschaltet.
Betrieben wird der Mt9v024 im Snapshot modus.

Ich hab nun das Problem, dass ich ein Bild aufnehme und erstmal gar 
nichts passiert.
Dann triggert man die Kamera zum zweiten mal an und erst dann kommt der 
Interrupt.

Es gibt ja noch die Möglichkeit, bei einem Fehler in der EPPI einen 
Interrupt zu bekommen.
Wenn ich diesen aktiviere, dann liegt der Grund darin, dass es einen 
LTOVR (Lin track overflow) gibt.
Also, bedeutet das, es werden mehr zweilen gesamplet, als in den 
Registern der EPPI eingetragen.
Erhöhe ich nun diesen Wert um eins, bekomme ich einen LTUNR (Line track 
underflow).

Hier sind die zuständigen Register:

EPPI_LINE = 846 //Hier overflow, bei 847 underflow
EPPI_HCNT= 752
EPPI_FRAME= 525 //
EPPI_VCNT= 480

Packing en, Broadcast dis, auf steigende Flanke samplen, LV und FV 
active high

Dann kommt die PVP mit canny-camera-edge konfig

IPF0: 752x480, Frame = 1, Drain en,

Dann kommt cnv0, hier wird unscharf gemacht und um 15 bit nach rechts 
geschoben (dieses schieben habe ich aus nem Beispiel, und nicht wirklich 
verstanden,

allerdings funktioniert gar nichts, wenn man es nicht so eingibt).

Dann kommen CNV1 und CNV2 parallel für X und Y kanten.

Dann kommt der PMA, hier kann man ja nichts einstellen.

Danach kommt der Pixel edge classifier

Zuletzt der OPF1, der 32bit am eingang erwartet und 8 Bit ausgibt.

Die einstellung für den DMA-Manager sind:

XCNT 90240 // 752*480/4 da 8 bit pro pixel und packing aktiviert ist
XMOD 4

DMA CFG:  Adresse_1D, Interrupt wenn xcnt überläuft.

Kann hier jemand erkennen, ob ich irgendwo was falsch gerechnet oder 
nicht berücksichtigt habe?
Wenn man drüber nachdenkt, dass erst wenn man zum zweiten mal eine 
Bildaufnahme anstößt, der DMA prozess fertig wird, wäre man doch der 
meinung, dass das

evtl passiert, weil zu wenig zeilen oder pixel angekommen sind, als in 
den Registern angegeben.
Das widerspricht ja aber erstens dem Datenblatt vom MT9v024 und zweitens 
dem Line track overflow.

Oder, kann es sein, dass der BF nur auf steigende Flanken achtet? 
Normalerweise ist ja der Framevalid high, im aktiven Bildbereich und 
fällt am Ende auf null.
Könnte es sein, dass der BF diese fallende Flanke ignoriert und statt 
dessen auf eine steigende wartet um das Ende des Frames zu erkennen?
Wenn ja, wäre das ein sehr unflexibler Controller.

Als drittes: EIgentlich muss dieser Line Track fehler weg, nur wie???

Ich wäre für jeden Tip dankbar.

Gruß Tim

von Strubi (Gast)


Lesenswert?

Hi Tim,

Ich kenne den BF609 nur noch aus der Ferne, aber wenn der Designfehler 
im EPPI des BF54x im 609er nicht gefixt wurde, dann wird er bei den 
meisten Video timings Fehler werfen. Die muss man dann wohl ignorieren. 
Habe zu dem Thema mal vor Jahren was zusammengestellt, vielleicht hilft 
Dir das weiter: http://tech.section5.ch/news/?p=4
Ein richtiger "Fehler" ist es nicht, man wollte den EPPI wohl mit etwas 
mehr Fehlererkennung ausstatten, aber dabei wurden so einige Fälle von 
generischem Videotiming wie bei dem Aptina-Sensor vergessen.
Ich hatte damals dasselbe Problem und bin beim BF527 geblieben, bzw. 
habe ein FPGA vorgeschaltet.

Grüsse,

- Strubi

von Tim F. (borger)


Lesenswert?

Hallo Strubi,

danke für deinen Antwort.
Habe nochmal etwas rumprobiert und bekomme auch immer, den 
Linetrackfehler, wie in deinen Messungen.
Übrigens, warum steht denn das nichtmal in den Anomalies des BF54x 
drin???
Haben die das noch nicht gemerkt???

Den Fehler würde ich gern ignorieren, habe ich auch schon probiert, 
allerdings bekomme ich nur jedes zweite Triggern ein interrupt.

Nach weiterem herumprobieren, habe ich rausgefunden, dass wenn der 
Framecounter der Eppi deaktiviert ist, (hatte ihn vorher auf eins 
stehen, damit halt nur ein Frame bearbeitet wird) und die Drain funktion 
der PVP auch deaktiv ist, dann kommt nach jedem Frame ein interrupt. Mit 
der Ausnahme beim Start des Programs. Am Anfang muss man zweimal 
triggern, ab dann löst jeder Trigger die ISR aus. Soweit erstmal nicht 
schlimm, aber nun landet bei jedem Bild der rechte Rand (ca 50 pixel) 
auf der linken seite (Also das was eigentlich rechts sein sollte ist 
links). Irgendwas ist beim erstem mal anders. Hat da vielleicht noch 
jemand eine Idee?

Ich habe schon in der engineerzone geschrieben und mehrere Mails an den 
Prozessor support von Adi. In der EZ habe ich gar keine Antworten 
bekommen, und beim Support kam als Antwort, dass derjenige meine 
Hardware(Kamera Headboard) nicht hat und ich solle mir die EPPI nochmal 
angucken.
Wunderlich, dass die meine Kamera nicht habe, wo sie doch extra eine API 
für den MT9V024 geschrieben haben.
(Überall hört man, dass der ADI support so toll sein soll) Was habt ihr 
für Erfahrungen mit denen?

Strubi, was meinst du denn mit generischem Videotiming.
Und was hast du denn an dem Aptina Signal verändert, mit dem FPGA 
dazwischen?
Wie sieht denn ein Signal aus, was der Idealvorstellung eines Blackfins 
entspricht?
Müsste oder sollte ich auch etwas zwischen Imager und Blackfin setzen?

Gruß Tim

von Strubi (Gast)


Lesenswert?

Hi Tim,

>
> danke für deinen Antwort.
> Habe nochmal etwas rumprobiert und bekomme auch immer, den
> Linetrackfehler, wie in deinen Messungen.
> Übrigens, warum steht denn das nichtmal in den Anomalies des BF54x
> drin???
> Haben die das noch nicht gemerkt???

Doch, die bekamen auch vor Jahren einen detaillierten Bug-Report, haben 
versprochen sich drum zu kümmern, aber ich habe nie wieder was von ihnen 
gehört.
Ich würde es nicht als Anomalie oder Bug sehen, einfach ein schlecht 
designtes "Feature."
>
> Nach weiterem herumprobieren, habe ich rausgefunden, dass wenn der
> Framecounter der Eppi deaktiviert ist, (hatte ihn vorher auf eins
> stehen, damit halt nur ein Frame bearbeitet wird) und die Drain funktion
> der PVP auch deaktiv ist, dann kommt nach jedem Frame ein interrupt. Mit
> der Ausnahme beim Start des Programs. Am Anfang muss man zweimal
> triggern, ab dann löst jeder Trigger die ISR aus. Soweit erstmal nicht
> schlimm, aber nun landet bei jedem Bild der rechte Rand (ca 50 pixel)
> auf der linken seite (Also das was eigentlich rechts sein sollte ist
> links). Irgendwas ist beim erstem mal anders. Hat da vielleicht noch
> jemand eine Idee?
>

Du musst beim EPPI die genauen Timings der Pausen eben auch noch 
einhalten, sonst kommt der Frame ev. verschoben an. Ausserdem musst Du 
auch auf korrekten Zeitpunkt des DMA-Transfers achten, da kann man sich 
auch ins Knie schiessen.

> Ich habe schon in der engineerzone geschrieben und mehrere Mails an den
> Prozessor support von Adi. In der EZ habe ich gar keine Antworten
> bekommen, und beim Support kam als Antwort, dass derjenige meine
> Hardware(Kamera Headboard) nicht hat und ich solle mir die EPPI nochmal
> angucken.
> Wunderlich, dass die meine Kamera nicht habe, wo sie doch extra eine API
> für den MT9V024 geschrieben haben.
> (Überall hört man, dass der ADI support so toll sein soll) Was habt ihr
> für Erfahrungen mit denen?
>

Bis zu einem gewissen Punkt ist der Support wie bei allen anderen auch. 
Sobalds ans Silicon geht, hört leider oft die Kenntnis der outgesourcten 
FAEs auf, und man weiss als Kunde oft irgendwann mehr als die FAEs 
selbst. Bis gemeldete Probleme bei den Silicon-Guys ankommen, vergeht 
ein langer Weg, und Rückmeldung bekommt man so gut wie nie.
Die Politik von ADI ist seit Jahren verwirrend bis frustrierend, aber da 
schenkt sich zu TI und anderen nix.


> Strubi, was meinst du denn mit generischem Videotiming.

Ein Video-Timing, was weder BT656 noch SDI oder sonst was einhält, wie 
es eben oft von Feldwaldwiesen-Sensoren kommt. Aber dass dein Aptina 
nicht will, ist verwunderlich. Der sollte eigentlich ein konformes 
Timing können.

> Und was hast du denn an dem Aptina Signal verändert, mit dem FPGA
> dazwischen?

Die Daten gehen in einen Encoder und werden als Zeilenschnipsel 
(Pseudozeilen) an den PPI übermittelt. Schlage mich also auf Bfin-Seite 
her nicht mehr mit Sensoren-Timings herum. Das ganze wird nämlich so 
richtig lustig, wenn die Sensoren Autoexposure machen und ihre Framerate 
(also Timings) ändern.

> Wie sieht denn ein Signal aus, was der Idealvorstellung eines Blackfins
> entspricht?

Genau definierte Sync-Dauern und Blank-Pause. Aber das gilt für den EPPI 
des BF54x. Kann sein, dass neue Böcke eingeschleppt wurden.

> Müsste oder sollte ich auch etwas zwischen Imager und Blackfin setzen?
>

Hängt davon ab, was Du vorhast. Bist Du denn auf den 60x angewiesen? Es 
gibt inzwischen einige besser supportete Alternativen auf der ARM-Seite 
(Freescale imx6).
Ansonsten macht es IMHO immer Sinn, ein kleines FPGA vorzuschalten, wenn 
die Timings noch nicht so ganz 100% feststehen. Da kann man dann viel 
korrigieren, puffern/verzögern, usw.


Grüsse,

- Strubi

von Tim (Gast)


Angehängte Dateien:

Lesenswert?

Ich habe mal da Programm angehängt.
Würde mich freuen, wenn du da mal reinschauen könntest, vielleicht fällt 
dir ja etwas auf.

Du schreibst von genau definierten Timings, die habe ich leider noch 
nirgends gefunden. Alles was ich kenne ist das etwas missverständliche 
Diagram im Datenblatt (ist vom Aufbau her mit dem BF54x gleich).
Wo finde ich denn die Timings?
Und wann der DMA-prozess gestartet wird, bestimmt doch die PVP und wenn 
der Zähler des DMA managers überläuft, gibts einen Interrupt.
Da habe ich doch gar keinen Einfluss drauf.

Strubi schrieb:
> Schlage mich also auf Bfin-Seite
> her nicht mehr mit Sensoren-Timings herum.

In welche Register schreibt man denn das Timing? Unter den EPPI 
registern sind doch nur Anzahlen von Zeilen, Pixeln, delays... möglich.

Habe auch nochmal zwei Bilder angehängt.
Bild1.jpg ist das erste empfange Bild. (Man beachte, ich musste hier 
zweimal den Auslöser betätigen)
Bild2.jpg ist das 2. bild was kommt, ab hier braucht man nur noch einmal 
triggern. Ich denke das liegt daran, dass noch Daten (Pixel) in der PVP 
stecken.
Man sieht jedenfalls oben und links am Rand das hier etwas nicht stimmt, 
ganz im Gegensatz zum ersten Bild, wo die Welt noch in Ordnung ist.

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.