www.mikrocontroller.net

Forum: FPGA, VHDL & Co. CMOS Sensor MT9P031


Autor: Julius Gonser (jugonser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

ich möchte eine einfache Kamera mit dem MT9P031 Sensor von Aptina bauen.
Die Übertragung über USB an den PC soll der CY7C68013A von Cypress
erledigen.  Die Kamera soll einfach permantent Bilder an den PC senden.
Vom PC aus will ich dem Sensor Helligkeitseinstellungen etc. mitteilen.
Ich denke das könnte der CY7C68013A übernehmen.

Den Schaltplan könnte ich von Aptina bekommen, da gab es nämlich ein
Demo1-Board. Nur die Quellcodes für CY7C68013A und PC wollen sie mir
nicht geben. Das heißt, ich müsste von Null anfangen. Hat jemand
vielleicht ein ähnliches Projekt und kann mir weiterhelfen?

Gruß, Julius

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Julius,

ich habe MT9P031 zusammen mit dem Cypress 68013A (FX2) verwendet. Den 
FX2 habe ich im Slave FIFO Modus betrieben und den Sensor direkt an den 
FIFO angeschlossen. Es ergibt sich dabei das Problem, daß der Sensor 
seine Pixeldaten ohne Unterlaß in den FIFO des FX2 schiebt. Der Sensor 
hat keine Flußkontrolle! Eine kleine Störung bzw. Zeitverzögerung führt 
dazu, das Daten verloren gehen. Mit 1 bzw. 3MPixel Sensoren läuft das 
noch ganz OK, mit dem 5MPixel Sensor habe ich schwer gekämpft. Die 
Stabilität dieser Lösung ist bislang nicht befriedigend. Weiterhin hängt 
die Stabilität vom Betriebssystem ab. Unter Vista habe ich mit dem 
CyUSB-Treiber größere Probleme als unter XP.

Ich empfehle Dir, zwischen FX2 und dem Sensor noch einen eigenen FIFO 
(FPGA + Speicher) zu schalten.

Du kannst natürlich auch das Timing des Sensors derart herunterdrehen, 
daß Du ein stabiles Timing hinbekommst.

Gruss
Hans-Christian

Autor: Julius Gonser (jugonser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Hinweise, Hans-Christian!

Ich bin noch ein absoluter Anfänger bei der Programmierung eines 8051. 
Wäre es möglich, damit ich nicht ganz von Null anfangen muss, mir deine 
Quellcodes zur Verfügung zu stellen?

Gruß, Julius

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Julius,

leider wäre mein Arbeitgeber nicht mit der Veröffentlichung des 
Quelltextes einverstanden. Ich stehe Dir aber mit Tips und bei Problemen 
zur Seite.

Fang doch mal mit einer einfachen Applikation an. Auf dem PC mit dem 
CyUSB-Treiber. Dort öffnest Du einen EndPoint und liest von ihm. Auf dem 
FX2 erstellest Du einen EndPoint in den Du einfach Daten schreibst, 
sobald der FIFO leer ist. Aus den Demo-Programmen von Cypress geht 
eigentlich alles hervor. Wenn Du das hast, ist es nicht mehr so 
schwierig einen Kamera Sensor anzuschliessen.

Viel Spaß, nur Mut!

Gruss
Hans-Christian

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Habe über die Suche nach MT9P031 diesesn Post gefunden. Ich bin auch 
gerade an einem Projekt bei dem ich ein Bildsensor nutzen muss! 
Allerdings muss er nicht farbig sein, graustufen reichen (s/w).

Könnt Ihr mir eventuell einen Tipp geben welcher Sensor es gibt?


Bei meinem Projekt muss der Sensor nur ein "Foto" machen und auf 
SD-Karte schreiben (wie bei einer Digicam). Geplant hab ich eine 
SD-Karte über einen AVR anzusprechen, welcher auch den Sensor ausliest. 
Habt Ihr Tips wie ich den MT9P031 mit nem Mega128 verbinden soll?

Ich suche auch BW-Sensoren mit geringer Auflösung für ein anderes Projet 
(320x200 in 256 Grau würde da reichen). Habt Ihr ne Quelle mit günstigen 
Sensoren?

Grüße
Alex

Autor: Julius Gonser (jugonser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hans-Christian,

klar, die Codes von deinem Job kannst du natürlich nicht rausgeben.

Aber danke für das Angebot über Tips und Hilfestellung. Werde bei Bedarf 
darauf zurück kommen.

Noch ne Frage: sind die Codes von Cypress für den 68013A in C oder 
Assembler geschrieben?

Gruß, Julius

Autor: Julius Gonser (jugonser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Alex,

ich habe mich für den MT9P031I12STM von Aptina (ehemals Micron) 
entschieden. Das ist ein Monochrom Sensor mit 5 MPixel. Ich habe 
Demokameras mit diesem Sensor gesehen: das Bild ist super. Datenblatt 
und Infos findest du unter
http://www.aptina.com/products/image_sensors/mt9p0...
Aptina bietet auch Demoboards an. Den Sensor kannst du z.B. bei Framos 
kaufen. Sollte um die 40 EUR zu haben sein.

Ansonsten kannst du auch mal die Sensoren von OmniVision anschauen.

Viel Glück!
Julius

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Infos!

Was kostet denn das Demoboard? Hab mich bei Framos schon registriert, 
noch keine Antwort bekommen. Vermutlich schaut sich die Reg. ein Mensch 
an, und kein PC ;-)

Grüße
Alex

Autor: Julius Gonser (jugonser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal hier nach:
http://www.digikey.com/scripts/DkSearch/dksus.dll?...

Gruß, Julius

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin moin,

@Julius: Die Demos sind in C (FX2) bzw. C++ (PC-seitig) geschrieben.

@Alex: Ich bin mit den Sensoren von Omnivision nicht so glücklich 
geworden. Die Datenblätter sind in der Regel nicht so ausführlich wie 
die von Micron. Der Support ist auch lausig. Die Micron-Sensoren habe 
ich mit der Info allein aus den Datenblättern zum Laufen gebracht.

Von Micron gibt es Sensoren mit VGA Auflösung für etwa 12 EUR.

Der MT9P031 ist zwar recht schön, jedoch bescheiden zu löten (siehe 
Nachbarthread Beitrag "Re: CMOS Bildsensor mit mehr als 25 FPS" wo ich 
Photos abgebildet habe). Am Besten hat mir bislang der MT9M001 mit 
1.3MPixel gefallen.

Ob Du erfolgreich den MT9P031 mit einem ATmega128 verbinden kannst, 
bezweifle ich. Guck Dir mal die Datenraten an, die da entgegenzunehmen 
sind.

Viel Spaß allen Kamerabauern!

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julius:

Den MT9P31 kenne ich zwar allerdings nutze ich ihn nicht an USB.
Ich wuerde auch unbedingt ein FPGA FIFO dazwischenschalten, denn eine 
Bildzeile ist u.U. laenger als ein FIFO-Buffer im FX2 (CY68013A).
Unabhaengig davon habe ich aber schon einige Sachen mit dem FX2 gemacht. 
Habe mit folgender Softwareunterstuetzung relativ schnell loslegen 
koennen:

- SDCC v2.6.0 (C-Compiler fuer u.a. 8051)
- Source fuer FX2 im GnuRadio-Projekt

Fuer den FX2 musst Du leider etwas Konfigurationsarbeit leisten, wie 
Endpoint-Descriptoren anpassen, FIFOs konfigurieren, etc.
Laesst sich aber alles mit Hilfe der FX2-HW-Referenz hinkriegen und von 
den diversen Gnu-Sourcen abgucken.

Viel Erfolg!

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans-Christian wrote:

> Ob Du erfolgreich den MT9P031 mit einem ATmega128 verbinden kannst,
> bezweifle ich. Guck Dir mal die Datenraten an, die da entgegenzunehmen
> sind.


Hmm, ok muss ich mir mal genauer anschauen. Ich hab da nur ein SCL/SCK 
gesehen mit 400khz und war der Meinung das ich dort das Bild auslesen 
kann. Eigendlich mus ich nur ein Foto machen. Das Auslesen kann von mir 
aus auch ne Minute dauern!
Wär halt schön wenn es mit nem M128 geht. Davon hab ich noch genügend 
rumliegen.

Autor: alta (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kenne den speziellen Sensor nicht, aber das ist nur der I2C Bus zum 
KONFIGURIEREN des Sensors und nicht zum Auslesen...

Autor: jugonser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin,

was soll der FPGA FIFO genau machen?

Gruß, Julius

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das habe ich kurz nach dem Absenden selber gesehen grml ^^

Also muss ich wohl den Sensor über einen FPGA die Bilddaten entlocken 
und in einen Ram schreiben. Eventuell kann der FPGA die SD-Card 
anfeuern. Hab aber zu wenig mit FPGAs gemacht um das sicher zu wissen ob 
das geht.

Eventuell find ich irgendwo ein FPGA-Beispiel mit dem Sensor.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Julius,

>
> was soll der FPGA FIFO genau machen?
>

Das Problem beim FX2 ist, dass er nur maximal 1kb (1024B) grosse FIFOs 
hat. Wenn also das USB2.0 kurz stockt (man erinnere sich, USB ist 
'polled', also muss laufend abgefragt werden), gehen Dir eventuell ganze 
Bildzeilen oder Fragmente verloren (Hans Christian hat das weiter oben 
schon beschrieben). Du solltest also mindestens ein paar Zeilen in einem 
Block-RAM puffern.
Dazu kommt, dass die Videosignale diverser Sensoren etwas 
unterschiedlich laufen, manche Sensoren schicken nur einen kurzen Puls 
zur Vertical-Synchronisation. Das kannst du dem FX2 nicht direkt 
fuettern. Es empfiehlt sich also auf jeden Fall der Einsatz 
irgendwelcher programmierbarer Logik, wenn Du ev. auch mal einen 
billigen Omnivision ausprobieren willst.
Je nachdem, was Du mit der Kamera machen willst, kann ich auch den 
Blackfin empfehlen. An die BF53x und BF52x-Reihe lassen sich alle 
moeglichen Sensoren anschliessen. Die BF52x haben zudem USB 2.0. 
Allerdings kann sowas ganz schoen komplex werden (BGA, ev. SDRAM...) - 
ev. kommst Du aber mit einem Core-Modul von Bluetechnix 
entwicklungstechnisch gut weg.

Gruss,

- Strubi

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Julius,

mit den Blackfins habe ich auch schon gute Erfahrungen gemacht. Es gibt 
auch gute open source Lösungen und eine wirklich riesige Webgemeinde. 
Wenn Du einen BF561 verwendest hast Du einen Core für die Bilderfassung 
und einen für ein Betriebssystem, wie z.B. Linux (Strubi wird da 
wahrscheinlich viel mehr darüber erzählen können)

Die Sensoren sind bei der "Datenablieferung" unerbärmlich. Wir verwenden 
daher sehr häufig eine kleines FPGAs zwischen Sensor und dem jeweiligen 
Prozessor. Dann kann der Prozessor die Daten aus dem FIFO mit seinem 
eigenen Takt sogar im Pollingbetrieb abfragen. Wichtig ist allerdings, 
dass man die effektive Pixelrate abholen kann.

Beispiel:
Der MT9P031 hat maximal 96MHz Pixeltakt an seinem Ausgang. Dabei 
generiert er  5MP Bilder mit ca. 14fps. Das entspricht einer effektiven 
Pixelrate von 2592x1944x14 Pixel/s <= 70,6 MPixel/Sekunde. Durch 
richtige Parametrierung der Blankzeiten lässt sich die Framerate und die 
effektive Pixelrate natürlich noch weiter senken.

Viele Grüße
Arndt

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arndt Bußmann wrote:
> Hi Julius,
>
> mit den Blackfins habe ich auch schon gute Erfahrungen gemacht. Es gibt
> auch gute open source Lösungen und eine wirklich riesige Webgemeinde.
> Wenn Du einen BF561 verwendest hast Du einen Core für die Bilderfassung
> und einen für ein Betriebssystem, wie z.B. Linux (Strubi wird da
> wahrscheinlich viel mehr darüber erzählen können)
>
> Die Sensoren sind bei der "Datenablieferung" unerbärmlich. Wir verwenden
> daher sehr häufig eine kleines FPGAs zwischen Sensor und dem jeweiligen
> Prozessor. Dann kann der Prozessor die Daten aus dem FIFO mit seinem
> eigenen Takt sogar im Pollingbetrieb abfragen. Wichtig ist allerdings,
> dass man die effektive Pixelrate abholen kann.
>
> Beispiel:
> Der MT9P031 hat maximal 96MHz Pixeltakt an seinem Ausgang. Dabei
> generiert er  5MP Bilder mit ca. 14fps. Das entspricht einer effektiven
> Pixelrate von 2592x1944x14 Pixel/s <= 70,6 MPixel/Sekunde. Durch
> richtige Parametrierung der Blankzeiten lässt sich die Framerate und die
> effektive Pixelrate natürlich noch weiter senken.
>
> Viele Grüße
> Arndt

Wie würdest Du die FIFO-Schaltung aufbauen? Ich würde nur ein Bild pro 
Sekunde benötigen (1Bild pro Minute würde auch ausreichen).

Ist das Bild erst mal im Speicher, kann das ja jeder popelige AVR 
verarbeiten!

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex W. wrote:

>
> Wie würdest Du die FIFO-Schaltung aufbauen? Ich würde nur ein Bild pro
> Sekunde benötigen (1Bild pro Minute würde auch ausreichen).
>
> Ist das Bild erst mal im Speicher, kann das ja jeder popelige AVR
> verarbeiten!

Hi Alex,

die Aufgabe ist die hohen Datenrate des Sensors in den Griff zu 
bekommen. Diese tritt einmal pro übertragende Zeile mit dem Pixeltakt 
des Sensor auf, unabhängig davon, wie hoch die Bildrate ist. Mann kann 
natürlich das Optimum zwischen benötigter Framerate, Belichtungszeit und 
Pixeltakt finden.

Ich würde versuchen ein zeilenbasiertes FIFOs in einem kleinen FPGA zu 
realisieren. In Zweierpotenzen gedacht wären das maximal 4096 Pixel a 16 
Bit, das entspricht 4 "normalen" BlockRAMs eines FPGAs. Die effektive 
Pixelrate würde ich versuchen so klein wie möglich zu machen (durch 
möglichst große horizontal Blanks). Der AVR sollte dann aber in der Lage 
sein diese Zeilen in der passenden Zeit abzuholen.

Eine andere Variante wäre ein komplett Bildgrabber auf FPGA Basis, 
allerdings müsste dann ans FPGA noch ein ausreichend großes RAM 
angeschlossen werden. Das Bild kann dann komplett in dieses RAM 
gespeichert werden und der AVR kann es dann "gemütlich" auslesen.

Viele Grüße
Arndt

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welchen FPGA würdest Du mir empfehlen?

Ich hab mal nachgesehen. Der XC3S50 hat 72k Block RAM. Wäre es damit 
möglich? Aufgrund der Auflösung wären das ja knapp 70MByte an Rohdaten.

Würde es Sinn machen ein 128MB großen RAM an den FPGA zu stöpseln und 
die Bildinformationen vom CMOS direkt in den RAM zu schreiben?

Oder geht es eleganter, bzw was ist gängige Praxis?

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex W. wrote:
> Welchen FPGA würdest Du mir empfehlen?
s.u.

> Ich hab mal nachgesehen. Der XC3S50 hat 72k Block RAM. Wäre es damit
> möglich? Aufgrund der Auflösung wären das ja knapp 70MByte an Rohdaten

Wenn man zeilenbasiert arbeiten kann (das ist zu 90% der Fall und 
gängige Praxis), dann benötigst Du 4 BlockRAMs (4x18kBit = 72kBit).

Da kannst Du den XC3S50 (Xilinx), EP2C5 (Altera), EP3C5 (Altera), XP2-5 
(Lattice) oder den ECP2-12 (Lattice) nehmen. Wenn Du kein zusätzliches 
Flash anschließen willst, dann wäre der XP2-5 passend, der hat Flash 
drinn und 166KBit RAM.

>
> Würde es Sinn machen ein 128MB großen RAM an den FPGA zu stöpseln und
> die Bildinformationen vom CMOS direkt in den RAM zu schreiben?

Externes RAM braucht man nur dann, wenn man wirklich ein ganzes Bild 
zwischenspeichern möchte. Im Fall des MT9P031 wären das (aufgerundet auf 
2er Potenzen) 4096x2048x16 = 128MBit = 16MByte. Asynchromes RAM mit 
dieser Größe ist relativ teuer, daher müsste man dann SDRAM nehmen, was 
aber bedeutet, dass man einen SDRAM-Controller braucht (gibt es z.B. bei 
opencores.org) und dann muss man noch die richtigen Timingparameter 
finden...


> Oder geht es eleganter, bzw was ist gängige Praxis?

Wenn es eben geht, dann würde ich versuchen zeilenbasiert zu arbeiten. 
Die Zeile, die der MT9P031 dann sendet wäre virtuell durch die 
Blankpixel deutlich länger (2592 echte Pixel und einige 1000er 
Blankpinxel). Dann hätte der AVR eine Chance durch einen Interrupt pro 
fertiger Zeile diese dann aus dem FPGA zu laden. Wie schnell 
(MByte/sekunde) ist denn Deine AVR-Schnittstelle?

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nunja,

ich würde ein Mega128 nehmen und den mit 16MHz takten. Ich denke mal man 
kann 1MB an Geschwindigkeit bekommen (über den Datendurchsatz hab ich 
mir keine Gedanken beim AVR gemacht). Daher könnte zeilenbasiert 
fehlschlagen.
Schöner wär es dem AVR alle Daten vorzukauen und ihm diese parallel zu 
füttern.

Den AVR würde ich auch nur nehmen um eine SD-Karte anzusprechen bzw 
einen Ethernet-Controller anzusteuern, welcher die Daten dann 
(gemütlich) per UDP weiter sendet.

Im Grunde genommen möcht ich einfach eine Art DigiCam-Bauen.

Was kostet so ein SDRAM und SD-Ram-Controller (hab ich das richtig 
verstanden das der RAM-Controller in den FPGA geproggt werden kann)?

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Arndt,

die Anbindung des Sensors an den Blackfin interessiert mich sehr. Ich 
nehme an, daß Du das per PPI gemacht hast? Verkraftet der Blackfin denn 
die hohen Datenraten von 96MHz direkt ohne FPGA dazwischen? Mich würde 
eine Lösung interessieren, wo ich den Sensor direkt an den Blackfin 
anschliesse und dort ein wenig Bildverarbeitung mache und die Ergebnisse 
auf einem LCD darstelle. Hast Du den Blackfin mit Embedded Linux 
betrieben oder ihm die Firmware direkt auf den Leib geschrieben? Fragen 
über Fragen ...

Danke und Gruss aus HH
Hans-Christan

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe vor einigen Jahren mal einen Blackfin mit Daten eines 
CCD-Sensors befüttert. Soweit ich mich erinnern konnte lag die max. 
Geschwindigkeit des PPI-Ports bei halber Busgeschwindigkeit, d.h. 66MHz. 
Evtl. ist mein Wissen da aber auch überholt.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

kann die Aussage von 'Guest' bestaetigen, der PPI-Clock darf maximal 
Haelfte des Systemclocks sein. Habe bei eigenen Experimenten 
festgestellt, dass knapp am Limit ab und an FIFO-Fehler auftreten, das 
hat damit zu tun, dass die Daten bei voll ausgelasteter Bandbreite nicht 
rechtzeitig ins SDRAM geschoben werden koennen (v.a. unter uClinux bei 
Systemlast)
An Hans-Christian: Gleichzeitiges Einlesen und Ausgeben von Bildern mit 
Verarbeitung usw. geht nur auf dem BF561 (dual-PPI) und den 
BF54x-Systemen.
Habe selbst folgende Kameraloesungen 'erprobt':

1) standalone-Highspeed-Loesung mit optimierter 'Buffer queue'
2) uClinux mit Realtime-Erweiterung und buffer queue-Treiber
3) uClinux Referenzdesign (mit dem MT9P031) von blackfin.uclinux.org mit 
ppifcd-Treiber

Jede Variante hat so ihre Berechtigungen, Vorteile und Nachteile. Ganz 
gut faehrt man fuer den Anfang mit der uClinux-Loesung 3), die Daten 
gehn mal eben lecker per Ethernet raus oder per ffmpeg zu einem Movie 
codiert.
Wenn man keine Daten verlieren darf, gehts eher in Richtung buffer 
queue. Und wenns simpel sein muss und schnell, laesst man ev uClinux weg 
und hat alle Kontrolle uebers Speichermanagement.

Punkto Blackfin ist eins sehr wichtig, wenn man mal eben BV-Algorithmen 
portieren will: Der Blackfin geht in die Knie mit float. Also schoen 
alles im fractional (1.15)-Format rechnen :-)


