Omnivision CMOS Kamera an uC

keine eine Ahnung? :(

Yakup schrieb:
> .... damit ich einen beliebigen uC nehmen kann...

Dir ist aber schon bewußt, mit welcher Datenrate die Kamera die Pixel 
liefert?
Also einen beliebigen uC kann man nicht nehmen.
Und ohne passendes Hardware-Interface am uC würde ich das nicht 
probieren.

Gruß,
Jörg

Ich will damit keine Videos abspielen oder sonst was, sondern immer nur 
ein Bild... Da ist die Datenrate dann nicht so extrem hoch oder nicht?

Und was für ein uC würdest Du mir denn empfehlen?

Ich möchte wetten, dass man die z.B Pixelclock und weiter signale extern 
vorgeben kann; also vom Mikrocontroller vorgebenen werden kann. Nennt 
sich Slave Operation oder so ähnlich.... also kannst du sehr wohl einen 
beliebigen wählen. Allerdings sind für frameraten mhz erforderlich.

Yakup schrieb:
> Und was für ein uC würdest Du mir denn empfehlen?

Sorry, kann ich keinen empfehlen, ich kenne nur Lösungen mit FPGAs oder 
Hardware-Encodern.
Da die Kamera einen recht flotten Datenstrom liefert, muß man diesen 
zumindest per DMA auffangen. Nur in Software sehe ich keine Chance.

Coder schrieb:
> Ich möchte wetten, dass man die z.B Pixelclock und weiter signale extern
> vorgeben kann;

Jein, die Pixelclock kommt aus der Kamera, man kann aber den Systemtakt 
vorgeben. Der muß aber noch durch die Kamera-PLL durch, so daß es kein 
per Software generierter Takt sein kann, da Anforderungen an den Jitter 
vorhanden sind....

Gruß,
Jörg

@JoergL

Slave Mode Operation.

@JoergL
Wie genau heißen diese Hardware Encoder? Ich würd mir gern mal einen 
Datenblatt davon anschauen

Hi,

Tip: Nimm einen Blackfin. Der ist perfekt zum Bau von Kameras geeignet, 
bringt auch die nötige Power für Software-JPEG-Encoding mit.
Fertige Referenzdesigns zum Einzug von Bildern gibts in folgenden 
Varianten:

- uClinux v4l : http://blackfin.uclinux.org
- Komplettes v4l2 Kamera-Framework: http://section5.ch/vkit
- Standalone-Shell (kein Betriebssystem): 
http://www.section5.ch/forum/viewtopic.php?f=2&t=118

Wenn du die Bilder anschliessend auch verschicken willst, macht die 
uClinux-Lösung mehr Sinn, zum Prototypen und Verstehen der Hardware ist 
allerdings die Standalone-Shell besser geeignet.

Gruss,

- Strubi

@ Strubi
Danke für die Tipps... Die bringen mich schon einen Schritt weiter...
Im besten Fall würde ich aber durch einen "Hardware Encoder" das System 
so gestalten wollen, dass ich auch uC ohne spezieller Schnittstelle 
benutzten kann...

Hi, Yakup,

ich habe mal einen Bewegungsdetektor gesehen mit einem Z80, einem 
A/D-Wandler und wohl einem Dual-Port-RAM zwischen A/D-Wandler und Z80.

Der uP las aber pro Bild nur eine Zeile aus.

Der AVR ist viel schneller - aber richtige Bildspeicherung oder gar 
Verarbeitung, dafür sind die 8-bitter viel zu klein.

Ciao
Wolfgang Horn

Sollte schon mind. 16bit sein :)

http://www.jrobot.net/Projects/AVRcam.html

@Geraffel
Verstehe ich das richtig? Der hat den OVSensor direkt an den Atmega 
angeschlossen?? Ist die ISI Schnittstelle vom SAM9G20 überflüssig???

