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
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
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
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
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
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
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/mt9p031i12stm/#overview 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
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
Schau mal hier nach: http://www.digikey.com/scripts/DkSearch/dksus.dll?Cat=2622039&keywords=MT9P031I12STM Gruß, Julius
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!
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!
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.
Kenne den speziellen Sensor nicht, aber das ist nur der I2C Bus zum KONFIGURIEREN des Sensors und nicht zum Auslesen...
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.
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
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
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!
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
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?
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?
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)?
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
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.
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
Hallo Julius, leider muß ich Dich enttäuschen. Im Bulk-Mode haben die 4 FIFOS nur 512 Byte Länge! Gruss HCW
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
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
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
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
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
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
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
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
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
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
Angehängte Dateien:
-
Rauschen.PNG
6,8 KB
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
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
Moin Julius, wir haben das NEXYS2-Board von Digilent verwendet: http://digilentinc.com/Products/Detail.cfm?NavTop=2&NavSub=451&Prod=NEXYS2 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
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
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
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
Jetzt wo Aptina an ON verkauft wird ist es schwierig ein Datenblatt zu bekommen. Gibt es da einen Link?
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/aptina-mt9p031i12stm_154c74ff1b.pdf
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
Ich habe das Teil hier: https://www.onsemi.com/PowerSolutions/evalBoard.do?id=MT9P031I12STMH-GEVB 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
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-sensors.html?111Manufacturer=ON+Semiconductor&___store=de&limit=32 Viel schlimmer ist dann später die Doku für den Sensor selber. Der hat sehr viele Register die überhaupt nicht beschrieben sind.
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.
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.
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
Arndt: Wir haben nur das Kamerabord ohne die Mutterplatine mit dem FPGA-Teil. Von daher ist uns natürlich auch keine Software geliefert worden.
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
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
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
Vom P031 gibt es die Monocrom-Version und genau die liegt mir als Hardware vor: http://www.onsemi.com/PowerSolutions/product.do?id=MT9P031&pdf=Y 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?
Da werden nur Farbfilter vor die Pixel gepackt, sonst ändert sich am Sensor nix.
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?
Jein, beim Debayering kommt ein Bild mit der vollen Auflösung raus. Die Farbinfo ist dabei aber interpoliert.
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?
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.
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 :-)
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.
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.
Ich habe das Problem dass eine einmal konfigurierte PLL kein zweites mal konfiguriert werden kann. Gibt es einen Workaround außer PowerDown?
Der MT9P031 läuft :-) Wie kritisch ist eigentlich die VDD_IO Spannung? Das Datenblatt sagt max 3.1V, meine Digitalspannung ist aber 3.3V. Kann ich VDD_analog = 2.8V und VDD_IO = 3.3V machen?
Glückwunsch Bzgl. der höheren Spannung ist halt zu beachten, dass die Schutzstrukturen leitfähig werden und unter Umständen überhitzen können. Wir haben den Sensor immer nur mit 2.8V benutzt.
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.