Gruesse,

- Strubi

Autor: jugonser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn ich das richtig verstanden habe, gibt es bei der Kombination 
MT9P031 und CY7C68013A im Slave-FIFO (ohne FPGA), das Problem, dass der 
Bildsensor die Daten evtl. schneller liefert als der USB-Host sie 
abholen und verarbeiten kann.

Ich möchte vom PC aus Bild für Bild von der Kamera abholen und 
verarbeiten. Die Kamera soll also nicht selbstständig Bilder senden. 
Kann ich nicht einfach sobald die FIFOs voll sind, das Auslesen der 
Bilddaten anhalten und wenn die FIFOs wieder leer sind, dann das 
Auslesen fortsetzen? Vielleicht kann ich das Auslesen dadurch 
unterbrechen, indem ich den Takt wegnehme oder mit dem Trigger-Signal 
des MT9P031 arbeite

Gruß, Julius

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Julius,

den MT9P031 kannst Du auch triggern. Wenn ich mich jetzt nicht irre geht 
das sowohl per Triggereingag als auch per Kommando (I2C). Danach sendet 
der Sensor aber unbeirrt das komplette Bild mit dem Pixeltakt. Es gibt 
keine Flußkontrolle!

Ob mit Wegnahme des Sensor-Taktes eine Art Flußkontrolle zu 
bewerkstelligen ist, wage ich zu bezweifeln, da die Photosensoren 
weiterhin belichten (Rolling Shutter). Du wirst dann ein ungleich 
belichtetes Bild erhalten.

