Hallo, ich würde gerne eine CMOS Kamera von Omnivision (z.B. OV7635) an einen uC anschließen. Von Atmel gibt es die ARM9 Prozessoren mit der ISI Schnittstelle... Kennt jemand sowas ähnliches von anderen Herstellern. Oder eine Modul, was die Schnittstelle ersetzt, damit ich einen beliebigen uC nehmen kann... LG Yakup
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 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
@Geraffel Verstehe ich das richtig? Der hat den OVSensor direkt an den Atmega angeschlossen?? Ist die ISI Schnittstelle vom SAM9G20 überflüssig???
Yakup schrieb: > @JoergL > Wie genau heißen diese Hardware Encoder? Naja, da mußt Du in Richtung MPEG, (M)JPEG oder H.264 Encoder suchen. Hersteller gibt es viele... > Ich würd mir gern mal einen Datenblatt davon anschauen Das Dumme daran ist, daß die Datenblätter zu den mir bekannten Chips nicht frei erhältlich sind. Stichwort:NDA. Daher ist die Lösung mit einem FPGA und einem freien Encoder Core durchaus reizvoll. Oder einen "kräftigen" Prozessor wie in Strubi's Vorschlag, der das Ganze dann in Software macht. Gruß, Jörg
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?
CMOS Sensoren haben üblicherweise keinen Zwischenspeicher nach der AD-Wandlung, deshalb gibt es keinen Modus mit dem man beliebig langsam ein Bild auslesen kann. Das Bild wird im Pixeltakt (ca 20 - 30Mhz) geliefert. Mit einem kleinen MC schaffst du kein Vollbild mit 640*480*2 Bytes (intern)zu speichern. Bei 1K Ram max. 1 Zeile. Farbsensoren liefern auch keine RGB Werte pro Pixel, sondern musst dir das aus den Bayer Pattern umrechnen. ISI macht das für dich und schiebt dir das Bild via DMA ins (externe) Ram. alternativ : CPLD oder Fpga + Ram.
Yakup schrieb: > @Geraffel > Verstehe ich das richtig? Der hat den OVSensor direkt an den Atmega > angeschlossen?? Ist die ISI Schnittstelle vom SAM9G20 überflüssig??? Der speichert nur 1 Zeile mit 8Bit Auflösung = 640Byte und das passt in 1K Ram.
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
Joerg L. schrieb: > Yakup schrieb: >> @JoergL >> Wie genau heißen diese Hardware Encoder? > > Naja, da mußt Du in Richtung MPEG, (M)JPEG oder H.264 Encoder suchen. > Hersteller gibt es viele... > >> Ich würd mir gern mal einen Datenblatt davon anschauen > > Das Dumme daran ist, daß die Datenblätter zu den mir bekannten Chips > nicht frei erhältlich sind. Stichwort:NDA. > Daher ist die Lösung mit einem FPGA und einem freien Encoder Core > durchaus reizvoll. > Oder einen "kräftigen" Prozessor wie in Strubi's Vorschlag, der das > Ganze dann in Software macht. > > Gruß, > Jörg Da ist nichts gross kodiert;) Die Sensoren sind prinzipiell monochrom. Farbe bekommen die erst wenn man den Pixeln Farbfilter vorschaltet. Die Farbfilter für RGB sind nach einem bestimmten Muster (Bayer Pattern) gleichmässig auf die Fläche der Pixel verteilt. .. das ist alles an Kodierung.
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
Yakup schrieb: > Also kann man mit den YUV Daten und einem rund 400MHZ uC mehr anfangen? Also was will man damit eigentlich anfangen? Du hast bisher reichlich allgemeine Fragen gestellt, aber leider keine Infos rausgelassen, anhand derer man Dir richtungsweisende Antworten geben könnte....
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.
> 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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.