Announcement: there is an English version of this forum on moin, ich hab ein paar infos zu dieser kamera von pollin: http://www.pollin.de/shop/dt/NTA4OTE0OTk-/Haustechnik/Sicherheitstechnik/Kameras/Farbkamera_Modul_SAMSUNG_AU_85B.html eigentlich hatte ich vor die in mein handheld einzubauen aber weiss nicht... mir gefaellt nicht wie man die daten abholt (clock wird von der kamera vorgegeben) usw... egal... datenblaetter ueber die kamera ansich und dem chip sind dabei... das datenblatt vom chip zu bekommen war ziemlicher stress die firma ist pleite anscheinend (hab webarchive durchgewuehlt usw)... vielleicht kann ja jemand damit was anfangen... lg...
Aber an sich spricht ja nichts gegen die Kamera oder? Ich meine für den Preis ist die Leistung unglaublich, man betrachtevor allem die Auflösung. Hab ich den Haken an dem Angebot nicht gesehn oder gibt es keinen? Denn dann würde ich mir auch gleich welche holen ;-)
ich find das ding klasse... passt nur nicht so recht bei mir in dem projekt... werd mir aber auch noch welche holen... fuer den preis was sie bietet kann jpg, ppl drauf fuer die mainclock und ziemlich viel was man am bild ansich noch einstellen kann schon super...
aber wie gesagt... wenn man ein bild abholen will gibt die kamera den vsync , hsync und pixelclock vor (vielleicht normal bei kameras hab bisher nur diese mir mal angesehen). ok die pixelclock ist noch durch divider einstellbar... bist du zu langsam muss du die mainclock runterdrehen... da weiss ich aber nicht wie das bild dann aussieht weil dadurch ja auch das aufnehmen verlangsamt wird...
Hab in dem Bereich noch nichts gemacht, doch wenn man schon die Datenblätter hat wird das sicher! Auf welchen Controllern hattest du dir vorgestellt, diese Kamera zu verwenden? Welcher ist hier angebracht? Grüße Dennis
von der geschwindigkeit waere das kein problem gewesen bei mir... verwende nen pic32 mit 80mhz... haengt sehr davon ab welche mainclock man verwendet... aber der pll ist recht flexibel (sieht man auf seite 21 des chips) die pixelclock kann man vor oder nach dem pll abgreifen mit anschliessendem divider... sprich wenn man ne kleine mainclock nimmt kann man die durch den ppl ja wieder hochziehen... aber keine ahnung kenn die atmegas o.ä. nicht mach nur was mit dem pic32...
Okay, bestellt sind die Teile mal. Werd nur leider die nächsten Wochen nicht dazu kommen. Achja, sah gerade, dass es sicherlich noch lusig wird, die Kameras zu löten oder?
Kann man das JPEG-Bild per I2C auslesen? dan könnte man ja eine Bilig Digicam bauen. ;-) Cam>Atmega>SD
Laut dem Block-Schaltbild kannst du zwar Befehle per I²C senden, aber eben nur um dann über den Output Formatter Daten zu beziehen. Aber eine Kamera kannst du ja dann sicher trotzdem bauen, nur eben nicht mit einem ATmega(xx). Naja mal sehn, wenn die Teile da sind. Adapterplatinen machen und das Teil mal auf ein Steckbrett setzten.
bloed ist wie gesagt das abholen... einmal angestossen kommt alles auf ein mal... weil ein bild in voller groesse abzuholen in rgb 565 ist schon 3,7mb gross... oder man laesst pixel aus...denn brauch man aber keine 2 mp ;) ich hab zwar 16mb dram an meinem pic32 nur das schreiben wuerde zu lang dauern... wahrscheinlich kommt man nicht drumrum die mainclock abschaltbar zu machen sprich wenn man das volumen erreicht hat was man verarbeiten kann wegschreiben...und wieder aktivieren... moechte aber nicht wissen wie das dann aussieht... :) ich glaub nicht das die kamera das ganze bild speichern kann gibt sicher probleme bei bewegten bildern...
egon schrieb: > ich glaub nicht das die kamera das ganze bild speichern kann gibt > sicher probleme bei bewegten bildern... Da die Kamera JPEG komprimieren kann muss sie das Bild zwischenspeichern können.
die kompression von jpeg beinhaltet die einteilung a 8*8 oder 16*16 blocke und nur diese werden immer komprimiert... gut ich steck jetzt nicht ganz so tief in jpeg aber das ganze bild muss sie dazu nicht speicher halten denke ich...
egon schrieb: > die kompression von jpeg beinhaltet die einteilung a 8*8 oder 16*16 > blocke und nur diese werden immer komprimiert... > gut ich steck jetzt nicht ganz so tief in jpeg aber das ganze bild muss > sie dazu nicht speicher halten denke ich... Ich bin auch kein JPEG-Experte, aber m.M.n. müssen die (schon verlusthaft gekürzten) Frequenzkomponenten aller 8x8 Blöcke zusammen komprimiert werden. D.h. es der Speicher muss nicht das komplette unkomprimierte Bild halten sondern nur einen Teil davon.
Man muss die Daten rausschaufeln. Was man machen kann, man kann das Hsync mit etwas Delay für ein parallel->serial chip verwenden und dann die Daten mittels des SPI einlesen, dann können auch schwächere uC mithalten, eventuell kann man die Daten gleich der SD-Karte geben ohne die im uC zu speichern. Den Clock braucht man nicht abschaltbar, das geht mit den Sleep-Modus problemlos.
Nachtrag, zwei mal verzögertes Clock-out muss man mittels AND mit dem Hsync als SPI Clock verknüpfen, kann ev. auch mittels zwei Widerständen gemacht werden.
Für einen guten Bewegungsmelder bräuchte man ca 5-6K an Speicher, wenn das Datenpaket in die SD-Karte gespeichert wird. Ein Projekt was mich interessieren würde wäre eine 3D Kamera mit der Laufzeitmessung von IR Strahlung (IR-Filter raus, Tageslicht-Filter rein). Durch das genaue Timing der Belichtungszeit, 3x8Byte auf 4bit reduzieren 600x240 durch 4 = 300x120. Wenn man jetzt eine Kontrollfläche von xx Pixel einplant, welche durch das IR belichtet werden, damit 240x120 pixel übrigbleiben, dann sind das bei 4 bit ca 20K an Speicher für ein Bild. Ist zwar Patentiert, aber für Privat verwendbar. Mit einer logaritmischen Entfernungsmessung der 16 Entfernungswerte wäre das eine feine Sache.
Am besten wäre es, den Bilddaten-Stream direkt mit der Taktfrequenz in einen externen Speicherchip zu schieben, aus dem die Daten dann in Ruhe wieder gelesen werden können. Was für ein Speicher käme dafür in Frage ?
Mein Ansatz wäre auch die Daten sofort in ein SRAM zu schieben. Und für meine Zwecke wäre selbst ein reduziertes schwarz/weiß Bild gut genug. bei 1/4 der Auflösung und YCrCb 8 Bit modus, mit Überspringen des CrCb Teils wären das: 408*302 * 1Byte = ~121KB Die Kamera wäre immer noch günstiger als die meisten anderen Möglichkeiten, insbesondere wenn man Zusatzfeatures und mögliche Erweiterungen in der Zukunft betrachtet. Ich denke da an einen ARM Cortex-M3 mit 80mHz Takt und so 512K externen Speicher. Vielleicht gibts ja einen netten STM32 der dazu passt.
Als Speicher habe ich mal den IS66WV51216BLL herausgesucht, 1Mbyte bei 8bit. Was für einen Prozessor würde sich da anbieten, um eine low cost rs232 Kamera mit 2x SPI Interface zu realisieren. SPI muss nicht 2x vorhanden sein, wäre aber von Vorteil. USB, wenn fast gleicher Preis, gerne.
Ich habe mal eine CPU für das Vorhaben gesucht, als einzige Möglichkeit habe ich PIC18F8XjXX oder PIC18F9XJXX gesehen, also entweder Ethernet oder USB-Slave. 32Bit, da habe ich keinen gefunden, auch den PIC32 welcher zwar verlockend klingte war im Endeffekt aus dem Rennen. Hat jemand da eine Lösung die ich übersehen hatte ?
Chris schrieb: > Für einen guten Bewegungsmelder bräuchte man ca 5-6K an Speicher, wenn > das Datenpaket in die SD-Karte gespeichert wird. > Ein Projekt was mich interessieren würde wäre eine 3D Kamera mit der > Laufzeitmessung von IR Strahlung (IR-Filter raus, Tageslicht-Filter > rein). > Durch das genaue Timing der Belichtungszeit, 3x8Byte auf 4bit reduzieren > 600x240 durch 4 = 300x120. Wenn man jetzt eine Kontrollfläche von xx > Pixel > einplant, welche durch das IR belichtet werden, damit 240x120 pixel > übrigbleiben, dann sind das bei 4 bit ca 20K an Speicher für ein Bild. > Ist zwar Patentiert, aber für Privat verwendbar. Mit einer > logaritmischen > Entfernungsmessung der 16 Entfernungswerte wäre das eine feine Sache. Erklaer doch mal, wie du dir das vorstellst?
Wozu braucht man soviel Rechenpower ? Wenn der Datenstrom hardwaremässig vom Clocksignal in das SRAM geschoben wird, muss man die Aufnahme des Bildes mit dem externen Prozessor doch nur auslösen. Die anschliessende Verarbeitung der Daten im SRAM ist auch nicht zeitkritisch, wenn keine Videosequenzen benötigt werden.
Hmm .. denkt Ihr, man könnte zwei oder gar mehrere von den Schätzchen über die GPIOs eines STM32 auslesen und dabei noch eine brauchbare Framerate erhalten ? Ich habe zwar schon einige kleinere Spielereien mit den STM32 gemacht, aber bisher eben noch nicht so etwas. Mit den 72Mhz (iirc) des Chips sollte doch schon einiges machbar sein, oder ? Kann ein erfahrenerer Anwender eine Einschätzung dazu abgeben, wie viel Rechenleistung bei einem solchen Szenario verbrannt wird - oder konkret, wie viel CPU für die Weiterverarbeitung der Frames bleibt ? Danke für alle hilfreichen Antworten.
> Erklaer doch mal, > wie du dir das vorstellst? Timing der IR-Beleuchtung zur Verschlusszeit hin. Geht auf Laufzeitmessung des Lichtes hinaus. Z.B. fixes Timing einer IR-Kamera mit globalem shutter. Nun wird ein IR-PULS durch eine auswählbare Verzögerungsleitung, einfachheit halber 4x Mux mit Laufzeitdifferenzen auf der Platine oder an 4 verschiedenen Pins mit unterschiedlichen langen Leitungen der IR-Puls getriggert. Das macht man dann 4x hintereinander. Jedes Bild wird mittels Threshold auf 1bit gebracht und das Ergebniss ist dann eine 4bit Entfernungsmappe der Gegenstände mit fest definierten Entfernungen, zwar durch Threshold änderbar. Dies jetzt mit globalem Shutter. Diese Kamera hat einen rolling shutter, also braucht es ein paar Bilder mehr und das Timing ist nicht ganz so flexibel wie bei globalem shutter, sprich das Resultat muss aus mehreren Teilbildern zusammengebaut werden da unterschiedliche Teile des Chips zu unterschiedlichen Zeiteinheiten belichtet werden. Zur CPU. Der ausgesuchte PIC hat einen EMI (External Memory Interface) sowie einen EPP (external Parallel Port) welche durch manuelles Zusammenspiel (kein DMA, aber jeweils ein Buffer bei den beiden Interfaces) zusammenarbeiten können. Bei einer PIC32 CPU hätte ich auch ein externes Speicherinterface, jedoch müsste dann entweder ein externer Zähler her, wie auch bei den STM32 oder die Übertragungsgeschwindigkeit muss runtergesetzt werden da ansonsten alles über Interrupt geschehen müsste. Pic32 hätte den Vorteil daß durch die Komparatoren externe glue-logik gespart werden kann, der Zähler stört mich aber, da könnte ich gleich eine SD-Karte nehmen, wäre ein bis zwei externe Chips weniger. Bei 12fps und 30Mhz bei uxvga entspricht 48fps bei vga. Bei 25fps und VGA entspräche das 15.625 Mhz . Rechnung ist nur eine Schätzung und das Datenblatt muss genauer angesehen werden und das wären 64ns, also würde ein Speicher von 55ns ausreichen.
ein externer zaehler muss beim pic32 nicht her denke ich... meine ueberlegung war folgende... die output clock und hsync kommt an einen externen interrupt... daten kommen auf irgendein port... der externe interrupt von der output clock ist der trigger fuer ein dma transfer der die daten vom port abholt... per dma chain wird ein zweiter dma angetriggert der das empfangende byte auf den pmp ausgibt... der pmp kann beim pic32 ja nur 65k adressieren... dewegen kommt der hsync auf ein irq der ggf die weiteren bits fuer den speicher steuert... wenn man das gemacht hat ist das einlesen der daten voellig ohne cpu benutzung... das einzig zeitkritische ist der hsync irq... das muesste aber machbar sein...
wahrscheinlich brauch man noch ne verknuepfung zwischen hsync und output clock das heisst nur wenn hsync aktiv ist darf die output clock wechseln... noch ne idee... wenn man diese standard displays 320*240 (mit nem ili932* controller) verwendet koennte man diese als speicher verwenden... sprich... subsampling runter und mit window auf 320*240 begrenzen... display im 8bit modus betreiben und so wuerd man sich den hsync irq sparen, den externen speicher und die kamera gibt das bild direkt ueber den pic32 auf das display aus... auf den speicher der kamera kann man ja direkt mit dem systeminterface zugreifen wenn man das bild am ende abgreifen will... das muesste eigentlich gehen...
Ja, müsste eigentlich gehen. Wegen Pic32, das hatte ich mir auch so gedacht, nur daß ich gelesen hatte Interrupt latency min 22 cycles + 2x6 cycles für pipeline load+ jump slot sind 22+12=34*12.5=425nS . Dazu kommt noch die ISR und deren Beendigung wenn notwendig (nicht verifiziert). Ich bin deshalb zum Schluss gekommen, daß mehr als 2.3 Mhz nicht drin sind. Ps. Nach dem Prelude, diesen 425nS scheint es zu sein, daß weitere Interrupts sein können, also sind es nur diese 425nS bei 80Mhz. Dies waren meine Überlegungen, bitte berichtigen oder verifizieren, ich habe keinen PIC32. USB-Host wäre aber nett.
stimmt die latenz... das hatte ich vorhin nicht bedacht... aber man koennte es auch so machen... wie ich oben schon schrieb die mainclock wollte ich ja schaltbar machen bzw. sie wird erzeugt durch pwm... und ist somit ueber hardwareregister schaltbar... neue idee (bei externen ram): das einlesen der daten erfolg wieder ueber outputclock ext irq und dma... dma chain braucht man nicht der dma kann auch direkt von port zum pmp schreiben... der neue ansatz ist nun das die clock nach den bytes die man lesen moechte (pro zeile) ausstellt... das kann man auch per dma machen sprich: gleichzeitig laeuft ein zweiter dma der auch als trigger den ext irq hat... dieser kopiert bei jedem ext irq vom ram (kostet natuerlich etwas speicher aber naja) etwas in das hardwareregister des pwm... sprich bei 1608 pixel kopiert er 1607 mal pwm an und beim letzten pwm aus... die mainclock steht somit... gleichzeitig loest dies ein irq aus wo man dann die pruefung macht und alles wieder fuer die naechste zeile vorbereitet anschliessend wird die mainclock wieder aktiviert... es gibt zwar dann noch eine isr die jede zeile aufgerufen wird nur wie viel zeit diese braucht ist egal weil die mainclock zu diesem zeitpunkt aus ist... das empfangen der daten ansich laeuft ja ohne isr.. das macht der dma und pmp usw unter sich aus... die daten koennen somit relativ schnell kommen es gibt halt nur jede zeile nen kurzen stop und dann gehts weiter... wenn man das jedoch ueber das display macht haette man das problem nicht... das abholen der daten laeuft voll ueber dma (keine isr) und das 65k problem ergibt sich dort auch nicht weil das display ja nen eigenen internen counter hat...
Nur mal so am Rande gefragt: Kennst Du auch andere Satzzeichen als Ellipsen?
Tolle theorien, die max 30Mhz Taktclock bekommst du von der Kamera und die wird mittels PLL gewonnen sowie die Zeit ändert sich mit der Belichtungszeit welche automatisch ist. Du kannst nicht mal den PIC32 auf die 30Mhz syncronisieren, da dieser auch nur PLL macht und du somit einen großen jitter hättest. Ob du beim PIC32 das über port-toggling machen kannst, keine Ahnung, das Flash läuft dort mit 30Mhz, Peripherie mit 10Mhz glaube ich gelesen zu haben, könnte jedenfalls besser gehen als DMA: 24/25Hz Videosequenzen schaffst du da nicht mehr im VGA Modus. Ein 8bit PIC hingegen schafft das, hat dann aber kein USB-Host. Externen Speicherinterface hat er sowie USB oder Ethernet, je nach Modell. Was gehen würde, einen SDRAM manuell zu refreshen und den Refresh-Counter als Zähler zu verwenden um die Daten ohne extern die Adressen anzulegen reinzuschreiben. Dieser Modi wurde jedoch von den Datenblättern entfernt, bei alten Datenblättern ist er noch vorhanden, und nicht jeder Baustein unterstützt sowas, bin jedoch nicht interessiert damit Zeit zu verlieren.
DMA bedeutet interrupt bei pic32 und nein, externer Speicher wird dort nicht über DAM angesteuert sondern über PMP (Parallel Master Port).
Ein übertakteter ATXmega könnte das doch schaffen, der hat doch HW DMA und man kann an das teil sogar(glaub ich weis ich aber nicht 100% ob HW fähig) SDRAM hängen. Laut datenblatt schaffen die ATXmega 32 Mhz und für manche pheriferie gibt es sogar noch eine interne PLL 64 MHz oder noch höher takten kann.
Habe ein paar von den Teilen bestellt und die kamen heute nach nur drei Tagen an. Allerdings bräuchte ich jetzt noch ein ordentliches datasheet, denn das wurde von Pollin nicht mitgeliefert. Hat da jemand ev. einen Link ?
Danke, habe es auch gerade gesehen, dass man auch die pdf-Files anklicken kann. Besten Dank für die Mühe, dann kann es ja losgehen !
Ich denke, ein XMEGA kann das nicht. Zum einen ist DMA mit einem parallelen Port als Quelle nicht vorgesehen (soweit ich weiß, kann mich irren), zum anderen ist der Datendurechsatz zum SDRAM schlechter als bei einem "alten" ATMEGA mit SRAM dran. Der SDRAM ist schön billig, und auch schön groß, aber langsamer als SRAM, wegen des hohen Overheads bei der Ansteuerung (nur 4-Bit-Modus).
Hallo ihr, Hab nach zwei tagen meine drei Kamera Module bekommen und muss sagen, dass das problem mit dem löten ja besteht, doch wie lötet ihr die Teile? Habt ihr Adapter oder kupferdrähtchen? Grüße Dennis
Ich habe das Modul mit drähtchen auf einer Lochrasterplatine aufgelötet und auch noch Stiftleisten drangemacht, damit ich gut damit experimentieren kann.
Weiß hier eigentlich jemand, ob das Modul eine spezielle externe Beschaltung braucht, also wegen Entstörung und so. Vielleicht habe ich ja deswegen Probleme mit der Konfiguration des Sensors.
Mal von dem Kondensator an der Versorgungsspannung abgesehn würde ich nur noch (wenn du I²C benutzt) diese Eingänge mit einem Pull-Up versehen. Vielleicht wäre noch ein PullUp oder PullDown an den Clk's nicht schlecht, das müsste man allerdings ausprobieren. Zu dem Löten: Ich habe mir auch gedacht, das über so Fädeldraht zu lösen, doch heute ist mir eingefallen, evtl. Adapterplatinen zu layouten, welche dann in einem 90° Winkel angelötet werden. an den anderen Enden könnte man ja dann Stiftleisten stecken. Wäre doch eine Idee oder?
Xmegas haben alle einen DMA und die größeren haben ein xmem interface an das man locker genug ram kriegt.... und 32 MHz clock is auch nich grade wenig.... trotzdem sind sie mit dem "vertrauten" toolchain (GCC + IDE der wahl) kompatibel.
ich hab sie mit faedeldraht geloetet geht recht gut eigentlich. kondensatoren hab ich keine zusaetzlich. im au-85.pdf ist ja der interne schaltplan und da liegen kondensatoren auf den spannungen. ok klar und pullups fuer i2c. funktioniert bisher eigentlich ganz gut. via i2c unterhaelt sich die kamera auch mit mir. das starten der aufnahme geht auch soweit nur das abholen der daten da bin ich gerade bei. ma gucken ob ich heute noch bisschen zeit habe... theHL-mod: zum subsamplen hast du da das register 250a benutzt ? wenn ich auf subsamplen stelle kommt was... nur weiss ich zur zeit noch nicht wie viel...
@egon: Ja, ich benutze das 0x250A Register, sobald ich da etwas programmiere (in meinem Fall 0x44 für ein subsampling von 4:1) kommen keine VSYNC und HSYNC Interrupts mehr. Ich habe aber auch andere Werte ausprobiert. Welche Register hast du denn sonst noch gesetzt? Ich habe: 0x2508 = 0x01 ; Exposure MSB 0x2509 = 0x36 ; Exposure LSB 0x2210 = 0x20 ; Line buffer enable 0x2217 = 0x00 ; Pins auf output mode stellen 0x257F = 0x01 ; URC befehl senden 0x2220 = 0x01 ; Set FRMPLS = 1, Jetzt kommen die Bilder
ich hab leider wenig zeit gehabt daher kaum was gemacht. hab nur bisschen gelesen. die waschmaschine hat gestreigt das hatte irgendwie prioritaet ;) habs eben nochma probiert bei mir kommt auch nichts. wahrscheinlich hab ich mich bei meinem letzten test vertan. mist weil sub sampling wollte ich auch verwenden... ich setzte noch ersten divider auf / 1 CamSetReg( 0x2200, 0x11 ); CamSetReg( 0x2203, 0x11 ); DelayMs( 500 ); CamSetReg( 0x2200, 0x45 ); jpg bypass CamSetReg( 0x2600, 0x1 ); sonst generiert die kamera jpg daten. beim zaehlen der hsyncs ist mir das aufgefallen das das viel zu viel sind. ggf. muss noch die konvertierung was gesetzt werden aber ich seh zur zeit noch nichts weil ich kein display am mc hab. aber ich uebertrage die daten spaeter auf den pc... und 250a. das mit dem subsampling ist ja super schlecht erklaert im datenblatt es gibt auch div einstellungen dazu... auch bits die man setzen muss wenn sub sampling aktiv ist. und die ganzen anderen sub samplings verwirren ziemlich. unterscheiden sich wohl an welcher stelle das sub sampling gemacht wird. ich hab gelesen das das imager sub sampling nur daten auslaesst gingegen die anderen noch was mit den daten machen... um die qualitaet zu verbessern. hm steig ich momentan noch nicht durch... aber wird schon ;)
Oh, Ich hatte gar nicht bemerkt, dass das Jpg standardmäßig aktiv ist. Wenn ich später im Labor bin, werde ich das mal ausprobieren, wenn ich nicht 100 andere Sachen machen muss :D
hab bisschen weitergemacht heute... also die oben beschriebene pic32 dma variante funktioniert soweit. allerdings nur mit ca. 6 mhz bisschen lahm :/ mit reiner pic32 cpu schaffe ich 20mhz... gesehen hab ich heute auch was allerdings ist es mit bisher nicht gelungen den farbraum richtig zu konvertieren. irgendwas stimmt noch nicht. also im prinzip funktioniert die kamera ist nur extrem fummelig weil manche sachen einfach unzureichend erklaert sind... manche sachen sind auch widerspruechlich... naja egal erstmal schluss fuer heute :)
Hallo, habe gerade die Diskusion über google gefunden, ja ist sehr intressant, werde die Sache mit einem STM32F103 lösen. Aber ich werde ein FIFO RAM als Interface einsetzen, dann muss die CPU nicht so schnell sein. Der JPEG Burst-Mode ist für mich intressant. Soll eine Funküberwachungskamera werden. Gruß Sascha
Angehängte Dateien:
-
campic.jpg
26 KB
das erste bild der kamera. sieht etwas bescheiden aus ich weiss :) das bild ist mit sub sampling (250a reg) der kamera runtergerechnet damit es noch in den speicher des pic32 passt. irgendwie sind die abstufungen der farben zu wenig...mein dev board hab ich erst vor kurzem gemacht kann sein das da paar bits nicht richtig rueberkommen. @theHL-mod wie du siehst kommt was bei mir mit aktivem subsampling. das letzte mal als ich es getestet hab hatte ich noch kein kaffee getrunken vielleicht war das der grund wieso nichts kam ;) die konvertierung nach rgb565 auf der kamera ist mir noch nicht gelungen irgendwas mach ich da noch falsch. das bild was man sieht ist in ycbcr welches ich spaeter nach rgb konvertiere... komisch ist auch dieser weissenbereiche im bild. stelle ich die expose time hoch werden diese bereiche noch extremer sprich werden weiss. egal was ich aufnehme der bereich ist immer gleich an dieser stelle. vielleicht ist es auch irgend ne einstellung. vielleicht ist die kamera nicht ganz ok keine ahnung. ich werd mal ne andere probieren mal gucken ob die das verhalten auch zeigt. lg und schoenes wochenende...;)
Cool! Das sieht ja echt mal spitze aus. Respekt. Bei mir bleiben die Teile erstmal auf Lager.
wie kommts ? ich werd denke ich auch nicht mehr viel machen... weil wie ich anfangs schrieb werd ichs nicht in meinen handheld einbauen. wollte nur mal sehen ob es soweit funktioniert :)
egon schrieb: > komisch ist auch dieser weissenbereiche im bild. stelle ich die expose > time hoch werden diese bereiche noch extremer sprich werden weiss. egal > was ich aufnehme der bereich ist immer gleich an dieser stelle. > vielleicht ist es auch irgend ne einstellung. > vielleicht ist die kamera nicht ganz ok keine ahnung. ich werd mal ne > andere probieren mal gucken ob die das verhalten auch zeigt. Oje, diese 3..4 milchigen Ringe sehen sehr nach einem Fehler der Optik aus. Irgend einen Grund muss es ja geben, dass die Teile bei Pollin vertickert werden... Es würde mich interessieren, ob die Bilder der anderen User auch Fehler aufweisen. Grüße, Peter
cool, wie hast du denn die Register genau gesetzt, um das Bild zu erzeugen? Mit welcher Bildrate kommen bei dir die Bilder? vielleicht muss ich auch einfach nur nen anderen Sensor testen. Bei dem Preis hab ich ja gleich ne ganze menge bestellt xD
Angehängte Dateien:
-
campic2.jpg
27 KB
ich hab mal ne andere kamera rangeloetet siehe bild. gleicher effekt. ich hab mal zum test alles was man ausstellen kann an features ausgestellt und aendert sich nichts. ich wuesste jetzt nicht was ich da noch falsch machen koennte. also wahrscheinlich ist die kamera ausschuss... je hoher man die exposer time dreht desto mehr kommt dieser fehler zum tragen. schade eigentlich. ich denke ich brech jetzt hier ab. vielleicht bekommt ja jemand anderes sie zum laufen. so setz ich die register...
1 | //enable outputs
|
2 | CamSetReg( 0x2217, 0x0 ); |
3 | |
4 | // set in div to 1
|
5 | // end iclk div to 2
|
6 | CamSetReg( 0x2200, 0x11 ); |
7 | CamSetReg( 0x2203, 0x11 ); |
8 | CamSetReg( 0x2200, 0x45+8 ); |
9 | // wait for pll
|
10 | DelayMs( 400 ); |
11 | |
12 | //jpg bypass
|
13 | CamSetReg( 0x2600, 0x1 ); |
14 | |
15 | // exposure time
|
16 | // value just found by try and error ;)
|
17 | CamSetReg( 0x2508, 0x02 ); |
18 | CamSetReg( 0x2509, 0x80 ); |
19 | |
20 | // Line buffer enable
|
21 | CamSetReg( 0x2210, 0x20 ); |
22 | |
23 | //imager sub sample
|
24 | CamSetReg( 0x250a, 0x44 ); |
25 | // lens correction subsample
|
26 | CamSetReg( 0x2309, 2 ); |
27 | |
28 | |
29 | //color cpace conversion matrix -> ycbcr
|
30 | CamSetReg( 0x2408,0x041 ); |
31 | CamSetReg( 0x2409,0x00 ); |
32 | |
33 | CamSetReg( 0x240a,0x081 ); |
34 | CamSetReg( 0x240b,0 ); |
35 | |
36 | CamSetReg( 0x240c,0x019 ); |
37 | CamSetReg( 0x240d,0 ); |
38 | |
39 | CamSetReg( 0x240e,0x16 ); |
40 | CamSetReg( 0x240f,0 ); |
41 | |
42 | |
43 | CamSetReg( 0x2410,0x25 ); |
44 | CamSetReg( 0x2411,1 ); |
45 | |
46 | CamSetReg( 0x2412,0x4A ); |
47 | CamSetReg( 0x2413,1 ); |
48 | |
49 | CamSetReg( 0x2414,0x070 ); |
50 | CamSetReg( 0x2415,0 ); |
51 | |
52 | CamSetReg( 0x2416,0x80 ); |
53 | CamSetReg( 0x2417,0 ); |
54 | |
55 | |
56 | CamSetReg( 0x2418,0x070 ); |
57 | CamSetReg( 0x2419,0 ); |
58 | |
59 | CamSetReg( 0x241a,0x15D ); |
60 | CamSetReg( 0x241b,0x1 ); |
61 | |
62 | CamSetReg( 0x241c,0x112 ); |
63 | CamSetReg( 0x241d,0x1 ); |
64 | |
65 | CamSetReg( 0x241e,0x80 ); |
66 | CamSetReg( 0x241f,0 ); |
67 | |
68 | |
69 | //urc
|
70 | CamSetReg( 0x257F, 0x01 ); |
71 | |
72 | // start snapshot
|
73 | CamSetReg( 0x2220, 0x1 ); |
74 | CamSetReg( 0x2220, 0x0 ); |
die daten kommen mit 20mhz.
egon schrieb: > je hoher man die exposer time dreht desto mehr kommt dieser > > fehler zum tragen. Versuch mal das Gehäuse der kamera schwarz anzumalen, oder irgendwie anders gegen Licht abzudichten, ich kenne einem ähnlichen Effekt von einigen Objektiven in IR Fotografie wenn das Objektivgehäuse leicht IR durchlässig ist. Eine andere Fehlerquelle könnte seitenstreung vom Licht sein, in diesem Fall könnte das mit einer kleinen selbstgebastelten Streulichtblende gemindert, werden. http://de.wikipedia.org/wiki/Streulichtblende
hab ich mal eben probiert. die ganze kamera bis zur platine mit schwarzem klebeband eingewickelt... und ein rohr vorn an das objektiv. der effekt ist der selbe :/
Oh je, das sieht gar nicht gut aus, kannst du die Kamera zerlegen und den Filter mal für einen Test herausnehmen ? So einen Effekt könnte vom Filter kommen. Wie wenn Öl auf dem Waver oder Filter sitzt. Mit einem Wattestäbchen reinigen mit Isopropanol. Ein FIFO habe ich bis jetzt noch nicht ganz passend gefunden, zudem es auch teurer als die Kamera ist. Aber Cypress CY7C4201 oder so. IDT baut auch noch welche. Gruß Sascha
also das objektiv ist es nicht... das habe ich eben mal abgedreht... der effekt ist noch immer zu sehen... entweder hat der sensor ne macke oder ne einstellung ist falsch... keine ahnung. ich geb jetzt auf wollte eh nur gucken ob das ansteuern so funktioniert wie ich mir das dachte... das tut es mission complete ;)
Hallo egon, erstmal vielen Dank für die Infos, echt klasse..... mit wie viel Volt versorgst du die Kamera ? Habe im Datenblatt etwas so mit 2,85V aufgeschnappt ?!? Das könnte natürlich auch ein Problem sein. Habe übrigens meine Meinung geändert, werde den Atmel AT91SAM9XE256 dafür verwenden. Der hat ein passendes Interface für solche Kameras und er ist noch mit Flash ausgestattet. Aber ein RAM oder SDRAM muss trotzdem ran. Ja wie man sieht ist das doch mit Aufwand nur zu machen. Gruß Sascha
moin sascha, ich hab sie mit 3,3v betrieben (Power Supply 2.4 to 3.3 VDC)... lg ;)
Das Testbild ist wohl das hier: http://ecx.images-amazon.com/images/I/51PYHV8Q6QL._SS500_.jpg Bei längerer Belichtungszeit wird das Bildrauschen zunehmen, diesen Effekt kann man durch Kühlung der Kamera etwas reduzieren. Der starke Gelbstich könnte an der Beleuchtung liegen, der Weißabgleich der Kamera ist möglicherweise auf Tageslicht ausgerichtet. Allerdings ist die Vorlage sowieso sehr ausgeprägt rotlastig (s.o.). Die hellen Stellen ("milchigen Ringe") könnten Reflexionen der Beleuchtung auf dem Buchcover sein. Außerdem ist so eine Nahaufnahme zum Testen der Kamera nicht besonders gut geeignet, das ist keine Autofocus-Kamera, sondern eine "Out-of-Focus"-Kamera, will meinen, eine Fixfocus-Kamera. Mach mal ein Bild von etwas mit a) normaler Beleuchtung b) deutlich größerer Entfernung von der Kamera und c) normalerer Farbverteilung als ausgerechnet ein so ausgeprägt rot-gelbes Buchcover.
gut erkannt @buch ;) wobei das bild schlecht ist im orig ist mehr gelb und andere farben... reflexionen schliesse ich aus weil a)die ringe sich nie aendern bleiben immer an der gleichen position b) die ringe auch kommen wenn ich das objektiv abdrehe. @focus wie gesagt ohne objektiv passiert es auch... weitere tests sind nicht mehr moeglich... bei abdrehen des objektivs ist mir ein pad der spannungsversorgung (+) abgerissen... und die zweite kamera hab ich zerlegt :/
@egon Hast du immer nur ein Bild aus dem Sensor ausgelesen, oder hast du den Sensor auch mal auf continuous mode gestellt, damit jedes Bild sofort rausgesendet wird? Bei mir scheint es so, als würde ein Bild geschickt werden, aber das vsync Signal geht danach nicht mehr auf 0. (Ich habe auch mal einen anderen Sensor getestet, aber der hat genau das gleiche Verhalten) Ich versuche mal die Daten abzuspeichern und schaue, ob sinnvolle Daten übertragen werden.
Also ich habe jetzt die auto exposure & white balance ausgeschaltet, und jetzt kommen scheinbar jede Menge Bilder, auch mit subsampling, allerdings tut sich nichts am vsync signal. Ich werde jetzt aber erstmal windowing ausprobieren, bevor ich mich um dieses Signal kümmere.
ich hab immer nur ein bild aufgenommen. vielleicht ist die exposure zeit bei dir zu lang ? die muss irgendwie kleiner ein ganzer frame sein. hab ich glaub ich mal gelesen... wobei ich die berechnung nicht ganz nachvollziehen kann. irendwie ;) bin nie auf die 0x4c0 bei einem vollem frame gekommen. kopfkratz
@egon : Welche Werte hast Du für die Pull-Up-Widerstände an den I2C-Leitungen genommen ?
Hallo, weis jemand wie diese Kamera überhaupt gelötet werden darf ? Ich stehe gerade vor der Überlegung ob ich das Ding kleben oder löten soll. Gibt es irgendwo eine Anweisung in den Datenblätter ? Die Temperatur beim kleben ist ca.140 Grad und beim Löten ca. 260 Grad. Das die Kamera aber ein Reflowlöten überlebt kann ich mir nicht vorstellen. Dampfphasenlöten ist da aber auch keine alternative. Die Leiterplatte ist ja sehr dünn und der CMOS chip vor allem die Farbpartikel könnten schnell beschädigt sein. Das könnte dann auch die weißen Ringe erklären. Also werde ichs auch vererst ganz vorsichtig mit dem Lötkolben mit 280 Grad und mit Kupferlackdraht probieren.(nur sehr kurze Lötzeit) Wollte so eine Kamera schon zerlegen, ist aber total verklebt. Man sieht an den Pads noch die Nadelkontaktierungen vom Prüfgerät und auch den Focusabgleich (Kontrollstrich) also gehe ich davon aus, das es prinzipell keine Ausschussware ist. Sonst hätte man sich die letzten Arbeitsgänge sparen können. @debugger Pullupwiederstände kannst du einfach ermitteln, das hängt in erster linie von deiner Geschwindigkeit auf dem I2C Bus ab. Schau mittels Oszi dir die Signalflanken an, sind sie steil genug und das Signal bis zum Einlesetakt sauber, reicht der Wiederstand aus. Also ich verwende 4K7 bei ca. 40KHz. PS.bastle gerade meine ARM9XE Leiterplatte..... Gruß Sascha
sascha hm stimmt @loeten... aber wenn es durchs loeten kam warum sind die ringe immer nur auf einer seite ? hm wobei... ich hab noch mal im datenblatt geguckt anscheinend ist der sensor an den seiten nur bis zum rand "oben" und "unten" ist er deutlich kleiner... muss ich nachher mal gucken. ich weiss noch wie rum die kamera war als ich immer aufgenommen hab mal schauen wie da der sensor stand... ja... zumal die anzahl der ringe schon stimmt... und die abstaende sind immer gleich in vertikal richtung (zumindest fast). koennte sein.
ahso debugger: siehe saschas text ich hab 2,2k glaub ich benutzt. ich hab eben noch mal geschaut. da wo die ringe sind liegt der sensor direkt drueber. zumindest auf der einen seite auf der anderen hm haette das eigentlich auch passieren muessen. ok gut ich bestell noch mal welche und teste es noch mal... insgeheim nerven tuts mich ja auch ;)
Zum Testen würde ich einfach mal eine 2x 10 pin Pfostensteckerleiste in ein 20 pin Ic Sockel stecken, die Kontakte mit Kabeln anlöten und dann alles mit reichlich Heisskleber fixieren.
Hallo, @egon, ja Vosicht die Leiterplatte der Kamera habe ich mir mal kurz unter der Lupe angesehen, es ist eine Multilayer Platiene mit vermutlich Blind-Vias. Das heisst sie müssen nicht auf beiden Seiten durchgängig sein. Als ich die Leiterplatte angesehen habe vermutete ich die Zusammenhänge mit deinem Bild. Vermutlich ist auch das der Grund, warum solche Kameras micht mehr Hergestellt werden, sondern nur noch mit Flat&Flex Kabel. Bei Pollin ist ja auch noch eine solche im Programm aber ich kann auch keine Daten darüber finden. Nach der Optik zu urteilen ist sie moderner. Der Stecker dürfte aber dann auch viel zu teuer werden. Also ich mache meinen SAM9XE mit einem externen SDRAM auf jedenfall fertig und wenn dann auch im Notfall eine andere Kamera her muss. Frage: ist der CMOS Waver auf der Platiene gebonded oder geklebt ??? Gruß Sascha
Sacha schrieb: > Frage: ist der CMOS Waver auf der Platiene gebonded oder geklebt ??? Der Wa_f_er ist die Gesamtheit aller Dice (pl. von Die) bzw. Chips, und nur einer davon ist auf der Plat_i_ne drauf. Die Anschlüsse werden gebondet, der Chip selbst ist i.d.R. geklebt. Flip-Chip-Technik ist bei einem Kamerasensor nicht anzunehmen.
Hallo, @Rufus ja klar ist es nur ein Die, aber das versteht vieleicht nicht jeder gleich. Also wir haben viele Chips im Einsatz die nicht mehr gebondet sind sondern nur noch mit Leitkleber in das SMD-Gehäuse geklebt werden, die Tollen Chips haben oft die Eigenschaften nach ca. 3 bis 5 Jahren auszufallen besonders bei gewissen Temperaturen, weil sich Haarrisse im Klebstoff bilden. Die Tolle Zeit holt uns da halt ein. Ich verwende einige 32Bit SDRAMs oder DDR2-RAMs die haben oft das Problem. Ist halt billiger als Bonden, da man beim Bonden auch mehr Platz braucht..... Aber ich gebe dir recht der CMOS Sensor kann eigentlich kaum ohne Bonddrähte ausgommen sonst müsste er ja Kopfüber eingebaut werden. Bzw. ich habe noch keine Kamera zerstört sonst könnte man das mit einer Lupe sehen. @egon Schau mal bei deiner zerlegten Kamera nach, wie der Chip auf der Leiterplatte sitzt. Also im Datenblatt steht der Hinweis: This Module is compatibel with X75 Module Socket. Also das könnte ein Hinweis darauf sein, das man überhaupt nichts anlöten darf ????? Und das würde für mich auch der kleine Abstand (bzw.Freiraum) der Pads erklären. Ufff ja woher den Sockel nehmen... Oder die Kamera mit Leitsilber kontaktieren ? Gruß Sascha
Angehängte Dateien:
-
adapter.jpg
15 KB
@chip und leiterplatte schau ich nachher mal... X75 da hab ich auch schon bisschen geforscht. scheint ein camera modul von siemens zu sein. http://www.neuhold-elektronik.at/catshop/product_info.php?products_id=3290 mit leitsilber hab ich auch schon ueberlegt... die frage ist ob das leitsilber am ende genuegend kraft hat und den draht auf dem pad zu halten. zudem leitsilber so genau zu dosieren wird schwierig. was man vielleicht machen koennte. eine platine (siehe bild) machen die innen ein viereckiges loch hat (das weisse). sind nicht alle pads drauf war zu faul ;) innen die pads der kamera aussen die pads die geloetet werden. und dort kommt ein draht dran ...silberdraht wird wohl zu flexibel sein... der draht muesste sich durch ein biegen vorher auf das pad der kamera druecken. mal schauen. aber erst mal probier ichs noch mal mit loeten.
@x75 oder besser aus dem handy x75 von siemens... da hab ich aber bisher keine richtigen infos zu gefunden.
egon schrieb: > innen die pads der kamera aussen die pads die geloetet werden. und dort > kommt ein draht dran ...silberdraht wird wohl zu flexibel sein... der > draht muesste sich durch ein biegen vorher auf das pad der kamera > druecken. Wieso nicht abgewinkelte Stiftleisten (90°) von unten im richtigen Abstand in die Platine löten. Dann könnte man die Kamera von oben (durch die Platine) nur auf die abgewinkelten Stife aufsetzen und die Kamera von oben am Gehäuse einkleben. Nur ob das nach ein paar Monaten immernoch kontakt hat? Grüße
Wenn die Kamera tatsächlich nicht lötbar ist, kann man sie mit Prüfnadeln kontaktieren, oder, wenn man gerade einen alten PC ausschlachtet, mit den Federkontakten aus dem Sockel 775 oder neuer ...
Rufus Τ. Firefly schrieb: > Prüfnadeln kontaktieren, Mmh, so wird es ja auch bei den Handys (teilweise) gemacht. Die Kamera ist ja da meist nur seitlich fixiert und wird durch das Gehäuse o.ä. von oben auf die Kontakte gedrückt...
Hallo, ich habe solche Sockel z.B. bei Molex gesehen, aber nicht den für unsere Kamera, da müssen wir halt nochmals suchen. Kontaktnadeln o.k. dann wird die sache aber größer. Ich prüfe nochmals das Rastermas und schau bei Samtec rein. Also Löten.... lasst es blos bleiben, das Ding ist definitiv dann tot. Gruß Sascha
ich hab 4 bestellt... eine koennte ich da noch opfern... ich werd bei der aber noch nicht alle pins anloeten um zu sehen obs wirklich daran liegt... die kameras sind schon da... komm ich aber leider erst morgen zu... ich werd dann berichten ;)
Hallo egon, verusch die Kamera wenigstens gut zu kühlen. Die Leiterplatte ist ja super dünn und der CMOS Baustein sitzt direkt darauf. Ich gehe nacher mal zu meinem Nachbar und schau ein paar CPU-Sockel an, ob man die Kontaktfedern auf einer Adapterleiterplatte löten kann ? Einen passenden Socker habe ich leider noch nicht gefunden. Habe aber alles schon sehr gut ausgemessen. Gruß Sascha
Angehängte Dateien:
-
campic3.jpg
11 KB
also habs heute probiert mit kuehlung und super defensiven loeten. loetzeit war vielleicht beim verzinnen ca. 0,2 s und loeten nach ner pause nochma 0,2 s... gleicher effekt (siehe bild) :/ es war nicht mal ansatzweise besser. ich hab nur die pins d4-d7 geloetet... dann scl sda mclk und hsync. und die spannungsversorgung wobei ich nicht mehr der meinung bin das die ringe durch das loeten verursacht werden weil: a) passt die anzahl der ringe nicht mit den loetstellen ich zaehle 7 ringe. geloetet hab ich auf der seite nur 4 auf der anderen seite 2 pads. oben 1 unten 3. b) mein naechster test war etwas radikel ;) habe ich auf der allen seiten mal 30 sekunden jeweils den loetkolben rangehalten . die kamera hat es ueberlegt und das haette eigentlich einen effekt auf dem bild erzeugen muessen hat es nicht. daher denke ich das das loeten nicht er ausloeser ist...
ich hab eben mal in photoshop das letzte bild und das vorletzte mit dem auto uebereinander gelegt und die ringe sind absolut deckungsgleich... tja... keine ahnung entweder ansteuerungs- oder produktionsfehler.
Wie ist denn die Anordnung der benutzten Lötstellen auf der Kameraunterseite? Vielleicht besteht da ja eine Korrelation zu den Ringen? Das Bild hier Beitrag "Re: pollin kamera au-85" "passt" halt irgendwie ganz, ganz grob.
auf der unterseite ist ein viereck mit jeweils 5 pads an den seiten. die loetstellen passen nicht zu den ringen :/
Man müsste sich ansehen, wie das Substrat aussieht, an dessen Unterseite die Lötstellen sind und auf das der Bildsensor geklebt/gebondet/gewasauchimmert ist. Naja, 's ist ja auch nur 'ne Vermutung gewesen.
Hallo, vieleicht sind die Kameras mit radioaktivität bestrahlt worden, dann gehen die auch auf diese Weiße kaputt. Das würden die Weißen Ringe erklären, denn dort ist überhaupt kein Kupfer. Röntgenstrahlung reicht da vieleicht noch nicht ganz aus !?!? Höhenstrahlung a la Flugzeug beim Stransport auch nicht. Wie lange werden die Teile von Polling den schon vertrieben ? Weis nur das eine CMOS Videokamera nur eine sehr kurze standzeit in einem AKW hat. Am besten mal messen lassen. Gruß Sascha
Das sieht sehr nach von hinten durchscheinendem Licht aus, hab das gleiche mal bei einer aus einem Notebook ausgebauten Webcam gesehen, auch wenn man glaubt da kommt nichts mehr dran, irgendwo koppelt noch ein Wenig Licht ein, also die Cam mal in einen Schuhkarton legen und gucken obs immer noch so ist
Nimm eine IR Fernbedienung, lass sie gegen hinten oder auch seitlich senden und schau dir die Bilder an. IF Strahlung wird nur von vorne geblockt. Wenn da Licht von hinten reinkommt, kann man das sehr gut mit einer Fernbedienung erkennen.
ops jetzt erst gesehen. debugger: ich hab bisher nur das subsampling des imagers probiert. und da tritt das problem auch auf. wundert mich aber nicht da das imager subsampling einfach nur daten auslaesst beim senden. was ich noch mal machen koennte waere das andere subsampling ausprobieren...
Hallo, also ich habe nun bei einer Kamera die Leiterplatte vorsichtig entfernt, damit der Chip und alles was sich darauf befindet ganz bleibt. Ich habe den Chip sowie den IR-Cut Filter unterm Mikroskop betrachtet, er hat überhaupt keine Anzeichen von irgendwelchen Beschädigungen. Als zweites habe ich einen IR Durchlichttest gemacht (wir haben noch eine alte IR-Kamera in Schwarz-Weiß zum IR-Filmen) auch keinen Fehler festgestellt. Dann habe ich den CMOS-Chip entfernt und die Klebstoffreste entfernt. Den IR-Durchlichttest erneut gemacht und klar es sieht so ähnlich aus wie bei dir egon, aber es ist ein anderes Bild. Egal wie ich es betrachte ich komme nicht ganz auf dein Bild. Ich Frage mich gerade ob wir die gleiche Kamera haben. Weil der Abgang der Leiterbahnen oben etwas anders aussieht als unten. Und der Siliziumträger eigentlich nichts durchlassen dürfte. Aber wo liegt nun das Problem ??? Na jedenfals bin ich mal gespannt wenn mein ARM9 dann geht, mach gerade eine nette Leiterplatte.... Gruß Sascha Ach noch etwas, habe keine Blindvias finden können.
interessant... hm die ringe waren bei mir bei allen kameras gleich. @deine ringe wenn man es ein wenig verzerren wuerde ? wuerde es dann passen ? die kamera macht ja noch eine linsenkorrektur wobei das wahrscheinlich nicht so viel sein wird... ich kann ja mal ein paar bilder der kamera machen... wovon haettest du wenn gerne welche ?
Ich weiß jetzt nicht ob es von der Größe passt aber eventuell könnte man einen SIM Sockel von einem alten Handy zum Kontaktieren nutzen?
Ich hätte gern ein Bild der Kamera (Aussenaufnahme bei gutem Licht) sowie ein Bild einer Fotokamera mit reduzierter Auflösung oder eben die Auflösung verkleinert des gleichen Motives, um die Bilder subtrahieren zu können. Weiters einen Graukarton, Braunen Karton, Weisses Blatt unterbelichtet, graue Wand, was auch immer.
Angehängte Dateien:
-
scan_2.jpg
14 KB
Hallo, also jetzt habe ich noch Glücklicherweise die Optik zerlegt bekommen. Das Problem sehe ich auch noch an der Linse, wenn man das Ding noch so nennen darf. Die Optik kann im laufe der Zeit etwas blind werden, also trüben. Also einen Test, ob die Optik verzerrt habe ich auch gemacht konnte aber nichts negatives erkennen. Ist aber Intressant, was der Chip intern alles so machen soll ?!? Vor allem so ganz ohne Großes RAM. Eine Entzerrung in Zeilenscann Richtung (X-Richtung) O.K. aber wie bitte in Y-Richtung ? Da würde ich mich schon auf meinem ARM9 mit 32MByte SDRAM schwer tun, weil die Algorithmen schon schwer genug sind so etwas richtig zu machen. Also gut wie dem auch sei zumindest müssten die Durchkontaktierungen mitten im Bild erscheinen. Aber ich habe auf meinem Scanner von der Leiterplatte einen Scan gemacht. Gruß Sascha
Angehängte Dateien:
-
scan_2.jpg
13 KB -
campic3.jpg
9,7 KB
Und jetzt vergleiche doch bitte mal das Bild der Platine mit den Bildern, die die "weißen Kreise" aufweisen.
Der Bildvergleich zeigt (mir zumindest), das es eindeutig die DuKos sind, die da zu sehen sind. Der CCD muß nicht in der Mitte der Platine liegen!
Angehängte Dateien:
-
overlay.jpg
20 KB
Es passt nicht ganz, aber wenn der Sensor etwas verzerrt ist...
Hallo, O.K. ich gebe zu das rufus das Bild sehr gut gespiegelt und gedreht hat. Es stimmt es sieht dem gleich und wenn man ganz genau hinsieht kann man sogar noch die Leiterbahnen von der anderen Seite sehen. Aber jetzt muss mir noch jemand erklären wie geht der Mist durch den Chip. Ich habe den Chip von der Leiterplatte entfernt und es war ein ordentliches Stück Silizium, keine Klare Glasscheibe ???? Ich glaube nicht das Licht oder sogar Infrarot bei egon so stark in seinem Raum vorhanden ist !?! Oder wurden die Teile mit einer anderen Strahlung zerstört was ich eher glaube. Zumindest stimmt dann die Shutter Einstellungen nicht und da ich den Chip gesehen habe muss ich sagen der aktive Bereich ist recht groß und die Durchkontaktierungen liegen so gut wie in der Mitte. Das Wärme da übertragen wird kann ich nicht mehr glauben, die Aussage von egon mit seinen Lötversuchen ist also richtig. Egon kleb doch mal ein kleines Metallstück oder etwas was auf gar keinen Fall Licht oder Infrarot durchlässt hinten über den Bereich. Oder hast du so tolle Energiesparlampem ? Die könnten auch sehr viel UV abgeben und UV (je nach Wellenlänge) könnte auch durch den Chip ?!? Energiesparlampen kommen bei mir nicht ins Haus. Gruß Sascha
Angehängte Dateien:
-
campic4.jpg
33 KB
hust AAAAAAAAAAAAAAAARGGGGGGGGGGGGGG ;) ich hab bei meinem lichttest nicht hinten abgeklebt ist mir vorhin wieder eingefallen. weil einer oben meinte vielleicht kommt ja licht von der seite rein. und danach war das thema fuer mich abgehakt... mist mist mist... sorry ;) sascha... ich hab immer ne hallogenleuchte in der naehe gehabt. die hat anscheinend gereicht... hab gleich noch ein bug behoben... momentan mach ich das subsampling ja noch per hand und da war nen fehler das ich immer mir 2 punkte geholt hab und dann 6 uebersprungen. das ist natuerlich kaese weil crcb aus den ersten beiden punkten und y vom ersten und aus der mitte... somit siehts nicht mehr so pixelig aus... sieht doch ganz brauchbar aus. schoen funktioniert das endlich... danke fuer die anregungen ;)
Ja super, egon das ist ja "Spitze", ich kann es noch gar nicht glauben, das die Dinger so extrem empfindlich sind....... ich hätte da nur noch eine Bitte an dich, würdest du mir die I2C Initialisierung nochmals verraten, dann habe ich es wenn mein ARM9 leuft etwas einfacher. Ich muss aber schon sagen der PIC ist doch recht schnell, wenn er das direkt so einlesen kann, hätte ich nicht gedacht ! Gruß Sascha PS. Der Deckel oben hat nur eine Glasscheibe drunter, damit die weiche Linse nicht zerstört wird. Daran muss nicht gedreht werden. Der Focus wird an dem unteren Gewinde eingestellt, es befindet sich auf gleicher höhe wie das Metal anfängt. Der Klebstoff lässt sich mit einem kleinen Messer entfernen wenn man das Metall vorsichtig herunternimmt. Mit einer besseren Optik müsste die Kamera ja extrem empfindlich werden......
sascha: die initialisierung steht oben schon da hab ich nicht viel geaendert ausser: CamSetReg( 0x2508, 0x00 ); CamSetReg( 0x2509, 0xf0 ); //imager sub sample CamSetReg( 0x250a, 0x0 ); // lens correction subsample //CamSetReg( 0x2309, 2 ); sprich subsample ist aus... mal schauen vielleicht poste ich auch mal den source dazu muss ich ihn aber noch bisschen aufraeumen :) das auslesen ist inline assembler ich brauch 4 instructions fuer 1 punkt... clock usw. steuer ich per hand somit kann ich sie auch einfach ausstellen... ich hab eben mal ein test gemacht und nach dem ich eine zeile ausgelesen habe einfach mal gewartet 600us (so lang wie ich braeuchte in meinem handheld die daten(3,2k) ins dram zu schreiben)... und klappt! cool das bild sieht noch genauso aus mit etwas korrigierter exposer time... gut das waer natuerlich jetzt raw... also jpg ist das natuerlich weniger... mal gucken vielleicht bau ich das doch noch in mein handheld (wenns schon so nen akt war das zum laufen zu bekommen ;)) mit wieviel mhz ist denn das sdram beim arm9 dann getaktet ? das dram muss ich ja zu fuss beim pic32 machen aber ist auf jeden fall brauchbar... refresh laeuft bei mir ueber pwm das kostet nichts an cpu und zugriff schaff ich um die 5,3 mb pro sekunde... das werd ich vielleicht mal die tage probieren ein jpg zu holen. die qualitaet kann man ja coolerweise auch einstellen... aber fuer 2,95 gutes schnaeppchen ;)
Kann man eigentlich den IR-Filter entfernen, damit Aufnahmen in der Dunkelheit mit IR-Dioden möglich sind ?
Angehängte Dateien:
-
scan_1.jpg
14 KB -
scan_2.jpg
14 KB
Hallo, @egon, ja das hört man gerne, ich programmiere sehr viel in Assembler auch meine ARM9. Ist für mich einfach eine Herausforderung die Algorithmen so schnell wie möglich zu machen. Also das SDRAM kann mit 133MHz oder mit 166MHz getaktet werden ich benuze den Chip: IS42S32800D. Die CPU leuft auf 180MHz dann kann das SDRAM auf 90MHz getaktet werden. Das besondere an der CPU ist das ein internes Flash mit bis zu 512K zur verfügung steht und benötigt bei 180MHz CPU clock 4 Wait States. Dann ist noch ein 32 Kbyte großer SRAM intern mit 0 Wait States vorhanden es kann auch dort Code ausgeführt werden. Das gute ist weiterhin das man ohne größere Probleme auf die AT91SAM9G10,15,45,46 Typen aufbauen kann, hat aber nicht jeder ein ISI also Image Sensor Interface drin (SAM9XE,G45 und G46 meines Wissens nach). @debugger, klar das habe ich auch vor, habe ja eine Kamera zerlegt und die Filterscheibe kann man ausdrücken und eventuell sogar nur noch ein IR-Bandpassfilter einbauen, dann ist die Farbe halt weg ! Was echt cool wäre mit einem Lösemittel die Farbbeschichtung vom CMOS Sensor noch herunterwaschen und eine IR tauglichere Linse einbauen...... (aber vorerst will ich mal nichts übertreiben) Gruß Sascha
180mhz ist natuerlich schon nicht schlecht... uebertaktet laeuft der pic32 stabil auf 120mhz (zumindest bei mir im raum) aber da kann er natuerlich nicht mithalten... wobei pic32 hat nen prefetch cache der bei loops greift die aus max 64 instructions besteht 0 waitstates usw...... bei linearem code brauch er aber dann waitstates alle 4 instructions... oder halt wie beim arm ram mit 0... ich war schon mal am ueberlegen umzusteigen...aber momentan reicht mir der pic32 noch. ausserdem arbeite ich schon um die 3 jahre damit da tut man sich natuerlich schwer mit was neuem... aber das ist ja gerade die herausforderung eben etwas machen was normalerweise nicht unbedingt dafuer gedacht ist... ok auf nem 8bitter ist das vielleicht noch etwas krasser aber ganz zurueck in die steinzeit will ich dann doch nicht mehr ;)
Ist das nicht ein unnötiger Overkill, die Datenbytes des Bildsensors vom Prozessor einzeln abholen und in SRAM schreiben zu lassen ? Wäre es nicht wesentlich eleganter, den Datenstream vom PIXCLK-, VSYNC- und HSYNC-Signal hardwaremässig gesteuert direkt in ein SRAM zu schieben und dann von dort aus in Ruhe mit dem Prozessor zu verarbeiten ?
hm wieso overkill ? es ist ja nicht mal zeitkritsch ? also overkill wuerde ich bezeichnen was du extern brauchst um die daten direkt ins ram zu schreiben... ohne cpld oder fpga mein ich... allein das sram und counter usw... klar ist es schneller keine frage nur mir waere z.b. eine schlanke loesung lieber die auch noch akzeptabel ist in der geschwindigkeit...
Hallo, @debugger sicherlich das sehe ich auch so, aber ich ziehe meinen Hut vor egon. Es gibt so vieles wofürs nicht immer die richtige Schnittstelle gibt und dann besteht halt eben mal die Stärke mit anderen Hardwaremodulen zu kombinieren. Schau dir doch mal das Datenblatt vom AT91SAM9XExxx an im Bezug auf das ISI Modul. Und manchmal kosten Hardwaremodule eine menge Geld und haben blöderweise auch noch den flaschen Prozessor drin..... @egon, ich habe früher mit Zilog Z80 (Schneider CPC) angefangen, dann Intel 8031 (der Core ist mir bis heute geblieben), Motorola 68000 (Amiga),Microchip PIC16Cxx, Renesas M16C,M32C und R32C. Der R32C ist schon cool mit FPU aber Renesas hat neuerdings andere Strategien deshalb bin ich heute auf Cortex M3 von ST umgestiegen. ARM7 habe ich angefangen mit dem Gameboy Advance und bis zu den Embedded Kontrollern. Der Sprung auf einen ARM9 ist sehr klein. Der ARM9 hat halt eine MMU drin und Data und Instruction Cache mit 2x16K, Befehle sind gleich. Wenn ich heute über alles so zurückdenke kann ich nur sagen, nimmt Prozessoren die jede Halbleiterschmiede lizensieren kann, somit bleiben die Produkte länger am leben. Was die PICs angeht muss ich sagen hat Microchip eine sagenhafte langzeitverfügbarkeit. Ich wollte halt damals nicht auf einen PIC18 und PIC24 gehen, und der MIPS-Kern ist gegen ARM nicht so leistungsfähig. War wohl eine Entscheidung von Microchip weil MIPS halt im eigenen Land ist. Deshalb vor Jahren auch das große Interesse Atmel zu übernehmen. Allerdings sehe ich auch das Problem bei ARM es kommen immer mehr CPU-Kerne auf den Markt (die meisten braucht man nicht wirklich, meiner Meinung nach) und das kann dann die Kunden verunsichern. Ich selber habe auch die Meinung man muss nicht jeden Hype mitgehen. Gruß Sascha
@egon, @Sascha _: Versteht mich bitte nicht gfalsch. Natürlich habe ich grössten respekt vor Leistung egon, 1.) uns auf den Chip bei pollin hinzuweisen und 2.) so schnell eine funktionierende Software zum erfolgreichen Auselsen des Bildes zu schreiben. Bei mir ist es nur so, dass ich eine Ultra-Low-Power-Anwendung mit einem MSP430F149 oder F249 plane, und da ist die höchste Arbeitsfrequenz eben 8 bzw. 16 MHz Und in dem Fall wäre ein hardwaregesteuerter direkter Dataenstream in das SRAM wohl wesentlich effektiver.
Hallo, @debugger klar ich wollte auch niemand damit angreifen. Ah der MSP430 von Texas, ist für Sensoric nicht ohne, vor allem wenns ums absolutes low power geht eine gute Entscheidung. Aber wenn du lieber bei einem allerwelts Core bleiben willst mit guten Debugger und IDE ohne $ dann schau mal bei Silicon Labs rein, die haben auch etwas zu bieten. Ein Eval-Kit kostet nicht viel und ist alles dabei. Ich arbeite sehr gerne mit diesen Teilen, nur mal so als Tip. www.silabs.com Gruß Sascha
debugger: ahso ok bei der geschwindigkeit ist das natuerlich was anderes ;) hab jetzt die kamera in meinem handheld eingebaut. funktioniert soweit auch nur der ausschnitt ist noch immer so klein. das werd ich morgen mal aendern. was etwas bloed ist das die kamera am gleichen port haengt wie das lcd und dram (geht nicht anders nix mehr frei) somit muss das tristate schalten der kamera ueber i2c laufen. das ist ziemlich bloed. naja mal schauen sonst muss ich da noch ein bustreiber zwischenhaengen... die i2c schnitstelle ist aber recht schnell hab mal mit 1mhz probiert und ging einwandfrei... mittlerweile geht auch die konvertierung nach rgb565 einfach: CamSetReg( 0x20c2, 0 ); //to rgb565 setzen. das hatte ich eigentlich schon probiert... hm keine ahnung warum das das letzte mal nicht funktioniert hat. jpg auslesen hatte ich mal probiert aber irgendwie klappt das noch nicht so richtig... der header des jpgs ist zwar noch ok aber irgendwie sind die daten danach muellig... naja ist erst mal fuer mich nicht so wichtig... so recht fuer heute... schoenen abend noch ;)
I2C-Ansteuerung und Antwort empfangen klappt bei mir auch schon. Arbeite mich nebenher weiter vor.
debugger: ah... sehr schoen... nur so zur info wenn du das bild automatisch einliesst: die kamera fuegt noch 208 oder 104 zusaetzliche clocks (horizontal blanking) in jeder zeile hinzu. das musst du in der groesse des speichers beruecksichtigen... sofern du das noch nicht beruecksichtigt hast.
hab gerade noch mal das datenblatt durchwuehlt... wenn man Figure 18. ansieht scheint hsync in der zeit auf lo zu sein... sorry dachte das blanking waer da mit drin...
ahso noch zwei tipps... 1) wenn man nicht den continous mode benutzt sprich wenn man einzelaufnahmen macht muss man anscheinend die exposer time immer neu setzen. tut man das nicht haengt die kamera irgendwie... 2) wenn man die kamera aussliest sollte die zeit die man brauch fuers auslesen jeder zeile gleich lang sein...(ich stoppe ja die mainclock zwischendurch) zuerst hatte ich 50 zeilen gelesen und dann das display aktualisiert dann wieder 50 gelesen usw. das sieht ziemlich bloed aus weil sich die exposer time nicht fuer jede zeile gleich ist... der effekt war dann das ich balken mit unterschiedlicher helligkeit hatte... nun lese ich eine zeile und aktualisier das lcd... geht deutlich besser... ich hab jetzt bei mir noch nen bustreiber rangehaengt damit ich nicht via i2c die kamera auf tristate schalten muss... klappt gut... momentan liegt ich bei um die 20 frames pro sekunde (320*240) mit lcd update... wird aber noch um einiges schneller weil einige sache noch nicht optimiert sind... zudem starte ich noch jeden frame einzeln das ist natuerlich nicht ganz so optimal...
egon schrieb: > ich hab jetzt bei mir noch nen bustreiber rangehaengt damit ich nicht > via i2c die kamera auf tristate schalten muss Über welchen Pin schaltest Du dann die Kamera auf Tristate (oder überhaupt nicht) ? Was verwendest Du als Bustreiber ?
debugger: man kann mit dem: 0x2217 TRICTL [0] RW [0]: Output Tri-state control. 0 outputs enabled 1 outputs tri-stated die outputs auf tristate stellen. das hat nur den nachteil das das recht lange dauert... wenn man jede zeile auf tristate stellen muss dann wieder zurueck... das ist natuerlich lahm deswegen der bustreiber... braucht man natuerlich nicht wenn man genuegend pins noch frei hat... default ist tristate somit muss man die outputs einmal wenigstens enablen sonst erhaelt man keine ausgabe... ich benutz ein 74lvx245d hat 3,3v usw. von reichelt...
Hat schon jemand das ding an einen AVR gehängt. Ich habe damit eine kleine Bildverarbeitung mit nem Roboter vor. 50 x 50 Pixel Wären schon ganz net.
moin, hat denn ueberhaupt schon jemand mal die kamera ausser mir zum fliegen gebracht ? irgendwie bekomme ich nur das subsampling vom imager zum laufen. stelle ich auf den subsampler im image process um bekomm ich nur noch muell. verstehe ich irgendwie nicht. im datenblatt sagen sie das der subsampler im image process besser ist weil gerade kantenschaerfung usw dann besser funktioniert daher moechte ich das gern mal ausprobieren... hat da jemand vielleicht ne idee ? hab ein wenig weitergemacht. die bilder sahen auf dem lcd was ich verwende nicht so prickeld aus. irgendwie sind die gamma einstellungen bei allen beispielen nicht passend fuer mein lcd. daher musste ich mir erst mal eine gamma korretur editor bauen. etwas stressig aber hat sich gelohnt...;) ist auf jeden fall besser aber optimal sehen die bilder noch immer nicht aus. evtl. muss ich mir mal das aufgenommene bild auf dem pc ansehen. wobei sind natuerlich auch nur 65k farben. bei meinem test auf dem pc hab ich ja ycbcr verwendet was ja ein insgesamt mehr farben hat als rgb565... lg ;)
kleines update: irgendwie ist dieses datenblatt ziemlicher mist. da sind so viele fragen offen... z.b. bekomme ich das auto exposure nicht richtig zum laufen... die kamera errechnet eigentlich von allein wie lang die exposure time sein soll ... auch gain fuer rb und g... irgendwie kommt da nur muell raus... daher hab ich bei meinen tests erstmal auto exposure ausgestellt und white balance nicht aus der auto exposure berechnung. gerade die white balance fuehrt dazu das die bilder richtig schlecht aussehen. und siehe da... die bilder sind deutlich besser... mit besserer gamma korrektur vom lcd echt nett. sprich: CamSetReg( 0x20F0, 0 ); //white balance do not use result from aeewb CamSetReg( 0x2040,1 ); //auto exposure off die helligkeit stellt man dann ueber exposure time ein: CamSetReg( 0x2508, exposerTime>>8 );//Exposure MSB CamSetReg( 0x2509, exposerTime&0xff); // Exposure LSB und CamSetReg( 0x2501, 1 ); //gain rb CamSetReg( 0x2503, 1 ); //gain g1 g2 schoener waers natuerlich wenn die kamera die werte selbst ermittelt... aber bisher keine chance... in den auto exposure bereich bei den registern gibt es ein maximalwert fuer die exposure time (0x206b/0x206a)... wenn auto exposure an ist kommt immer der maximalwert. das ist auch der grund warum man die exposure time immer neu setzen muss wenn man einzelaufnahmen macht (siehe weiter oben)... aendert auch nichts wenn man im continous mode aufnimmt... keine ahnung... ich vermute das liegt am imager subsampling ... ich werd nachher mal ein test machen und das bild voll abholen ob dann die berechnung richtig ist...
Angehängte Dateien:
-
26.jpg
54 KB
moin, oben ein bild im betrieb meines handhelds... wie man sieht kann man gain und belichtungszeit per hand einstellung (warum siehe unten)... hm ist nicht sehr scharf das aufgenommene bild... bei meinem ersten test hab ich das ganze bild aufgenommen und dann per hand subsampling gemacht... das sub sampling nach dem imager ist eigentlich unbrauchbar... zumindest fuer mich... das problem dabei ist das der imager wirklich die daten reduziert... beim anderen sub sampler wird nur die output clock reduziert sprich man liest mit der geschwindigkeit als waere es eine volle aufloesung... ziemlicher kaese vielleicht eine einstellung keine ahnung... @auto exposure und white balance... habe ich fast zum laufen gebracht man muss wenn man sub sampled noch die groesse des bereichs fuer auto exposure und white balance aendern... das die exposure time geaendert wird hab ich bis heute noch nicht hinbekommen.. aber das auto gain sprich die helligkeit vom bild... nur irgendwie schaltet er immer hin und her keine ahnung wieso... deswegen hab ich erst mal die helligkeit einstellbar gemacht... jetzt noch das bild speicherbar machen und dann ist das thema durch... ziemlicher nervkram ehrlichgesagt... hab echt keine lust mehr ;) die kamera kann zwar viel aber unglaublich anstrengend mit dem datenblatt ... dauernd probiert man rum wie was funktionieren koennte... das problem ist halt aktiviert man sub sampling muss man 1000 andere sachen einstellen ...
@egon Bin nur Mitleser, da ich hier aus der Türkei keine Möglichkeit habe, bei Pollin einfach so mal 'ne Bestellung aufzugeben. Ich möchte Dir aber zu Deiner Arbeit, voallem zu Deiner Geduld und Hartnaeckigkeit gratulieren!
Hallo egon, ich habe heute den Pollin Katalog bekommen und bin auf die AU-85 Farbkamera und dadurch auf diesen Beitrag gestoßen. Ich arbeite ebenfalls mit einem PIC32 wodurch dieser Beitrag super für mich passt :) Könntest du evtl die gesamten Sourcen deines Projekts posten (inclusive assamber etc.)? Wäre echt super :). Eine Farbkamera auslesen klingt echt cool und für 2.95€ ist das sehr interessant für mein Projekt :) Vielen Dank und Gratulation für die tolle Arbeit Andi
Hallo, Ich bin das erste mal in einem forum... Ich benötige eure hilfe, ich werde massiv gestalkt und möchte entlich mal wieder mein auto sicher abstellen können. Und dazu 4 oder mehr kameras einbauen. Dazu habe ich mir mehrere der au-85 gekauft und würde gern eine sehr simple mitzeichnung aufbaun. Am besten wie oben beschrieben Cam>Atmega>Sd und das wenn möglich mit endlos-speicher und bewegungsmelder gern auch per radar zb. X-band. Leider habe ich bis jetzt nur mit Bascom kleine steuerung wie eine Automatische Säge mitrde Atmega8515 zusammen gebaut. Und experimentiere gerade mit ein paar Arduinos Könnt ihr mir da helfen würde gern auch in C starten... um so schneller ich da was funktionierendes zusammen bekommen würde um so besser. Danke,Danke,...
Frank T. schrieb: > Ich benötige eure hilfe, ich werde massiv gestalkt und möchte entlich > mal wieder mein auto sicher abstellen können. Die Stalkingfälle haben hier in den letzten beiden Tagen aber massiv zugenommen, auch Thomas D. ist betroffen: Beitrag "Peilsender aufspüren" Ich würde allerdings eher Trollen statt Stalken vermuten.
@Dirk Sorry das das mit dem salking über die feiertage immer so zunimmt.. Aber genug damit. Gibt es ein schaltplan mit dazugehörigem protokoll (gern auch skizzenhaft) wie ich die jpg daten aus dem Kamera modul bekomme möglichst hochauflösend und störungsfrei? Und das möglichst auf "Knopfdruck" den rest versuch ich gern auch selber(Speichern und so)... Ir-scaner als auslöser hab ich fast fertig. Achso: Respect was ihr da immer auf die "Beine" stellt.
Frank T. schrieb: > Ir-scaner als auslöser hab ich fast fertig. Na dann ist doch der Rest ein Klacks!
> Na dann ist doch der Rest ein Klacks!
Da ist nur ein Analogeingang und ein Servoausgang nötig, kein Protokoll
und keine Pinbelegung wichtig.
Hab bis jetzt noch nie so richtig erfolg mit kommunikation zwischen
atmel und zubehör wie zB. einer Kamera gehabt.
Frank T. schrieb: > Hab bis jetzt noch nie so richtig erfolg mit kommunikation zwischen > atmel und zubehör wie zB. einer Kamera gehabt. Mach es dir einfacher und kaufe dir: Mini DV Camcorder PMDV80 für 19,95 € http://www.pollin.de/shop/dt/ODI5OTcyOTk-/Computer_und_Zubehoer/Multimedia/Kameras/Mini_DV_Camcorder_PMDV80.html
> Mach es dir einfacher und kaufe dir: > > Mini DV Camcorder PMDV80 für 19,95 € Klingt immer alles super aber ich will nicht aller 2tage die Sd-card leeren müssen um dann festzustellen das wenn es drauf ankommt das Ding voll ist. Hab schon solch zeugs im einsatz gehabt bis es entwendet wurde... toll ist anders...und Reifen zerstechen macht keine 60dB. Irgend ein tool fehlt immer! Deshalb diese Kamera, weil günstig und schön klein.
mhhh der source code und evtl ein schaltplan wär net schlecht... Biiiiiiiiiiitte upload ;) Hab sonst leider nix gefunden...
Das Ding scheint leider ausverkauft :-( Hat jemand eine Ahnung ob es das Modul sonst wo noch gibt ? Viele Gruesse, der Doc
Der Doc schrieb: > Das Ding scheint leider ausverkauft :-( > Hat jemand eine Ahnung ob es das Modul sonst wo noch gibt ? Hä? Wenn ich auf den Link im ersten Beitrag dieses Threads klicke, dann steht da im Status bei Pollin immer noch "Artikel verfügbar." Oder meintest Du ein anderes Modul?
Hmmm seltsam... Tut mir leid fuer etwaige Verwirrungen. Ich hab das Modul gesucht und da war es ausverkauft... Nun is es wieder da? Sehr seltsam. Aber dennoch vielen Dank. War schon auf der Suche nach Ersatz :-)
Kann sein, daß Pollin nachbestellt hat, wegen des großen Erfolges. :) Manche Artikel sind keine einmaligen Angebote, sondern tauchen später wieder auf.
Zur zeit sind 392 Exemplare dieses Schnäppchens verfügbar. Man kann zwar unbegrenzt viele Exemplare in den Warenkorb legen, beim Gang zur Kasse wird einem dann mitgeteilt, daß nur noch 392 Stück verfügbar sind. Werde das Teil aber nicht kaufen, da meine perönliche Aufwands/Risiko Analyse negativ ausgefallen ist. Your mileage may vary.
Hallo Egon und die anderen, die diese Kamera zum Funktionieren gebracht haben: ich krieg die I2C-Verbindung nicht hin. Ich habe die Kamera an einen ATmega16 angeschlossen und versucht, mittels I2C-Verbindung die Register zu beschreiben. Leider bis jetzt kein Erfolg. Gibt es irgend etwas Besonderes zu beachten? Ich versuchte, so vorzugehen, wie in dem Datenblatt beschrieben: I2C-Adresse 0x45, 2 Adressbytes für das Register, 1 Datenbyte. Als SCL-Taktfrequenz wählte ich ca. 100 KHz. Habe auch für SCL und SDA je einen 4.7 kOhm-Pull-Up-Widerstand eingebaut. Da es nicht funktionierte (Oszilloskop: SCL bleibt nachher low, Ausgänge bleiben vermutlich Tristate trotz Enable-Outputs-Kommandos), testete ich den I2C-Code im ATmega an einem EEPROM 24C32 (natürlich dann mit der für dieses gültigen Adresse 0x50) und dort funktionierte die Verbindung problemlos. Die Kamera habe ich sorgfältig auf eine kleine Adapterplatine gelötet, es gibt keine Kurzschlüsse und keine Unterbrechungen. Danke und Grüße, I.
Egon Winter: das problem hatte ich auch... die kamera brauch einen takt sprich mainclock um i2c zu bedienen sonst passiert nichts der scl reicht nicht... @source... ich hab momentan leider wenig zeit daher auch die spaete antwort... ist ehrlich gesagt auch keine grosse magie drin... der init code ist wichtig den kann ich mal posten bei zeiten... der rest ist nur signale setzen auch daten holen... @schaltplan... der ist noch trivialer bis auf die zwei widerstaende fuer i2c wird kein zusaetzliches bauteil benoetigt... sprich hsync,data,sda, scl und mainclock an die cpu... den rest brauchte ich nicht wie vsync oder pixclock...
ahso noch eine wichtige sache... wenn ihr wie ich die mainclock per hand steuert ist es wichtig den clockgenerator so zu stellen das er auf bypass ist... wenn man das nicht tut kann logischerweise der pll sich nicht locken und es geht gar nichts...
egon schrieb: > ahso noch eine wichtige sache... wenn ihr wie ich die mainclock per hand > steuert ist es wichtig den clockgenerator so zu stellen das er auf > bypass ist... wenn man das nicht tut kann logischerweise der pll sich > nicht locken und es geht gar nichts... Das passiert auch über den Init-Coder, der via I²C gesendet wird, oder?
die initialisierung mache ich erstmal mit pwm aus dem pic32... damit sich der pll locken kann... ausserdem wichtig sind die auch die die wartezeite nach dem einschalten... nach dieser zeit wird auch der clockgenerator umgestellt... die pwm stelle ich aus wenn ich anfange ein bild einzulesen... ab dort toggle ich die clock per hand... ich denke es macht mehr sinn wenn ich nicht den vollen source uploade a) ich verwende viele routinen aus meiner lib die ich nicht veroeffentlichen werde b) ausser pic32 user eh keiner was damit anfangen kann also mehr ein quasi source wo als kommentare steht was zu tun ist oder so...
@egon danke das du geschrieben hast! Wusst nict genau ob der thread ne leiche ist aber wenn du nur viel um die ohren hast ist ja alles ok :) Ich habe heute die kameras bekommen und mal ein paar Kabel hingelötet. Werde es dann in den kommenden tagen (je nach zeit und lust :) ) mal austesten. Wegen dem Schaltplan hatte ich nur bedenken wegen der relativ hohen Taktrate aber wenn das kein Problem ist dann passt das ja... Das man den VSYNC nicht brauche hab ich mir schon gedacht, aber warum brauchst du den pixclock nicht? Ist dieser nicht der OutputClock der zum lesen der Daten benötigt wird? Oder verwendest du hier auch den Mainclock? @Helge Tefs So wie ich das sehe ja :) Gruß Andi
ups hatte helge's text zwar gelesen und da fiel mir der tip ein mit dem pll ein und dann die frage vergessen ;)... ja wird auch ueber i2c gemacht... daher ist es wichtig am anfang das mit pwm zu machen... @Taktrate... ne das ich kein problem... auf meinem testboard hab ich so 8 cm fädeldraht genommen... @pixclock... ich setze ja den clock generator so wie ich ihn brauche... die mainclock steuere ich per hand damit weiss ich ja bei welcher flanke was kommt... kommt aber auch die anwendung drauf an... wenn man z.b. jpg export macht gibts auch modes wo die pixclock zum takten verwendet wird... oder besser die pixclock ist dann nicht durchgängig... das haengt aber vom export mode ab... fuer meine anwendung brauchte ich es nicht... den jpg export habe ich nur mal angefangen ... klappte aber irgendwas nicht richtig daher hol ich es als raw ab... steht weiter oben was zu... reicht fuer mich ;)
egon schrieb: > die mainclock steuere ich per hand damit weiss ich ja bei welcher flanke > was kommt... Heisst das, dass man die mainclock, nachdem man auf "bypass" gestellt hat, toggeln kann, wie man lustig ist ? D.h. mal alle 10 Takte, mal alle 30 z.B.? Klingt so, frage aber zur Sicherheit, weil ich bei anderen Sensoren gelesen hab, dass die teilweise ganz empfinglich reagieren kann auf ein paar Prozent Abweichung.
@egon:
danke für die Hinweise mit der Main Clock und der Takterzeugung. Ich
habe einen externen Taktgenerator angeschlossen, und die
I2C-Schnittstelle funktionierte. Es ist dafür offenbar eine
Mindest-Taktrate nötig. Mit 1 MHz ging es nicht, aber mit 4.9152 MHz.
Habe es dann aus dem OC2-Ausgang des ATmega16 mittels CTC-Mode (mit dem
Timer2) die halbe Taktfrequenz des Mikrocontrollers gewonnen (das sind
dann 3.6864 MHz), damit funktioniert es auch.
Wenn ich Dich richtig verstanden habe, muß man zum Initialisieren der
Kamera und zum Beschreiben der Register den Takt für die Kamera etwa so
wie oben beschrieben erzeugen.
Zum Auslesen der Bilddaten kann man dann den Takt softwaremäßig ("von
Hand") erzeugen, also durch asm-Befehle, die einen Ausgang ständig
umschalten, und nach der passenden Anzahl solcher Takte die Pixeldaten
auslesen.
Zum erneuten Start einer Aufnahme muß vorübergehend wieder auf die
Takterzeugung via OC2/Timer2 gewechselt werden, weil dafür Register
beschrieben werden müssen und die I2C-Schnittstelle benötigt wird, usw.
Ich glaube, das genügt, um die Kamera zum Laufen zu bringen.
Nochmals danke, Grüße,
I.
Ziegenpeter: wie man lust ist nicht... die kamera ist auch empfindlich in der hinsicht... ich hab erst noch einen timer laufen lassen nebenbei diesen hat man dann im bild gesehen. das toggeln per hand habe ich nur gemacht um das zeitkritische bisschen rauszunehmen. sonst muesste ich taktgenau die daten abgreifen das laesst sich mit ner cpu mit der geschwindigkeit (auch wenns 80mhz sind) schlecht realisieren... also irqs aus und auslesen und dabei bisschen drauf achten das pro zeile die zeit einigermassen gleich ist. was geht ist nach dem auslesen einer zeile eine taktpause einzulegen dies nutze ich um das lcd upzudaten... Egon Winter: genau...;) viel erfolg
anbei die initialisierung und das auslesen via pseudo code... ich denke das muesste reichen um der kamera etwas zu entlocken...
ahso noch was vergessen ;) die ausgabe ist rgb565 408x302 pixel... wobei ich wie man sieht nur 240 zeilen auslese...
@egon: Kannst du die assambler sequenz zum auslesen des PORTS posten (PIC32)? Welche Taktrate schaffst du letztendlich?
Angehängte Dateien:
-
I2C_CAM.png
2,5 KB -
I2C_CAM_2.png
2,9 KB
also habe jetzt mal die cam angeschlossen :) Leider antwortet sie noch nicht auf meinen I2C. Habe auf den EXCLK 5MHz PWM drauf gelegt da die kamera das anscheinend so will aber leider ohne erfolg :( Hab mal zwei bilder mit meinem PC-Scope gemacht. Die 5Mhz sehen bissle verzockt aus aber des liegt glaub an meinem Oszi das da schon an die Grenzen stößt :) Den Hardware I2C habe ich bereits mit einem Temp. Sensor getestet (allerdings den I2C2 und jetzt nehme ich den I2C1) sollte aber eigendlich gleich funktionieren... gruß Andi
hab jetzt mal die pullups von 2.4k auf 1k verkleinert um die 3mA zu gewährleisten und die flanken zu verbessern aber leider ohne erfolg?!
Angehängte Dateien:
-
AU85Test.jpg
8,6 KB
Hallo, ich habe es jetzt geschafft, mit einem ATmega16 Bilder mit dieser Kamera zu bekommen. Nicht zuletzt dank der hilfreichen Hinweise von Egon. Die Bilddaten übergebe ich mittels serieller Schnittstelle an ein Bluetooth-Modul (eingestellt auf 460.8 kBaud), und dieses überträgt diese Daten an ein Notebook. Das Auslesen eines Bildes mit 320 x 240 Bildpunkten dauert etwa 10 Sekunden, eine Zeile dauert etwa 35 msec. Ich fürchte jedoch, daß die Zeilen nacheinander belichtet werden (Durch Bewegen werden die Zeilen verwischt, die gerade ausgelesen werden). Andi: mit Pull-Up-Widerständen von 1.8 kOhm funktioniert es sicher, größere habe ich nicht probiert. Aus dem Bild, daß Du beigefügt hast, entnehme ich, daß der I2C-Takt (SCL) etwa 400 kHz hat. Probiers mit weniger (eventuell ist ein minimales Verhältnis von EXCLK-Frequenz und SCL-Takt notwendig. Mit 3.6864 MHz EXCLK und 100 KHz SCL-Takt funktioniert es bei mir). Grüße, I.
Angehängte Dateien:
-
I2C_CAM_3.png
2 KB -
I2C_CAM_4.png
2,8 KB
@egon Winter: Schade daran liegts wohl net :(
haha hab mein fehler gefunden sry :) Mein EXCLK gieng in PIXCLK :) Jetzt funtzts so wies aussieht, also die cam feuert die daten und HSYNC raus (ich sehe es auf dem eval board einmal wild blinken :) ) Jetzt muss ich mich "nur noch" ums auslesen kümmern...
egon: super... endlich nen zweiter der dem teil mal ein bild entlockt :) andi: ja denn steht ja auch nicht mehr viel im weg... so ich zieh noch los heute... schoenen abend noch...
Hallo Egon Winter, ich will die Kamera mit einem Atmega 644 auslesen. Da wären die Sourcen schon hilfreich. Willst du die vielleicht mal hochladen? Das würde mir sehr helfen. Ich will die Kamera danach mit dem CPLD Board streamen und in einen externen Speicher schreiben (also nicht so viel Aufwand). Da das schnell geht, hoffe ich, dass dann die Helligkeitsunterschiede nicht zu stark sind, wie oben beschrieben. Im Gegenzug würde ich mich bereit erklären eine kleiche Platine zu machen und die hier hochladen. Damit das im Schaltplan alles mal ein bisschen dokumentiert ist für die Ewigkeit! ;-) Gruß, Jens
Hallo Jens, ich lade die Teile des Quelltextes hoch, die sich direkt auf die Kamera beziehen. In BI8921.Inc sind Funktionen zum Beschreiben der Register für die Initialisierung und das Auslösen der Aufnahme. Die Register und ihre Werte habe ich vom anderen Egon übernommen (siehe einige Postings weiter oben). AU85CAM.ASM ist die Hauptdatei. Die wichtigen Funktionen sind: SelectAutoClock (schaltet den OC2/Timer2-Takt ein, der mit 3.6864 MHz läuft = halbe Taktfrequenz des ATmega16). Damit erfolgt jeder Zugriff auf die Register. SelectManualClock schaltet den OC2/Timer2-Takt aus, zum Auslesen des Bildes muß der Takt "von Hand", durch Hin- und Herschalten eines Ausgangs erzeugt werden. EXCLK (Pin 5 von Port C) und OC2 (Pin 7 von Port D) sind verbunden, eines von beiden muß immer hochohmig (Tristate) sein. ReadImage ist die Funktion zum Auslesen des Bildes. Es wird gewartet, bis HSYNC positiv wird, dann in zwei verschachtelten Schleifen (Zeilen und die Pixel einer Zeile) die nötigen Takte ausgegeben und die Pixel eingelesen. r25:r24 = Zeilen, r23:r22 = Pixel in der Zeile, r21:r20 = Takte pro Zeile. Ein Pixel benötigt zwei Takte (da 16 Bit, RGB565), nach jedem Takt wird ein Byte (Port A Pin 0..7) eingelesen und hier über den USART an ein Bluetooth-Modul ausgegeben. SnapShotSmall löst die Aufnahme aus und ruft dann ReadImage auf (Subsampling R2S6 hor. und vert., 400 x 300 Pixel, 1184 Takte pro Zeile) SnapShotMedium und SnapShotLarge sollen das gleiche für halbe und volle Auflösung tun, es funktioniert aber zur Zeit nur SnapShotSmall. Das ist alles, was für das Verständnis wichtig ist. Der Rest von AU85CAM.ASM ist Bluetooth-Initialisierung, USART-RX-Interrupt, Funktionen für die Verarbeitung von Bytes, die vom USART empfangen werden (über Bluetooth gesendete Kommandos). Einige #include-Anweisungen in AU85CAM.ASM verweisen auf Bibliotheken, die ich nicht hochlade. Sie haben keinen unmittelbaren Bezug zu dieser Kamera. Grüße, I.
@egon (Gast)
Hi Egon,f
ist echt super geworden dein handheld. RESPEKT!
Ich komme nicht weiter und hätte zwei Fragen.
Wieso wartest du in der Schleife do{...}while( picLine != 240 ); am
Anfang und am Ende auf HSYNC läuft doch durch oder ?
Die zweite Frage wäre, was meinst du mit:
// two clocks to get one byte !
muss man zweimal per Hand CLK anlegen und dann lesen ?
Ich habe den code von egon2 angeschaut der macht keine zwei CLK ?
Danke !!
Gruß,
CWI
Angehängte Dateien:
-
AU85TST7.jpg
32 KB -
AU85TST6.JPG
280 KB
Hallo CWI: die zwei Clocks gelten pro Pixel. Jedes Pixel besteht aus zwei Bytes (z. B. bei der gewählten Register-Einstellung RGB565 = 16 Bit), sodaß pro Clock ein Byte ausgelesen wird. Ich habe meinen Code inzwischen verbessert: 1. takte ich nicht mehr "von Hand", sondern weiter mit dem Timer2/OC2-Ausgang, aber beim Pixel-Auslesen langsamer eingestellt. Vorteil: konstante Geschwindigkeit, daher gleichmäßige Belichtung des ganzen Bildes beim Durchlauf des "Rolling Shutters". Das in meinem oberen Posting angeführte Umschalten von zwei verbundenen Ausgängen mittels Tristate wie oben ist natürlich vollkommen überflüssig und Blödsinn - EXCLK nur noch an OC2=D7. 2. verwende ich PIXCLK zum eigentlichen Auslesen. PIXCLK habe ich dazu an den INT2-Eingang gelegt, in der Interrupt-Routine findet der Auslesevorgang statt (fallende Flanke von PIXCLK, und wenn HSYNC auf logisch 1 liegt). Mit diesem Schema ist es auch recht einfach, JPEG-Bilder auszulesen (zweites Bild). Etwas ist mir aufgefallen, was ich nicht verstehe: Da ich die ausgelesenen Daten seriell in die Bluetooth-Schnittstelle schicke, ist der Vorgang langsam und dauert viele Sekunden pro Bild. Wenn es nun mehr als 20 Sekunden sind, dann entsteht ein Bereich, der überbelichtet ist und etwas rotstichig, und ab dann ist das Bild nur noch grau (siehe Bild). Grüße, I.
CWI: danke @handheld... :) das warten hat den sinn das ich a) nicht die volle x breite abhole b) die kamera noch nach dem hsync eine austaskluecke sendet... zudem beginnt die kamera auch nach dem aufnehmen nicht direkt mit dem hsync und wartet einen moment... die laenge haengt ab von der belichtungsdauer...
Hi egon's, oh man ich hatte in deinem pseudo-code überlesen das du am ende der Zeile auf HSYCN low wartest. Deshalb auf meine dumme Frage. Danke nochmal ! Im Anhang meine Version eurer Arbeit. Verwende eine SD-Card an der SPI für die Bilder. FAT File von Elm ChaN I2C von Peter Fleury Gruß, CWI
Habe so eine Kamera übrig, gegen 3 EUR inkl. Versand würde ich sie gerne jmd zuschicken, der sich damit beschäftigen möchte. Unbenutzt.
Hallo, habe der Kamera mal wieder etwas aufmerksamkeit geschenkt und mich etwas in den PIC32 assembler eingearbeitet. Habe jetzt eine Routine zum auslesen der Daten geschrieben, welche mir die Daten erstmal in Flash schreibt. Dies funktioniert mit der simulation auch ganz gut :) Leider kommt bei Hardware der HSYNC den ich an PORTA_10 angeschlossen habe nicht durch (mit dem Oszi sehe ich ihn aber mein Programm leider nicht :) ) Hier ist meine Interpetation von WHILE(!HSYNC){ //do one clock } in assembler (die ersten zeilen sind nur daten die ich später brauch): asm("lui $t0, 0xbf88"); // base address Port asm("addiu $t1, $zero, 2"); // t1 = 2 (for RD1) asm("lui $t2, 0x7d01"); // base address user flash asm("addiu $t3, $zero, 640"); // t3 = 640 asm("lui $t4, 0x0400"); // Mask BIT_10 for HSYNC asm("srl $t4, $t4, 0x0010"); asm("addiu $t5, $zero, 480"); // t5 = 480 //-------------------------- Read line --------------------------\\ asm("lw $at, 0x6010($t0)"); // Get HSYNC (wait for HSYNC high) asm("and $at, $at, $t4"); asm("bgtz $at, 16"); asm("sw $t1, 0x60E8($t0)"); // MAINCLK = 1 asm("sw $t1, 0x60EC($t0)"); // MAINCLK = 0 asm("b -24"); ... Wie bereits gesagt, mit der simulation und dem stimulus zum testen funktiert alles. Mit der Harware funktioniert der main clock, aber der HSYNC wird leider nicht erkannt. Über PORTSetPinsDigitalIn(IOPORT_A, BIT_10); setzte ich zuvor den Pin als digitalen Eingang. Evtl. kann mich jemand (z.B. egon g ) da weiterhelfen. Gruß Andi
andi:
man muss nicht alles in assembler schreiben... man erreicht durch c fast
den gleichen code... ich benutze assembler nur da wo es wirklich noetig
ist... ich bin zwar auch ein assembler-fan aber wenn ichs nicht
unbedingt muss mach ichs auch nicht ;)
das was du machst ist etwas gefaehrlich und unsauber... hab ich am
anfang auch gemacht und bin nur in probleme gelaufen... und tierisch
geflucht ueber den inline assembler...
ein problem ist der optimizer im prinzip weiss der c compiler nicht was
du da tust und kann gut sein das er sachen einfach wegoptimiert... und
glaub mir das tut er...
wenn du inline asm benutzt entweder sauber sprich mit ausgabeliste ,
eingabeliste und clobberliste... das ist aber leider nicht so richtig
einfach weil es keine richtige doku gibt in sachen inline assembler...
oder asm volatile in jeder zeile und beten das compiler die regs nicht
vergibt die du benutzt... aber wuerd ich nicht mehr machen sowas...
wenn du alles in asm machen willst... machs in einem eigenen .s source
alles andere ist kaese ;)
kleiner tipp. (wichtig ist optimiser >= 1) !
int *portBase = 0xbf880000;
// lata = 1
*(portBase+0x6020/4) = 1;
// latb = 1
*(portBase+0x6060/4) = 1;
erzeugter code ist:
37: int *portBase = 0xbf880000;
9D00003C 3C03BF88 lui v1,0xbf88
38:
39: // lata = 1
40: *(portBase+0x6020/4) = 1;
9D000040 24020001 addiu v0,zero,1
9D000044 AC626020 sw v0,24608(v1)
41:
42: // latb = 1
43: *(portBase+0x6060/4) = 1;
9D000048 AC626060 sw v0,24672(v1)
schneller bekommst du das direkt in asm auch nicht hin... ich machs
mittlerweile fast nur so das ich den c code so forme damit der code
rauskommt den ich haben will... der vorteil ist das du es auch noch in
einem jahr verstehst oder du kannst auch mal teile mal eben rauskopieren
und wo anders verwenden... was auch immer...
daher schreiben und disassembly window ansehen... aber vorsicht das
disassembly window zeigt teilweise richtigen muell an... wenns denn so
ist es besser das memory window zu benutzen...
anbei noch ein kleines tutorial was ich mal geschrieben hab fuer mich
selbst als referenz fuer pic32 assembler bzw. optimierung...
normalerweise ist das 20 seiten lang ich veroeffentliche mal nur den
inline assembler teil weil der andere kram noch teilweise mit fehlern
ist...
mittlerweile gibt es noch mehr was ich rausgefunden habe beim inline
assembler steht aber leider nicht drin ;) aber sollte erstmal reichen
fuer den anfang...
zu deinem problem... schau dir den code mal im disassembly window an
bzw. memory... da wird dir auffallen das die zeile asm("lw $at,
0x6010($t0)");
fehlt (bei mir zumindest)... anscheinend liegt das an deinem kommentar
// am ende... loesch die zeile mal dann kommts rein...
was es noch sein koennte... ra10 ist glaub ich auch ein analog pin...
sprich du musst diesen pin auch als digital in setzen... evtl. ein
problem
macht man mit:
AD1PCFGSET = 0xffff;
viel glueck und lg ;)
ops ich seh gerade die formatierung der rtf-datei ist etwas merkwuerdig... anscheinend sind sich da open office und word nich ganz einig ;)
@ egon: Danke für die info! Das man das Auslesen auch mit C machen kann wusste ich nicht. Habe gedacht des wäre zu langsam... >schau dir den code mal im disassembly window an >bzw. memory... da wird dir auffallen das die zeile asm("lw $at, >0x6010($t0)") Hehe, das ist mir auch aufgefallen. Habe gedacht das wär ein bug vom compiler :) Habe deswegen in Wirklichkeit auch asm("lw $at, 0x6010($t0)"); // Get HSYNC (wait for HSYNC high) asm("lw $at, 0x6010($t0)"); // Get HSYNC (wait for HSYNC high) stehen gehabt damit die Zeile auch wirklich so im Disassambly steht. Das dies am optimizer liegt wusste ich net! Naja egal, ich habs jetzt wieder in C umgeschrieben. Leider bin ich immernoch unfähig den HSYNC auszulesen... Habe hierfür die Cam vom Evalboard abgesteckt und den Pin manuel mit nem Taster auf high gesetzt -> das tut! Hier ein Ausschnitt aus main():
1 | |
2 | /* Open Timer2 with Period register value */
|
3 | OpenTimer2(T2_ON, T2_PS_1_1 | 0x10); //10 = 5 MHz; |
4 | |
5 | /* Enable OC | 32 bit Mode | Timer2 is selected | Continuous O/P | OC Pin High , S Compare value, Compare value*/
|
6 | OpenOC2( OC_ON | OC_TIMER_MODE32 | OC_TIMER2_SRC | OC_CONTINUE_PULSE | OC_LOW_HIGH , 0x10, 0x08); |
7 | |
8 | |
9 | CameraInitAndCapture(); |
CameraInitAndCapture() ist dann genau die Funktion die du gepostet hast (nochmal danke ;) )! Hier das ende von CameraInitAndCapture():
1 | // start exposure
|
2 | CamSetReg( 0x2220, 0x1 ); |
3 | CamSetReg( 0x2220, 0x0 ); |
4 | picLine = 0; |
5 | |
6 | int tmpDat; |
7 | char *PointerFlash; |
8 | int rowCount = 0; |
9 | |
10 | // ** pwm off
|
11 | CloseOC2(); |
12 | |
13 | PORTSetPinsDigitalOut(IOPORT_D, BIT_1); // MAIN CLOCK (EXCLK) |
14 | |
15 | //-------------------------------------------
|
16 | |
17 | //--------------------------------------------------------------------------
|
18 | // start read out
|
19 | |
20 | PointerFlash = 0x7D010000; |
21 | do
|
22 | {
|
23 | |
24 | //** wait for hsync high
|
25 | while(mPORTEReadBits(BIT_8)==0) |
26 | {
|
27 | mPORTDSetBits(BIT_1); |
28 | mPORTDClearBits(BIT_1); |
29 | }
|
30 | while(rowCount < 640) |
31 | {
|
32 | // ** get the data from the cam
|
33 | // two clocks to get one byte !
|
34 | // i received 320*2 bytes for the lcd
|
35 | mPORTDSetBits(BIT_1); |
36 | |
37 | tmpDat = mPORTERead(); |
38 | *PointerFlash = tmpDat; |
39 | PointerFlash++; |
40 | |
41 | mPORTDClearBits(BIT_1); |
42 | ++rowCount; |
43 | }
|
44 | |
45 | ++picLine; |
46 | |
47 | // ** lcd update
|
48 | |
49 | //** wait for hsync low
|
50 | while(mPORTEReadBits(BIT_8)!=0) |
51 | {
|
52 | mPORTDSetBits(BIT_1); |
53 | mPORTDClearBits(BIT_1); |
54 | }
|
55 | } while( picLine != 240 ); |
56 | |
57 | // ** pwm on
|
58 | ConfigIntTimer2(T2_INT_ON); |
Zum testen habe ich in main wie folgt verändert:
1 | |
2 | /* Open Timer2 with Period register value */
|
3 | OpenTimer2(T2_ON, T2_PS_1_1 | 0x10); //10 = 5 MHz; |
4 | |
5 | /* Enable OC | 32 bit Mode | Timer2 is selected | Continuous O/P | OC Pin High , S Compare value, Compare value*/
|
6 | OpenOC2( OC_ON | OC_TIMER_MODE32 | OC_TIMER2_SRC | OC_CONTINUE_PULSE | OC_LOW_HIGH , 0x10, 0x08); |
7 | |
8 | // ** pwm off
|
9 | CloseOC2(); |
10 | |
11 | while(mPORTEReadBits(BIT_8)==0) |
12 | {
|
13 | }
|
14 | |
15 | |
16 | CameraInitAndCapture(); //hier ein Breakpoint |
Der Befehl AD1PCFGSET = 0xffff; habe ich natürlich auch getestet -> ohne Erfolg. Hat es was mit damit zu tun, das ich einer funktion polle (wohl eher nicht?!) Bitte um Hilfe... Vielen Dank Andi
Hallo Ihr, welche Datenleitungen habt Ihr an euren Kameras angeschlossen? Theoretisch kann ich mit einem DCMI Interface auch alle 8 Leitungen anschließen oder? Oder funktioniert es auch, wenn ich das ganze auf 4-Bit laufen lass? Also D0-D3 HSYNC, VSYNC PIXCLK und MCLK ?
ich habe die 8 datenleitungen, hsync, mainclk und i2c angeschlossen... 4 bit funktionieren meines wissens nicht... grus andi
Hmm okay, da ich am STM32 einen Pin mit PIXCLK habe frage ich mich wie ich diesen Beschalten muss. Weil generell hat dieser F4 Typ schon ein DCMI Interface, ich wäre ja dumm es nicht zu benutzen ;-)
Dennis X. schrieb: > Hmm okay, da ich am STM32 einen Pin mit PIXCLK habe frage ich mich wie > ich diesen Beschalten muss. Weil generell hat dieser F4 Typ schon ein > DCMI Interface, ich wäre ja dumm es nicht zu benutzen ;-) Wie wäre es denn, wenn Du das DCMI vom Controller ganz einfach 1:1 mit der Kamera verbindest? Wenn ich das Datenblatt z.B. vom STM32F407 richtig deute, dann hat der nämlich sogar einen dazugehörigen Daten-Anschluß: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/DM00037051.pdf Seite 16, rechts oben Wenn Du bei ST ein wenig suchst, dann findest Du auch die Beschreibung samt Schaltplan zu einem Evaluation-Board mit einem Haufen Multimedia-Krempel drauf. u.A. einer Kamera... Gruß, Helge
Die Ergänzung für die Faulpelze: http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/DM00036746.pdf Seite 46...
So, also ich hab soeben geschaut. Bei ST gibt es dieses Eval-Board mit Kamera und Dsiplay. Die machen das allerdings über einen externen IC. Ich kann nun grad aber nicht erkennen, welcher das sein soll. Der Takt für die Mainclk. wird auch über einen Quarz gemacht. Die I²C Leitungen gehen auch nicht zur Kamera sondern zum Controller. Im Anhang hab ich das Datenblatt auf Seite 46 ist der Schaltplan von dem Teil. Wie ist das hier gemeint? Warum verbinden die das nicht direkt? Danke schonmal! Edit.: Exakt das Datenblatt von oben ;-) hab ich ja gefunden... Edit Edit: Kann es denn sein, dass der IC 24-5805- die Kamera selber ist? Ich seh den Wald vor lauter Bäumen nicht mehr -.-
Schau mal in obigem Datenblatt auf Seite 15. Da ist ein schönes Foto. Was steht dort neben der Camera? Richtig, CN15. Was steht auf Seite 46 im Schaltplan neben/über dem fetten "IC"? Genau, auch CN15. Also ist CN15 der Connector, auf den die Kamera direkt gesteckt werden kann :) CN23 ist der "Camera-Extension-Connector" (Seite 36). Der ist dafür gedacht, daß man z.B. auch eine andere Kamera, als die auf Position CN15 stecken kann. Soweit ich das aus dem Schaltplan erkenne, gehen also alle Leitungen von der Kamera direkt zum Mikrocontroller. Und ja, der Haupttakt der Kamera kommt aus einem Quarzgenerator (24MHz, U27). Gruß, Helge
Andi: schau mal mit nem oszi ob hsync ueberhaupt von der kamera kommt... ich mein wenn der taster geht liegts ja nicht am code... und wirklich alles richtig angeschlossen ? den CamSetReg( 0x2217, 0x0 ); hast du auf jeden fall drin ? wenn der nicht gemacht wird ist die kamera im tristate...
also zweites wuerd ich mal die mainclock mit dem oszi untersuchen wenn er in der die while-scheife haengt...
Okay, besten Dank! Jetzt hab ich nur noch kurz eine Frage zum Interface auf dem STM32F4. Da überschneiden sich jetzt die DCMI-Pins mit denen vom SDIO-Interface. Was jetzt erstmal heißt, dass ich nur eins von beiden anschließen kann. Aber die Kamera und die SD-Karte haben ja beide einen CS. Also könnte ich doch diese Leitungen doppelt verwenden muss dann aber bei der Programmierung darauf achten, dass immer nur einer an ist oder?
Sollte theoretisch gehen, allerdings kannst Du da schlecht ein Bild, das Du gerade von der Kamera einliest, gleichzeitig auf die SD-Karte speichern.
Helge Tefs schrieb: > Sollte theoretisch gehen, allerdings kannst Du da schlecht ein Bild, das > Du gerade von der Kamera einliest, gleichzeitig auf die SD-Karte > speichern. Joa und genau da sehe ich bei dem STM32F415 ein großes Problem. Denn es gibt zwar teilweiße Pins doppelt, damit man beispielsweiße andere Funktionen noch voll nuten kann, aber eben genau den D0 nicht -.- Könnte ich es dann theoretisch nur über einen Zwischenspeicher machen, oder ich steuer die SD-Karte mit SPI an? Was meint Ihr?
habe mein fehler gefunden! Hatte bei den I2C nachrichten ein delay am schluss! Nun komme ich an der While Schleife vorbei und empfange mein erstes byte :) Ich will die Daten erstmal intern zwischenspeichern (auf Flash). Leider wird dabei eine exception geworfen... Ich habe einen Pointer vom typ char* angelegt und diesen auf die Adresse 7D050000 zeigen lassen:
1 | PointerFlash = 0x7D050000; |
Dort sollte sich der Programm Flash befinden. Zuvor habe ich mit
1 | BMXPUPBA = 0x50000; |
192 KByte (0x80000 - 0x30000 = 0x50000) Flash als user mode reserviert. Das Auslesen sieht dann wie folgt aus:
1 | tmpDat = mPORTERead(); |
2 | *PointerFlash = tmpDat; |
3 | PointerFlash++; |
In der Simulation hat er mir es an die entsprechende Speicherstelle reingeschrieben... Bitte um Hilfe :) Gruß Andi
ja ne... das du da eine exception bekommst wundert mich nicht... du kannst auf diese art und weise nicht den flash-speicher beschreiben... lies dir mal dazu im datenblatt Sect. 05 Flash Programming.pdf oder in der plib das entsprechende kapitel durch...
haha, ja das habe ich auch gerade gesehen :-) naja habs jetzt halt auf sd karte geschrieben... also eine line 320pix = 640 byte in RAM (normales char array) gepuffert, dann in eine file auf sd karte und dann die nächste zeile... habe jetzt auch eine datei mit 153600Byte (2*320*240) juhu :D Gibts da jetzt ein tool zum konvertieren oder wie kann ich des jetzt am pc anschauen?! Gruß Andi
hm keine ahnung... ansonsten konvertier das bild in ein 24 bit rgb bild... speicher es als .raw und dann kannst du es in photoshop laden... einfach groesse angeben, kanaele 3 und dann sollte das klappen
Ich habe mich mit Kamera TCM8230 beschäftigt und will meine Erfahrungen erzählen. Am Anfang habe ich probiert die Kamera an AVR32AP7000 anzuschließen, was nicht funktioniert hat weil AVR32 ein Bug hat. Alle umgeschriebene Treiber für Linux habe ich hier in Forum gepostet. Auf AVR32UC3A habe ich auch probiert mit IRQ, wahr einfach zu langsam knapp 1fps Da es braucht schon bis IRQ registriert wird + Bearbeitung. Es gibt AVR32UCxx bei dem gpio 1x1 mit CPU clock läuft aber nicht ausprobiert. Xmega habe ich sofort ausgeschlossen. Bei PIC32 wahr ich auch am überlegen aber dann habe ich STM32F2 entdeckt mit Kamera Interface. Da muss ich sagen hat alles sofort geklappt außer FIFO denn musste ich ausschalten. Mit speichern auf SD Karte als BMP Format hat auch funktioniert, nur mit lesen in 16 bit Version gabs probleme habe dann einfach als 24 bit BMP gespeichert. Bei STM32F2 gibs Cropframe was nur angegebenen Bereich in Speicher transportiert. Was die Sache mit Großen Auflösung viel leichter macht, wenn man das nicht bei Kamera einstellen kann. Hätte STM32F2 oder F4 SDRAM oder DDRRAM interface dann wäre es perfekt. Als Videospeicher SD karte ist zu langsam, SDHC konnte ich nicht nutzen da ich die kleine version von STM32 gekauft habe, und ich weiß nicht ob SDHC von STM32 unterstützt wird. SD Karte würde einfach mit GPIO angesteuert. Als Lösung habe ich dann CompactFlash überlegt aber nicht zum laufen bekommen. Neue Platine gemacht wo ein Kurzschluss gab, und Zwei Leitungen gehen nicht mehr. Erfahrung wenn man GPIO macht kann man bei STM32 als opendrain machen.:))) Bei STM32 hatte ich bedenken das ich den Chip nicht zum laufen bringe, aber auf einseitige Platine hat alles zum meinem Überraschung funktioniert. Jetzt habe ich STM32F4 mit 2mb SRAM und pollin Kamera au-85 aber noch alles als Einzelteile. Wenn ich zum bauen komme poste ich sofort. Wenn Jemand die Programme braucht kann ich posten.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.