Nein, die beste Lösung scheint ein großer FIFO zu sein, der das 
ungleichmäßige Leeren der CY7C68013A-FIFOs seitens des PCs ausgleichen 
kann. Du mußt zumindest einige Bildzeilen zwischenspeichern können, am 
Besten natürlich das ganze Bild.

Gruss
Hans-Christian

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, da hat Hans-Christian leider recht.

Die Rolling-Shutter Sensoren haben meistens keine oder sehr kleine FIFOs 
integriert. Ein Anhalten bzw. ein Eingriff in das Sensortiming hat daher 
einen direkten Einfluss auf die Bildqualität (Ausnahme sind die Sensoren 
mit großem FIFO und JPEG Encoder, wie z.B. der MT9D131).

Die effektive Belichtungszeit und damit auch die Helligkeit jeder 
Bildzeile ergibt sich aus dem zeitlichen Abstand des Zeilenresets und 
der Zeilenauslese. Verändert man also das Timing bzw. hält den Sensor 
kurz bei der Auslese an, dann werden die Zeilen länger belichtet, die 
bereits resetet, aber noch nicht ausgelesen wurden. Das Ergebnis wäre 
ein Bild mit helleren/überbelichteten horizontalen Streifen.

Umgekehrt kann man den Effekt des Rolling-Shutters auch gut bei 
künstlicher Beleuchtung beobachten, wenn die effektive Belichtungszeit 
kein geradzahliges Vielfache der Flimmerfrequenz ist. Das Ergebnis sind 
wandernde horizontale Bildstreifen.

