Zitierenwas wäre denn wünschenswert, nur kommunikation mit der cam, oder auch gleich noch beispiele, was man so mit den befehlen machen kann, oder sonst noch?
Bei Jufo wäre die CMUCam wohl nicht das richtige.
Für nicht Wettbewerbe o.k.
Castle
was wäre denn wünschenswert, nur kommunikation mit der cam, oder auch gleich noch beispiele, was man so mit den befehlen machen kann, oder sonst noch?
Linus Torvalds, Entwickler von LinuxIch will Microsoft wirklich nicht zerstören. Das wird nur ein gänzlich unbeabsichtigter Nebeneffekt sein.
....kommunikation mit der cam.
Kein Schnickschnack.
Castle
Hi
Ich wollte mcih eigentlich nicht in diese Diskussion einmischen.
Aber ich arbeite gerade ein einem Jufo-Projekt mit der GBC.
Und du wirst es cniht glauben, aber es geht: Bildauswertung mit dem M8.
Ob dus jetzt glaubst oder nicht... ;D
VLG Tobi
http://www.tobias-schlegel.de
"An AVR can solve (almost) every problem" - ts
Bin noch nicht ganz durch aber schon mal ein paar Vorab Erfahrungen:
Setup:
gamboy-Kamera an ATMega168 mit 18,432MHz Takt, 5V Versorgung.
Die Bilder werden während des Einlesens direkt über UART0 an den Host übertragen und dort mit dem hier schon erwähnten Java Programm angezeigt.
Folgende Dinge sind dabei zu beachten:
Damit der READ Pin auf low geht, dürfen einige Register nicht 0 sein! Ich teste das mal und setze die Werte hier ins Forum. Wichtig ist aber schon mal auf jeden Fall, dass die Belichtungszeit nicht 0 sein sollte. Damit muss entweder im C0 (reg3) oder C1 (reg2) Register ein Wert != 0 stehen.
Damit im Normalmodus (grauwert-positiv-bild) auch etwas erscheint, muss P=1 M=0 und X=1 sein (reg 4, 5, 6). Steht im Datenblatt auf Seite 14.
Jetzt kommt der entscheidende Punkt, damit man bei der direkten Übertragung des Bildes zum Host über die Serielle auch etwas sinnvolles erkennen kann:
Der M64282FP Chip, der in der Gameboy Kamera verbaut ist, hat keinen Shutter (Verschluss). Das heisst, dass während das Bild ausgelesen wird, die CMOS Elemente weiter Licht aufnehmen! Deswegen kommt es auch zu seltsamen Bildern, wenn man die Kamera zu schnell bewegt.
Hier mal eine kurze Berechnung.
XCLK wird optimal, sprich mit 500kHz getaktet. Den ADC squeeze ich ein bisschen, was laut Datenblatt OK ist, da nur 8bit verwendet werden, mit Prescaler 64, auf 288KHz. Eine ADC Wandlung braucht 13 Takte. Macht also als Gesamtzeit für ein Pixel:
13*1/288k+2us = 47.14us/Pixel
Alle Pixel brauchen dann: 128*128*47.14us = 740ms.
Was fehlt? Richtig: Die Übertragung zum Host!
Dadurch wird die Zeit pro Pixel verlängert. Bei 115200bd ist das (8N1+Startbit) = 115200/10 = 11520kB/s =>86.8us/Pixel. Die kommen also zu unserer Kalkulation oben nochmal hinzu.
In Summe landen wir dann bei 2.162 Sekunden/Bild.
Fazit:
Liest man nur das Bild ein, braucht man mit dem ATMega168, bzw. allen Designs, die den internen ADC der AVRs verwenden, 740ms/Bild. Das ist dann auch die Gesamtbelichungszeit für das letzte Pixel (das erste Pixel hat nur die normale Belichungszeit plus irgendwas <47us für's Auslesen). Schreibt man die Daten direkt zum Host wird's nochmal schlimmer. Die Belichtungszeit ist dann so lange, dass die CMOS Elemente ruckzuck in die Sättigung gehen (Weisses bzw. graues Bild).
Deswegen sollte die initiale Belichtungszeit kurz sein, da die Kamera während des auslesens noch genügend Licht aufnimmt.
Hier sind mal meine Parameter: Belichtungszeit ist in us. Offset Voltage in mV (ist aber 0) und Referenzspannung in Volt*2 (damit kein float anfällt). Ist aber auch 0 das Schwarz auf 0V kalibriert werden soll.
Code:void initRetinaParams( void ) { _retinaParams.mode = grey; _retinaParams.enhancement = false; _retinaParams.enhancementRatio = 50; _retinaParams.invertImage = false; _retinaParams.exposureTime = 4500; _retinaParams.offsetVoltage = 0000; _retinaParams.outputVoltageRef2 = 0; _retinaParams.outputGain2 = 104; _retinaParams.boostGainBy6dB = true; }
Das führt bei mir zu folgenden Registerwerten:
0: 0x80
1: 0x10
2: 0x01
3: 0x19
4: 0x01
5: 0x00
6: 0x01
7: 0x00
Ich baue im Momemt noch eine Routine für's Binning (Reduktion der Bildauflösung). Sobald die fertig ist (hoffentlich morgen) kommt der ganze Code hier ins Forum. Das Bild ist dann zwar nur noch 24x24 Pixel groß, dafür wird es aber mit der vollen ADC Rate eingelesen und es ist noch genügend Platz im SRAM des 168 um Bildverarbeitung und diversen anderen Kram zu berechnen.
Für meine Zielapp werde ich eher auf den 162 wechseln, da der ein externes Speicherinterface hat, so das man ein komplettes Bild in maximaler Auflösung halten kann. Ausserdem sollte ein externer ADC ran, der die 500KHz Samplerate bringt.
Angenehmen Abend.
Ingo
BTW: Besteht Interesse am Code in C++ oder machen hier alle C?
Ein externer ADC braucht nicht ran beim AVR , nur bei der C-Control.
Auch wenn man die Cam ganz langsam bewegen tut, kommen Schlieren weil die Cam nicht anders verarbeiten kann.
Ich nehme die Cmucam2, dort wird das Bild nach dem Schnappschuss sofort gespeichert bis Ultimo.
Castle
wie bereits oben geschrieben:
Ich benutze den internen ADC und habe die Taktrate schon über die mögliche Grenze gesetzt. 288kHz statt 200. Um die Kamera aber schnellstmöglich auszulesen, muss man einen externen ADC verwenden.
Hinzu kommt, dass kein AVR genügend SRAM an Bord hat um ein Bild (16384 Pixel) vollständig zu speichern. Deswegen der 162, der kommt mit einem externen Memory Interface (XMEM).
Naja, das ist aber eine komische Aussage. Das ist wie: "Der wagen braucht keine 200 PS der läuft auch mit 50ps von A nach B"Zitat von super_castle
Das wir wirklich sehr gerne die Gameboycamera verwenden möchten, sollte im laufe dieses sehr umfangreichen Threads ebenfalls deutlich geworden sein...
Es gibt einen scheinbar sehr guten AD-Converter bei Reichelt. Und zwar handelt es sich um den ADS 830 E . Der schafft satte 60 Mhz und ist quasi der einzige, den ich finden konnte, der parallel Daten ausgibt! Er ist spezialisiert auf hochlast Aufgaben wie Video digitalisieren. Zumal er nur 5.25 Euro kostet.
Warum steigst du nicht auf den Mega 128 um? Der hat nicht nur ebenfalls das XRAM Interface, sondern auch die aktuelleren und evtl schnelleren Operationen.
Ich verwende C. C++ will mein Compiler nicht compilieren.
BTW: du hast fasst genau die selben Regsitereinstellungen, wie ich. Da wir praktisch die gleiche Tacktrate haben, ist das ein gutes Zeichen dafür, dass wir auf dem richtigen Weg sind
Gruß
Timo
Ich bekomme auch vernünftige Bilder von der Kamera. Aber da die Auslesezeit so hoch ist, muss die Belichtungszeit eben sehr kurz und der Raum einigermassen dunkel sein.
Den 162 verwende ich, weil es den in DIL gibt und ich die Platine erstmal fädeln will.
ADC: Da reich ein Chip der 500kHz schafft. Schneller kann die GameboyKamera die Daten ja nicht liefern. Ich werde einen ADC0804CN verwenden. Der ist schnell genug, liefert die Daten in 8bit und kostet 3.50 bei Reichelt.
Um mit C++ zu arbeiten muss man das Makefile im AVR Studio exportieren, dann im Makefile die Zeile CC=avr-gcc nach CC=avr-g++ ändern und in den Projekteinstellungen das Makefile auswählen. Funktioniert einwandfrei. Einziger - und wie ich finde gravierender - Nachteil: Man kann den Simulator des AVRStudio (noch) nicht mit C++ benutzen. Aber ansonsten schon sehr schick.
BTW, die CMUCam2 ist ja sehr interessant, aber leider 59 mal teurer als die GBKamera. Ich habe für die GBKamera 1 Euro bezahlt (da habe ich dann direkt vier genommen). Abgesehen davon: Der Reiz liegt ja auch darin, die Hardware zu meistern, oder? Ansonsten kann man ja direkt einen Aibo kaufen.
Berechtigungen
Lesezeichen