Das mit dem "kärftigen Porzessor" wenn man jetzt normale I/O's nimmt, 
muss das ganze über die Software laufen... Verstehe ich das richtig?

Ok, das verstehe ich... Danke für die Erklärung :)
Noch eine andere Frage: Was wenn der uC die Daten nicht intern 
speichert, sondern direkt in den externen Ram. Oder geht das nicht?

> Was wenn der uC die Daten nicht intern
> speichert, sondern direkt in den externen Ram. Oder geht das nicht?

s. Blackfin

Nur ne Anmerkung: der OV7735 spuckt die Daten im UYVY-Format aus (man 
behafte mich nicht auf die genaue Reihenfolge). D.h. da ist bereits ein 
kleiner 'dummer' DSP eingebaut, der das Bayer-Pattern in YUV 4:2:2 
umrechnet, damit spart man sich schon mal was an Zyklen.
Bei der Surveyor SRV1-Robot-Kamera (die man auch einzeln bekommt) ist 
übrigens der fertige JPEG-Encoder zu einem ähnlichen Sensor in 
Opensource vorliegend, der Schaltplan übrigens auch. Viel 
neu/selberzumachen gäb's da also nicht, nun ist die Frage: Ist das Ziel 
der Weg oder die Lösung :-)

Bei HW-Encodern hab ich mir bisher immer die Finger verbrannt. Trotz NDA 
gibt's für den "kleinen Mann" doch immer nur schlechte Infos und die 
Hälfte funktioniert nicht so wie beschrieben. Bisher damit nur Frust 
(von Philips über TI bis ADI...). Dann wäre doch eher noch ein 
vorgeschaltetes FPGA (DCT, usw.) interessant.

Viel Spass,

- Strubi

Also kann man mit den YUV Daten und einem rund 400MHZ uC mehr anfangen? 
oder was genau bedeutet das?

Ich kann leider kein FPGA oder CPLD nehmen, weil meine Aufgabe mir 
vorgibt, alles mit dem uC zu machen... ggf. extra HW-Encoder

Meine Aufgabe in meiner Abschlussarbeit ist folgendes:

Ich soll ein vorhandenes System:
Atmel Sam9g20 uC
CMOS Kamera von OV
LPDDR mit 64MB
so umstellen, dass man die ISI Schnittstelle des Atmel nicht mehr 
benötigt wird, damit man ggf. andere Prozessoren einsetzten kann, die 
nicht über diese Schnittstelle verfügen...

Ich hoffe, dass die Info jetzt reicht, mehr kann ich auch nicht sagen :)

Also soweit ich mich erinnere, kann die Pixel-Clock bei Sensor extern 
vorgegeben werden (MCLK in slave mode). Also sollte das Teil so langsam 
arbeiten wie der Mircokontroller. Würde z.b einen Xmega nehmen oder 
besser einen avr32. Für die ARM Fans auch m0 oder m3. Je mehr mhz desto 
besser. Dann das ganze geschickt mit usb 2.0 high speed im fifo modus 
verheiraten.

ok hätte ich bloss das letzte post gelsen...

> so umstellen, dass man die ISI Schnittstelle des Atmel nicht
> mehr benötigt wird, damit man ggf. andere Prozessoren einsetzten
> kann, die nicht über diese Schnittstelle verfügen...



Nennt sich USB Webcam ;-)

1

> so umstellen, dass man die ISI Schnittstelle des Atmel nicht

2

> mehr benötigt wird, damit man ggf. andere Prozessoren einsetzten

3

> kann, die nicht über diese Schnittstelle verfügen...

4

5

6

7

Nennt sich USB Webcam ;-)

Haha.... entweder bekomme ich damit ne 1.0 oder ne 5.0 :D

Die Aufgabenstellung klingt nach "Wir haben eigentlich keine Ahnung was 
wir da machen wollen aber irgendwas mit Kameras basteln".

Also ist die USB Webcam wahrscheinlich gar nicht so verkehrt...