Viele Grüße
Arndt

Autor: jugonser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier eine kommerzielle Kameraplatine mit dem MT9P031 und 
CY7C68013A. Die Kamera besteht aus zwei aufeinander gesteckten Platinen. 
Die eine Platine enthält den Bildsensor, die zweite den CY7C68013A mit 
einem CPLD (XC9572XL).

Ein Speicherbaustein ist nicht zu sehen, das Datenblatt des CPLD sagt 
nichts über einen internen Speicher. Ich denke, der CPLD ist dafür da, 
um verschiedene Bildsensoren anzupassen. Das heißt, diese Kamera kommt 
ohne zusätzlichen FIFO aus. Ich frage mich, wie die das gemacht haben.

Ich habe das USB Protokoll mitgeschnitten und gesehen, dass die Bilder 
in 64 KByte große Blöcke übertragen werden. (Eine andere Kamera mit 
Speicher hat dagegene die Bilder in 3,5 MB und 1,5 MB Blöcke 
übertragen.)

Gruß, Julius

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Julius,

hast Du das Eval-Board von Micron?
Die Sache kann schon funktionieren, wenn man sich folgende Punkte bzw. 
Moeglichkeiten vor Augen haelt:

- Die horizontale Aufloesung ist kleiner als 1024: Dann geht eine
  Zeile komplett ins FIFO des FX2 (Cypress)
- Die Pixelfrequenz ist langsam genug, dass der FX die Daten rauskriegt 
- mit eingerechneten Unterbrechungen auf dem USB 2.0
- Die ganze Geschichte laeuft sowieso im "isochronous" mode und high 
speed

Genau hab ich's nicht nachgerechnet, aber wenn du isochrone Transfers 
"high speed" annimmst, gehn die Daten unter obigen Annahmen ev. 
fehlerfrei ohne Zeilenpufferung raus.
Guck' dir am besten mal das Thema "Frames, Microframes, isochronous 
transfer" im FX2-Manual an.
Allerdings wuerde ich fuer ne eigene Anwendung dem Ding ein FPGA 
spendieren, bei Reichelt gibts die fuer'n paar Euro auch im loetbaren 
Gehaeuse. Bis du dann deine Software so optimiert hast, dass alles ohne 
Zeilen-FIFO funktioniert, gehen bestimmt ein paar Stunden drauf.
Wenn Du Pech hast, mag dein Mainboard-Chipsatz naemlich den Iso-Mode 
nicht, bzw. hat Timing-Probleme (alles schon gesehen).
Ahja, und der Vorteil von einem FPGA: 'Teure' Algorithmen wie Bayer nach 
YVUV kann man spaeter auch mal in Hardware giessen.

Wenn Du prototypen willst:
Hab letztens ein FPGA-Board von CESYS in die Finger bekommen, da ist ein 
FX drauf und genuegend Expansions-Pins um mal eben rumzuspielen. Nennt 
sich "efm01", die Software scheint mir ziemlich ausgereift (und laeuft 
unter Linux).

Gruss,

- Strubi

Autor: jugonser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Strubi,

danke für die Antwort. Die horizontale Aufloesung des Boards, das ich 
hier habe, beträgt 2592 Pixel.

Brauche ich zu dem FPGA nicht auch noch einen extra Speicherbaustein 
oder ist der in dem FPGA integriert?

Wenn man ein Speicherbaustein verwendet, dann kann man doch "nur" 
mehrere Zeilen zwischenspeichern. Kann es nicht trotzdem sein, dass der 
Host die Daten nicht schnell genug abholt und die Daten überschrieben 
werden von den nächsten Zeilen?

Wie funktioniert generell die Synchronisation, wenn in den Speicher 
geschrieben und ausgelesen wird?

Gruß, Julius

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Julius,

den Extraspeicher brauchst Du nur dann, wenn Du mehr als nur einige 
Zeilen zwischenspeichern willst. Du brauchst für eine Zeile (wenn man 
faul und speicherintensiv programmiert) 4 BlockRAMs (gilt für Lattice, 
wie auch für Xilinx). Wenn sich etwas mehr Mühe gibt und die Datenbits 
ideal verteilt, kommt man auch mit 2 BlockRAMs hin.

Damit Du mit dem Syncen keine Probleme bekommst, würde ich mit min. 2 
unabhängigen Zeilenspeichern arbeiten (einer speichert die aktuelle 
Zeile, der andere wird vom µC ausgelesen).

Kleine FPGAs mit mehr als 8 BlockRAMs:
XC3S200 (Xilinx)
ECP2-12 (Lattice)
XP2-5 (Lattice)

Damit die Auslese auch zeitig funktioniert und der µC nicht überfordert 
wird, muss man die horizontalen Blanks des Sensors entsprechend 
vergrößern (eine Registereinstellung im Sensor). Maximal 4095 Blanks 
sind möglich.

@Hans-Christian
Die Blackfinlösung war auf den "Leib" des Blackfins geschrieben, so wie 
es im SDK von Avnet auch gemacht wurde. Schöner ist es auf einem Kern 
die Applikation und auf dem anderen Kern Linux laufen zu lassen. Als 
Eingangsport kommt nur der PPI-Port in Betracht, die Einlese wird hier 
dann auch zeilenweise organisiert, um die schnellen DMA-Kanäle im L1 
nutzen zu können. Da der PPI ja auch nicht die 96MHz kann, benutzen wird 
vor dem PPI-Port häufig noch ein kleines FPGA. Strubi hat in dem Gebiet 
aber deutlich mehr Erfahrung als ich ;-)

Viele Grüße
Arndt

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Arndt,

vielen Dank für Deine Ausführungen. Mein nächstes Projekt sieht so aus, 
dass ich einen MT9N001 (9MPixel) an einen Blackfin anschliessen und die 
Bilder dann per Ethernet und/oder USB2.0 an einen PC senden möchte. Der 
Blackfin soll dann später mal so Sachen wie Verschlüsselung oder 
Komprimierung der Bilddaten machen. Ich habe mir dazu gerade so ein 
BF533 STAMP-Board besorgt. Schaffe ich das mit uCLinux und nur einem 
Kern? Um Geschwindigkeit geht es mir zunächst nicht, nur um die 
Sicherheit, alle Pixel auch zu bekommen.

Grüße aus HH
Hans-Christian

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe mal mit der SMX-155 von Sumix rumgespielt. Soweit ich weiß hat 
diese Kamera ebenfalls nur einen USB Baustein und einen Bildsensor. Bei 
Vollaufllösung lief alles wunderbar. Sobald man das Bild kleiner gemacht 
hat ist die Framerate in der Keller gegeangen. Maximal waren 200fps 
möglich. Egal wie klein man das Bild gemacht hat.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hans-Christian,

>
> vielen Dank für Deine Ausführungen. Mein nächstes Projekt sieht so aus,
> dass ich einen MT9N001 (9MPixel) an einen Blackfin anschliessen und die
> Bilder dann per Ethernet und/oder USB2.0 an einen PC senden möchte. Der
> Blackfin soll dann später mal so Sachen wie Verschlüsselung oder
> Komprimierung der Bilddaten machen. Ich habe mir dazu gerade so ein
> BF533 STAMP-Board besorgt. Schaffe ich das mit uCLinux und nur einem
> Kern? Um Geschwindigkeit geht es mir zunächst nicht, nur um die
> Sicherheit, alle Pixel auch zu bekommen.

Das geht bestimmt, wenn Du den Pixelclock auf ca. 30-40 Mhz gedreht 
kriegst. Haengt von deiner Bildrate ab.. ev. gehts auch schneller fuer 
Einzelbilder mit dem ppi_fcd-Treiber. RAM hat das BF533 STAMP ja 
genug...
Ach, da faellt mir grade ein: Bis Rev. 0.3 muss man ein paar Tricks 
benutzen, da gibt's ne unartige Anomalie, die die oberen 64 MB betrifft. 
Kurz gesagt, kann letztere das Kernel nicht nutzen, Du kannst aber den 
Treiber dazu vergewaltigen, dass er den Videobuffer da reinlegt 
(manchmal hat physikalische Adressierung seine Vorteile :-) )

Gruss,

- Strubi

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ha, bevor ich's vergesse, ein kleiner Anhang:

>
> - Die horizontale Aufloesung ist kleiner als 1024: Dann geht eine
>   Zeile komplett ins FIFO des FX2 (Cypress)

Das war Quatsch! Habe gerade im Experiment festgestellt, dass mit der 
richtigen Konfiguration des FX2 auf einen Schlag 2048 Bytes in den 
Puffer gehen: Stichwort Quad-Buffering (4x 512 bytes).
Damit aendert sich natuerlich einiges, und die Chance, ein Bild 
fehlerfrei uebertragen zu bekommen, duerfte steigen.

Gruss,

- Strubi

Autor: Julius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

noch eine Frage zur Belichtungszeit: die korrekte Belichtungszeit möchte 
ich auf dem PC berechnen. Kennt jemand einen Algorithmus dafür?

Wie wäre es damit: ich berechne den durchschnittlichen Helligkeitswert 
h(AvgIst) eines Bildes. Bei einem Grauwertbild wäre der optimale 
durchschnittlichen Helligkeitswert h(AvgSoll)=127. Dann ist der Faktor, 
mit dem ich die Belichtungszeit multipliziere h(AvgSoll)/h(AvgIst). Ist 
das OK?

Gruß, Julius

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Strubi,

Ich betreibe meine Sensoren (Aptina und Omnivision) derzeit alle im 
Bulk-Modus. Meistens klappt das auch ganz gut, jedoch bei einigen 
Rechnern habe ich Bildstörungen aufgrund der fehlenden FIFOs.

Ich würde gerne mal die isochroner Übertragung probieren, jedoch 
schlugen alle Bemühungen dahingehend bislang fehl. Hast Du da 
Erfahrungen? Was muß ich beachten? Ich habe mir sagen lassen, daß ich 
die bereitgestellte Bandbreite auch exakt füllen muß!?

Mein BF533-Board hat die Revision 1.1, da habe ich wohl Glück gehabt.

Gruss
Hans-Christian

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Hans-Christian,

bei dem isochronen Kram hab ich mir auch mal ne blutige Nase geholt...
Hab damals mit der libusb (> v1.0!) und dem FX rumgefrickelt, und hatte 
KEINEN Spass. Habs dann damals auch geknickt, da ich keinen 
Logic-Analyzer zur Hand hatte und es auch mit Bulk klappte. In der Firma 
(ne Weile her) hatten wir ne Kameraloesung, die machte aber mit diversen 
Chipsaetzen Probleme.

Ich meinte mit der 0.3 die Chip-Revision, das v1.1 Board sollte aber 
(hoffentlich) nen 0.3er-Chip draufhaben. Mit dem 0.2er gabs zuviele 
garstige Anomalien, uClinux ist darauf nich mehr wirklich unterstuetzt.
Ab rev0.4 ist beim BF533 das Cache-Problem mit den oberen 64MB beseitigt 
(beim BF537 schon ab rev0.3).

Hoffe, das hilft dir weiter,

Gruesse,

- Strubi

Autor: Julius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Strubi,

laut der technischen Referenz des FX2 (Cypress) ist der FIFO sogar 4 KB 
groß. Das heißt doch, dass bei einem 5 MPixel Sensor (2592 x 1944) auf 
jeden Fall eine komplette Zeile in den FIFO passt?

Wie würdest du den FIFO konfigurieren (single, double, triple oder quad 
buffering)?

Julius

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Julius,

leider muß ich Dich enttäuschen. Im Bulk-Mode haben die 4 FIFOS nur 512 
Byte Länge!

Gruss
HCW

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An Arndt:

Ich habe weiter oben mal aufgeschnappt, dass Du moeglicherweise auch 
schon mit dem MT9D131 experimentiert hast?
Ich versuche grade, dem Ding einen vernuenftigen JPEG-Stream zu 
entlocken. Habe mal den Factory Bypass-Modus, wie auch den Sequencer 
ausprobiert, und bin nicht wirklich gluecklich geworden. Ich benutze den 
Spoof-Mode um ganz normal aussehende Frames rauszuclocken. Nur stehen 
keine JPEG-Daten drin. Weisst Du nen Trick?

Gruss,

- Strubi

Autor: Julius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hans-Christian,

was meinst du zu folgendem Vorschlag: ich verwende zwei Endpunkte, um 
eine Bildzeile (= 2592 Bytes) zu übertragen. Zum Bespiel EP 2 und EP 6 
mit jeweils 4 x 512 Bytes. Zuerst schreibe ich den Puffer von EP 2 voll 
(= 2048 Bytes), dann schreibe ich die restlichen Bytes der Zeile (= 544 
Bytes) in den Puffer von EP 6. Könnte das funktionieren?

Gruß, Julius

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Julius,

das wuerde ich nicht machen, da du fuer die EPs die FIFO_ADR-Pins 
umschalten musst, dabei gehen dir wieder wertvolle Zyklen verloren.
Du koenntest eher Glueck haben, dass eine komplette Zeile trotzdem 
rausgeht, weil beim Quad-Buffering waehrend dem Fuellen schon wieder 
Puffer geleert wurden.
Aber eben: Glueck. Wuerde dir nach wie vor das FPGA zur Pufferung 
empfehlen. Ist uebrigens nicht allzu wild, mit z.B. den Xilinx-Tools ein 
FIFO zu generieren. Und ev. willst Du ja spaeter auch etwas 
Vorverarbeitung machen...

Gruss,

- Strubi

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Julius,

ich habe jetzt das Datenblatt nicht vor mir, aber ich glaube, daß die 
Endpoints sich die FIFOs teilen müssen. Insgesammt stehen 4kByte FIFO 
zur Verfügung. Ob Du 2k für jeweils EP2 und EP6 reservieren kannst, 
weiss ich nicht.

Ich würde auch den FIFO empfehlen. In einer meiner Kameras habe ich das 
leider nicht gemacht und habe nur Ärger mit dem Timing und den 
Übertragungsstörungen.

Gruss
Hans-Christian

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
An Strubi:
Hast Du das Devboard von Micron/Aptina ?
In den Beispielsettings sind einige gute Einstellungen, mit 
unterschiedlichen Möglichkeiten der JPEG Nutzung. Standardmäßig wird das 
Devkit so konfiguriert, dass es einen "normalen" JPEG Stream liefert.

An Hans Christian:
Die gute Nachricht ist, dass der MT9N001 ein Zeilenfifo implementiert 
hat. Damit kannst Du die Sensordaten mit einer anderen Geschwindigkeit 
auslesen, als diese aus der Matrix geliefert werden.
Die bedenkenswerte Nachricht ist die benötigte Rechenleistung. Wieviel 
fps benötigst Du denn?
Für ein schönes RGB Farbbild benötigt man ca. 40 Operationen (nur grobe 
Schätzung, mit Debayer, CCM, AE und AWB) pro Pixel. Für ein Bild sind 
das dann ca. 380MOPs . Die Operationen "leben" (bzw. dann hat man die 
maximale Performance) im Blackfin davon, dass alle relevanten Daten im 
L1 verfügbar sind, dass erfordert in der Regel ein gutes DMA Management.

Viele Grüße
Arndt

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Arndt,

vielen Dank für den Hinweis mit dem Zeilen-FIFO. So genau habe ich das 
Datenblatt noch nicht durchgekaut.

In meiner Applikation habe ich zum Glück konstante Bedingungen. Ich 
beleuchte eine geschlossene Szene mit konstantem NIR und brauche daher 
kein Weißabgleich, Demosaicing, Exposure-Control etc. Ich muß wenige 
Bilder/s in voller Auflösung übertragen und möglichst viele 
subgesampelte Bilder (Skipping oder Binning). Vielleicht kann ich die 
Auswertung der kleinen Bilder von dem Blackfin übernehmen lassen. Der 
Blackfin wird dann noch solche Sachen wie Encryption oder Compression 
der großen Bilder übernehmen müssen, die dann per USB2.0 oder Ethernet 
an den PC gehen sollen.

Grüße aus dem derzeit weißen Hamburg
Hans-Christian

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Arndt,

Ich habe in der Tat das 'Head board' vom Aptina Devkit, allerdings ohne 
das USB-Geraffel, da ich das Ding direkt am Blackfin anhaenge.

Habe inzwischen mal den Logic Analyzer zu Hilfe nehmen muessen, es 
scheint so, als ob der Blackfin den irregulaeren (teils gated) 
Pixelclock nicht mag. Darum bekomme ich auch offensichtlich Muelldaten 
im JPEG-Mode. Etwas besser sieht's aus, wenn ich nur das Testpattern 
codiere, allerdings sind auch da die Daten noch "Bogus". Fuerchte, ich 
muss ein FPGA dazwischenhaengen..

Gruss & danke,

- Strubi

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Strubi,

das USB-Geraffel ist der Trick. Es enthält sehr viele INI-Files 
(Beispielsettings für die Sensoren) für jeden einzelnen Sensortyp und 
Revision. Bei Auslieferung ist bereits eine große Sammlung von INI-Files 
drinn, für speziellere Sensoren muss man speziell bei Aptina anfragen, 
meistens braucht man dann ein NDA (Geheimhaltungsvereinbarung) direkt 
mit Aptina.

An Hans-Christian:
Das hört sich ja machbar an ;-)
Viel Erfolg

Viele Grüße
Arndt

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Arndt,

Ich habe ansich die ganzen Sachen vom Devkit, habe den Beispielcode auch 
mehr oder weniger 'embedded' umgesetzt. Aber irgendwo steckt's noch im 
Detail.
Huffman-Tabellen sind alle in Ordnung, aber der JPEG decoder verschluckt 
sich schlussendlich an den Daten - premature end. Ich fuerchte, dass der 
Blackfin an irgend einem Punkt nicht die richtigen Daten bekommt (soweit 
vermutet per Test Patterns). Im Non-JPEG-Modus kommen alle Daten richtig 
rein und sind schluessig. Im JPEG-Modus (ohne Testpattern) stimmt ab und 
an das Ende des Datenstroms nicht wirklich mit dem Length-Register 
ueberein.
Wird also aeusserst spassig, diese Events genau zu triggern und zu 
finden..

Gruss,

- Strubi

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Julius,

wir haben hier gerade den MT9P031 über einen FPGA/SDRAM an den FX2 
angeschlossen und es läuft ganz vorzüglich trotz voll ausgelastetem 
Rechner. Keine Bildstörungen mehr bei voller Framerate! Es lohnt 
wirklich, einen FIFO dazwischen zu schalten.

Gruss
Hans-Christian

Autor: Hans-Christian (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Moin Moin,

so, nun da der MT9P031 ja läuft habe ich folgendes Problem. Ich habe am 
oberen Bildrand so ein komisches Bildrauschen in den hellen 
(übersteuerten?) Partien. Es ist dabei unerheblich, ob ich die volle 
Auflösung oder sonstwo ein Teilbild aufnehme. Das Rauschen tritt immer 
in den ersten paar Zeilen auf. Hat jemand soetwas schon beobachtet und 
evtl. behoben?

Danke und Gruss
Hans-Christian

Autor: Julius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hans-Christian,

was für einen FPGA/SDRAM Baustein hast du benutzt?

Auf dem DevBoard von Aptina wird ein VIRTEX-II XC2V250FG256 (ohne extra 
RAM) eingesetzt.

Gruß, Julius

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Julius,

wir haben das NEXYS2-Board von Digilent verwendet:

http://digilentinc.com/Products/Detail.cfm?NavTop=...

Es mußten dazu hier und da ein paar Fädeldrähte gezogen werden. Seit ein 
paar Tagen läuft auch der MT9N001 (9MPixel) an dem Board :-)

Gruss, Hans-Christian

Autor: Dennsi Willja (googoo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hans Christian,
hast du vielleicht Schnappschüsse, die du mit uns teilen willst?
Ich würde gerne mal die Bildqualität beurteilen von dem Sensor

Autor: Hans-Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Dennsi,

Momentan habe ich die Kamera nicht zur Verfügung. Sobald sich das 
ändert, kann ich ein paar Bildchen für Dich machen.

Gruss
Hans-Christian

Autor: Dennsi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wär ne super Sache
(Ein Bild könntest du ja evtl von der Schaltung selbst machen, mit nem 
Spiegel;)
wie erzeugst du die 3.3 (3.6*) Volt für den Lichtsensor....
hast du beobachtet, ob die Qualität der Betriebsspannung die 
Bildqualität beeinflusst?
Habt ihr irgendwelche Pixelfehler (evtl durch Bitfehler in der 48Mhz** 
Datenübertragung?)

** `??  *?
Gruß Dennsi

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt wo Aptina an ON verkauft wird ist es schwierig ein Datenblatt zu 
bekommen. Gibt es da einen Link?

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, das ist nur die gekürzte Version, da fehlen die 
I2C-Registerzuordnungen. Das "richtige" Datenblatt ist 60 Seiten lang 
und habe ich hier gefunden:
http://data.datasheetlib.com/pdf1/122/7/1220715/ap...

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Hast du das Aptina Devkit, oder eine fertige Kamera, oder willst selber 
was bauen? Der Sensor ist ja schon etwas in die Jahre gekommen...
Ich habe hier noch ein Embedded Linux Framework für ne Latte 
Aptina-Sensoren etc., das ansich auch unter Windows über Cypress FX2 
(Aptina Devkit) lief, aber wegen div. USB-Querelen nicht mehr 
unterhalten wurde. Falls Du Lust hast, Dir den Schuh anzuziehen, könnte 
man über Codesharing reden :-)

Die Kameras kannst du über netpp fernsteuern (sowas wie GenICam), z.b. 
aus Python raus.

Gruss,

- Strubi

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das Teil hier:
https://www.onsemi.com/PowerSolutions/evalBoard.do...

Mit dem Board will ich die Ansteuerung des CCD-Chips erarbeiten, da 
Aptina keinerlei Unterstützung dafür liefert (ON auch nicht). Letztlich 
will ich eine sehr kleine Kamera mit einem Xilinx Zynq machen auf der 
ich Code für eine Bildverarbeitung laufen lassen kann.

Ich muss also den Speicherkontroller im Zynq so konfigurieren dass ich 
die CCD-Daten direkt in den ARM-Speicherbereich reinpacke und von dort 
aus per Pointer und Offsetadresse Zugriff habe.

Ich muss also alles BareMetal selber hochziehen da ich keinerlei Code 
gefunden habe. Was schon viel Zeit sparen würde wäre der I2C-Zugriff 
wenn da jemand getesteten Code hätte. Und ja - Tipps und Tricks sind 
natürlich unbezahlbar!

Viele Grüße!
 Marko

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte mich früher immer bei Aptina Registriet und konnte da auch die 
Datenbläter runterladen. Leitder gibt es die Seite nicht mehr.

Es gibt den deutschen Händler Framos. Über die kann man die Sensoren 
kaufen und dort kann man auch die Datenblätter bekommen. Es kann sein 
das Du da noch ein NDA unterschreiben must. Dies ist leider bei einigen 
Herstellern wie Sony der Fall.

https://www.framos.de/products/de/sensors/area-sen...

Viel schlimmer ist dann später die Doku für den Sensor selber. Der hat 
sehr viele Register die überhaupt nicht beschrieben sind.

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Datenblätter bekommt bei OnSemi recht problemlos.
Die Sensoren werden auch von Arrow vetrieben.
Wir haben mit diesem Sensor recht viele Kundenentwicklungen gehabt. Er 
ist im Gegensatz zu den neueren Sensoren recht harmlos.

Order man ein vollständiges Kit, dann hat die Devware auch ein 
vollständiges Registerfile des Sensors. Bzw. die Devware legt für diesen 
Sensor im Installationsverzeichnis entsprechende Files an. Ist ein XML 
Format und enthält alle "non confidential" Register.

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich habe auf Nachfrage den Schaltplan für das Eva-Board gekriegt und 
da stehen an Pin Namen dran, die im offiziellen Datenblatt "NC" sind.

Bei dem Eva-Board und der Doku habe ich das Gefühl, dass das ein 
Abfallprodukt der eigenen Produktentwicklung bei Aptina war.

Der Sensor ist aber gesetzt und ich muss mit ihm leben. Ich hatte 
gehofft dass mir vorhandener Source-Code den Weg etwas beschleunigt.

Autor: Arndt Bußmann (Firma: Helion GmbH) (bussmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn das ein offizielles Firmenprojekt ist, helfen wir gerne weiter. Wir 
haben in der Regel alle Sensorunterlagen (noch) und können auch 
entsprechenden Support geben.

VG
Arndt

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arndt:
Wir haben nur das Kamerabord ohne die Mutterplatine mit dem FPGA-Teil. 
Von daher ist uns natürlich auch keine Software geliefert worden.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marko R. schrieb:
> Ich habe das Teil hier:
> https://www.onsemi.com/PowerSolutions/evalBoard.do...
>

Das ist, soweit ich sehe, das olle Headboard ohne das USB-Geraffel.

> Mit dem Board will ich die Ansteuerung des CCD-Chips erarbeiten, da
> Aptina keinerlei Unterstützung dafür liefert (ON auch nicht). Letztlich
> will ich eine sehr kleine Kamera mit einem Xilinx Zynq machen auf der
> ich Code für eine Bildverarbeitung laufen lassen kann.
>

Wenn auf dem Zynq Linux läuft, kannst du den "Videoserver" anpassen. 
(http://section5.ch/vkit, da ist auch der P031 mit unterstützt). Hat 
schon jemand gemacht, aber "custom" mit proprietären Treibern, d.h. 
nicht weiterverwertbar.

> Ich muss also den Speicherkontroller im Zynq so konfigurieren dass ich
> die CCD-Daten direkt in den ARM-Speicherbereich reinpacke und von dort
> aus per Pointer und Offsetadresse Zugriff habe.
>
> Ich muss also alles BareMetal selber hochziehen da ich keinerlei Code
> gefunden habe. Was schon viel Zeit sparen würde wäre der I2C-Zugriff
> wenn da jemand getesteten Code hätte. Und ja - Tipps und Tricks sind
> natürlich unbezahlbar!
>

i2c-Ansteuerung und der ganze Kram ist im videoserver schon drin. Was du 
nur noch brauchst, ist ein v4l2 Kerneltreiber. Meines Wissens gibt es da 
von Xilinx was, aber nicht mit mords Performance. Es sollte ein Treiber 
sein, der die USERPTR-Methode kann (zero-copy).

In die videoserver-FIFO-Queue kannst du dann OpenCV usw. einschleifen.

Übrigens: Es ist eine CMOS-Kamera, keine CCD.

Marko R. schrieb:
> Bei dem Eva-Board und der Doku habe ich das Gefühl, dass das ein
> Abfallprodukt der eigenen Produktentwicklung bei Aptina war.

Das Ding ist noch aus Micron-Zeiten, da hat sicher inzwischen dreimal 
die FAE-Crew gewechselt. Der P031 geht eigentlich noch von der Doku her.
Die ollen Photobit-Relikte mit eingebauten 68xx sind noch viel 
schlimmer..
Das Problem ist, dass ON sich offenbar nur noch auf vertikale Märkte 
fokussiert.

Grüsse,

- Strubi

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi:
Super Info! Ich werde sehen wie viel ich davon für unseren 
Baremetal-Code verwenden kann. Ohne OS ist man sein eigener Herr, muss 
es dann aber auch sein.

Jetzt muss ich erst mal ein bisschen Code häcken. Für Hinweise bin ich 
natürlich immer dankbar.

Marko

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Datenblatt spricht leider immer nur über die RGB-Ausgabe, was sich 
auf die MT9P031|12STC bezieht, ich habe aber einen MT9P031|12STM  (M - 
wie monocrom).
Kann ich einfach die 12 Bit als 12-Bit-Wort Helligkeitswert 
interpretieren?

Viele Grüße!
 Marko

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja. Der P031 kann RGB nur als Bayerpixel.

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vom P031 gibt es die Monocrom-Version und genau die liegt mir als 
Hardware vor:

http://www.onsemi.com/PowerSolutions/product.do?id...

Das Datenblatt beschreibt nur die RGB-Version, schweigt sich aber über 
die Monocrome aus. Ich vermute mal dass sie die vollen 12 Bit für den 
Monocromen Wert als u12 nutzen?

Autor: Zoom Zoom (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Da werden nur Farbfilter vor die Pixel gepackt, sonst ändert sich am 
Sensor nix.

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, dass heißt dass die 5 MPixel jedes "Graupixel" zählt, wenn man aber 
sieht das ein "Farbpixel" aus 4 Einzelpixeln besteht dann hat man nur 
noch einen 1,25MPixel-Farbsensor?

Autor: Zoom Zoom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jein, beim Debayering kommt ein Bild mit der vollen Auflösung raus.
Die Farbinfo ist dabei aber interpoliert.

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, also jeder "Pixel" ist die Farbsumme der ihn umgebenden Pixel? 
Heißt, dass bei meinem MonoCrom-Teil letztlich alle Pixel gleichwertig 
sind?

Wer aber ein Teil mit Farbe hat muss sich die Farbe zusammenrechnen aus 
dem Umgebungspixeln. Farbe und MonoCrom kommt auf die gleiche Auflösung, 
nur dass die Farbe einen Filter über 1-Pixelweite gesehen hat?

Autor: Zoom Zoom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marko R. schrieb:
> OK, also jeder "Pixel" ist die Farbsumme der ihn umgebenden Pixel?

Da gibts zig verschiedene Verfahren. Manche einfach und nicht so gut und 
bessere aber aufwändigere.


> Heißt, dass bei meinem MonoCrom-Teil letztlich alle Pixel
> gleichwertig sind?

Jep.

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK - geschnallt.  Wäre schön gewesen wenn das Datenblatt ein Wort über 
MonoCrom verloren hätte. Letztlich macht das aber alles total Sinn.
Ich code mal weiter :-)

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marko R. schrieb:
> OK, dass heißt dass die 5 MPixel jedes "Graupixel" zählt, wenn man aber
> sieht das ein "Farbpixel" aus 4 Einzelpixeln besteht dann hat man nur
> noch einen 1,25MPixel-Farbsensor?

Kann man eben so nicht wirklich sagen. Die Frage ist immer, was du aus 
dem Bayerpattern machst, d.h. ne Frage der passenden Interpolation. Wenn 
du YUV422-Ausgabe berechnest, interpolierst du anders als bei raw RGB. 
Im Endeffekt ne Sampling-Frage (Auflösung versus Moiré). Gab da mal eine 
Latte Testbilder von Kodak und ne nette Seite zu, finde sie aber gerade 
nicht.

Autor: Arndt Bußmann (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Was beim P031 allerdings hinzukommt ist, dass dieser Sensor ursprünglich 
als Farbsensor geplant wurde. Dies äußert sich darin, dass auch in der 
monochromen Version 4 analoge Verstärkerpfade existieren. Dies führt bei 
einem monochromen Sensor zu einem leicht gecheckten Bild, da diese 4 
Kanäle (die ursprünglich einem 2x2 Pixel Bereich (rot, grün1, grün2, 
blau) entstammen) ein leicht unterschiedliches analoges Gain "sehen". 
Dies liegt in der Herstellungstechnik des Sensors begründet, die leichte 
Abweichungen bei den analogen Verstärkern erzeugt.

Autor: Marko Rocznik (dr_marko_rocznik) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das Problem dass eine einmal konfigurierte PLL kein zweites mal 
konfiguriert werden kann. Gibt es einen Workaround außer PowerDown?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.