STM32F4Discovery – Kamera über die DCMI-Schnittstelle anschließen. Sicherheitsinformationsportal Stm32-Kamera vom Mobiltelefon

• Anleitung

STM32F4Discovery – Kamera über DCMI-Schnittstelle anschließen

Es war einmal, als man eine Kamera von einem Mobiltelefon mit einem Mikrocontroller verband STM32F407VGT6(was auf der Tafel stattfindet STM32F4Discovery), habe ich gar nicht darüber nachgedacht, dass dieser Controller in diesem Zusammenhang über eine spezielle Hardware-Schnittstelle verfügt. Vielleicht habe ich das Datenblatt nicht sorgfältig gelesen, aber ich dachte immer, dass die Schnittstelle DCMI Nur für Chips in Paketen verfügbar UFBGA176 Und LQFP aus 144 Fuß. Vor nicht allzu langer Zeit entdeckte ich jedoch das stimmhafte Detail: 100 Beine STM32F407 hat auch DCMI an Bord.
Da ich ein großer Fan der Erforschung und gemeinsamen Einführung verschiedener mobiler Hardware (insbesondere LCDs und Kameras) mit MK bin, konnte ich an einer solchen Entdeckung einfach nicht vorbeigehen und beschloss, diese Lücke in der Erforschung von STM32-Peripheriegeräten zu schließen. Eigentlich ist dieses Material einer Beschreibung der Umsetzung der entstandenen Idee gewidmet.

Nur eine kleine Theorie.

Zunächst müssen Sie sich vorstellen, wovon wir sprechen – oder besser gesagt, was eine CMOS-Kamera ist und womit sie verwendet wird.
Dieser Kameratyp gibt Informationen vom Sensor in digitaler Form aus: RGB, YCbCr und auch in komprimierter Form – JPEG. Verschiedene Kameras haben ihre eigenen Nuancen in Bezug auf die Fähigkeiten. Ich werde einen ganz speziellen Fall einer Kamera mit niedriger Auflösung (VGA, 640 x 480) betrachten, die ich in der Antike aus meinem Telefon herausgeholt habe. Siemens C72"(Sensor PixelPlus PO2030N). Diese Kamera ist aufgrund ihrer einfachen Bedienung und ihrer Zugehörigkeit zu einem mehr oder weniger verbreiteten Typ für Studienzwecke am besten geeignet. Vor langer Zeit habe ich dafür eine kleine Platine gebaut (um den Anschluss zu erleichtern) – mit einem 2,8-V-Stabilisator und Pull-up-Widerständen am Bus I2C. Hier ist es (das Kamerakabel und der Stecker sind unter dem Gehäuse versteckt).

Neben Nuancen im Bereich des Datenformats können sich Kameras auch in der Anzahl der Synchronisationspins unterscheiden. Die meisten (meiner Meinung nach) Sensoren verfügen über spezielle horizontale und vertikale Synchronisationsstifte; Es gibt jedoch Kameras, die nur über einen Pixel-Strobe-Ausgang verfügen und Sie mithilfe spezieller übertragener Codes (z. B. 0x00 oder 0xFF). Die Kamera, die ich habe, verfügt über externe Synchronisierungspins.
Sie können eine ungefähre schematische Darstellung der Kamera in Form eines Blocks schätzen.

CMOS-Kameras werden größtenteils über eine Schnittstelle gesteuert I2C(obwohl ich Geräte gesehen habe, die von gesteuert werden UART). Über I2C werden verschiedene Parameter konfiguriert, wie zum Beispiel: Auflösung, Farbraum, Ausgabedatenformat usw.
Abschluss EXTCLK– Kamerataktung, die extern bereitgestellt werden muss. DCLK– ein Strobe-Signal, an dessen Vorder- oder Hinterkante Daten auf dem Kameradatenbus aufgezeichnet werden (z. B. ein Datenbyte eines Pixels der Matrix oder ein „Halbpixel“-Datenbyte, wenn die Kamera in Betrieb ist). RGB565). HSYNC– horizontales Synchronisationssignal, das den Beginn einer neuen Zeile anzeigt, und VSYNC– ein Synchronisationssignal, dessen aktiver Pegel den Beginn eines neuen Frames anzeigt. Schlussfolgerungen D0..D7– Datenbus; In der Regel handelt es sich bei solchen Kameras um 8-Bit.
Lassen Sie uns nun mehr über Synchronisationssignale sprechen.

Die Grafiken zeigen, dass die Kamera für Signalaktivität konfiguriert ist DCLK nur während der aktiven Phase HSYNC(Diese Phase interessiert uns nämlich; das Taktsignal während der „Line-Feed“-Periode ist für uns nicht interessant). Wenn die Kamera auf eine Auflösung von 320 x 240 eingestellt ist, dann bei jedem Impuls HSYNC 320 Impulse passen DCLK, und während des Zeitraums VSYNC – 240 HSYNC.
Wenn wir hineinzoomen, sehen wir, was auf dem Datenbus passiert.

Bei einer steigenden Flanke (in diesem Fall) wird ein Byte vom Datenbus entfernt, das direkt zur Anzeige an das Display gesendet oder zur anschließenden Verarbeitung in einen Puffer „gefaltet“ werden kann.

Theoretisch ist jetzt alles mehr oder weniger klar, was die Schnittstelle betrifft DCMI Mikrocontroller STM32.

Schnittstelle DCMI ist in der Lage, mit einem bis zu 14 Bit breiten Datenbus zu arbeiten, unterstützt sowohl Hardware- als auch Softwaresynchronisation sowie Datenformate: YCbCr, RGB und JPEG.
Außerdem, DCMI enthält einen Puffer FIFO, hat die Möglichkeit, Interrupts zu konfigurieren (einschließlich beim Füllen des Datenregisters) und den Betrieb über zu konfigurieren DMA.

Unterbrechungen von DCMI kann aufgerufen werden, wenn folgende Bedingungen eintreten: Leitungsende, Rahmenende, Empfangspufferüberlauf, Synchronisationsfehler erkannt (bei interner Synchronisation).
Etwas verwundert war ich über das Fehlen eines speziellen Kamera-Taktausgangs. Ich weiß nicht, warum die Entwickler aus SGS Mikroelektronik Es wurde aufgegeben, aber für mich wäre es zum Beispiel sehr praktisch, eine anpassbare Taktquelle zu haben.
Persönlich habe ich einen im PWM-Modus eingeschalteten Allzweck-Timer-Zähler verwendet, um eine Rechteckwelle mit einer Frequenz von 4 MHz zu erzeugen. Natürlich kann man mit einer solchen Uhr keine hohen FPS erreichen, aber ich mache gleich einen Vorbehalt – das Display, das ich verwende, ist nicht angeschlossen FSMC Daher ist die längste Funktion in der gesamten Kette die LCD-Ausgabefunktion, daher schlägt bei einer höheren Frequenz die Bildausgabe auf dem Bildschirm fehl. Deshalb schalte ich vor dem Entladen den Timer aus und danach wieder ein.
Hardwaremodul DCMI enthält zusätzlich zum Datenregister zehn Steuer-/Statusregister. Dies ist: Kontrollregister ( DCMI_CR), Statusregister ( DCMI_SR), Interrupt-Statusregister ( DCMI_RIS), Interrupt-Freigaberegister ( DCMI_IER), Interrupt-Maskenregister ( DCMI_MIS), Interrupt-Flag-Reset-Register ( DCMI_ICR), internes Taktcoderegister ( DCMI_ESCR), internes Clock-Code-Masken-Reset-Register ( DCMI_ESUR), Register der Startwerte beim Erfassen eines Teils des Frames ( DCMI_CWSTRT) und Frame-Fragment-Größenregister im CropWindow-Modus ( DCMI_CWSIZE). Und natürlich das Datenregister - DCMI_DR.
In diesem Fall sind Register, die sich auf die Erfassung eines Teils des Frames und die interne Synchronisierung beziehen, für uns nicht von Interesse. Ich habe mich auch entschieden, Interrupts vorerst in Ruhe zu lassen, daher lohnt es sich, nur das Steuerregister genauer zu betrachten DCMI_CR und Statusregister DCMI_SR.

Das Steuerregister gibt uns die Möglichkeit, das Format der Interaktion mit der Kamera vollständig anzupassen: Datenbusgröße, aktive Leitungspegel HSYNC Und VSYNC, usw.

In Ordnung. Bisschen AKTIVIEREN– Die Inbetriebnahme der Schnittstelle ist selbstverständlich. Feld EDM (erweiterter Datenmodus) – Datenbusgröße; Meine Kamera verfügt über einen 8-Bit-Bus, daher sollte dieses Feld auf „00“ eingestellt sein. Feld FCRC (Steuerung der Frame-Capture-Rate) ermöglicht eine leichte Anpassung des FPC: 00 – alle eingehenden Bilder werden erfasst, 01 – jedes zweite Bild, 10 – jedes vierte. Bits VSPOL Und HSPOL– aktive Ebenen der vertikalen und horizontalen Synchronisationslinien. Aktive Ebenen werden ignoriert und während aktiver Zeiträume werden keine Daten erfasst. Dies sollte berücksichtigt werden. PCKPOL– Bit des aktiven Pegels des Pixel-Strobe – an welcher Flanke des Signals Daten vom Bus gelesen werden sollen: vorne oder hinten. ESS– Bit zur Auswahl der Synchronisationsmethode: extern oder intern. JPEG– Wahl des eingehenden Datenformats – komprimiert oder nicht. ERNTE– Auswahlbit für die Frame-Fragment-Erfassung ( Zuschneidefenster). Wenn dieses Bit auf Eins gesetzt ist, erfasst die Schnittstelle Daten in einem Fenster, das durch die Werte in den Registern definiert wird DCMI_CWSTRT Und DCMI_CWSIZE.

Also, lasst es uns einrichten.

Da ich es gewohnt bin, die Standard-Peripheriebibliothek von ST zu verwenden (obwohl ich sie in den ersten Iterationen der Arbeit mit neuen Peripheriegeräten nie verwende, bis ich manuell an den Registern herumbastele), habe ich die Einstellungen mithilfe der Bibliothek vorgenommen.

Void DCMIInitialRoutine(void) ( DCMI_InitTypeDef DCMI_CamType; DCMI_DeInit(); DCMI_CamType.DCMI_CaptureMode = DCMI_CaptureMode_Continuous; DCMI_CamType.DCMI_CaptureRate = DCMI_CaptureRate_All_Frame; DCMI_CamType.DCMI_ExtendedDataMode = DCMI_ExtendedData Mode_8b; DCMI_CamType.DCMI_Synch roMode = DCMI_SynchroMode_Hardware; DCMI_CamType(ENABLE);
Tatsächlich war es für meine Zwecke möglich, kein einziges Bit im Register zu berühren DCMI_CR– Standardmäßig sind sie zurückgesetzt – mit Ausnahme der Bits ERFASSEN Und AKTIVIEREN.
Die Schnittstelle ist konfiguriert und einsatzbereit. Nachdem ein Taktsignal an die Kamera gesendet wurde, beginnt die Schnittstelle, die Daten zu empfangen, die wir verarbeiten müssen.
Zunächst habe ich mir die einfachste Aufgabe gestellt – das Bild auf dem Display anzuzeigen, damit die Datenverarbeitung minimal ist.
Das Statusregister hilft uns beim rechtzeitigen Lesen von Daten aus dem Empfangspuffer DCMI_SR.

Zum Lesen stehen nur sehr wenige Bits zur Verfügung – nur drei. Bits HSYNC Und VSYNC signalisieren den Zustand der entsprechenden Leitungen: aktive Phase oder Leitungseinspeisung; Das Interessanteste ist das Gebiss FNE. Es sagt uns, dass wir den Puffer mit Daten füllen sollen. Oder weil Sie es nicht ausgefüllt haben.
Überprüfen des Status des Bits in einer vorgefertigten Schleife FNE V DCMI_SR, erfahren wir über die Ankunft von Daten im empfangenden 32-Bit-Puffer. In meinem Fall werden die Daten so lokalisiert:

Beim Setzen des Bits FNE im Statusregister DCMI_SR Der Empfangspuffer enthält vier Bytes, Daten von zwei benachbarten Pixeln: Byte0 Und Byte1 – 16 Pixelbits N, A Byte2 Und Byte3 – 16 Pixelbits n+1. Ich muss sie nur noch kombinieren und an die Anzeige senden. So sieht die Hauptschleife aus:
while (1) ( while ((DCMI_GetFlagStatus(DCMI_FLAG_FNE)) == RESET); //Warten auf den Puffer TIM_Cmd(TIM3, DISABLE); //CAM-Uhr deaktivieren cam_grab = (DCMI->DR); //Puffer lesen SendDataByte_LCD (cam_grab); cam_grab = (DCMI->DR)>>16; //2. Teil des Puffers lesen SendDataByte_LCD (cam_grab);
Das heißt, ich warte darauf, dass das Bit gesetzt wird FNE im Statusregister DCMI_SR, und dann lade ich in zwei Schritten 16 Bit Daten auf das Display hoch.
An dieser Stelle würde ich gerne zu einer logischen Schlussfolgerung kommen, aber dazu sollte es nicht kommen.
Nachdem ich die Firmware geflasht und den MK neu gestartet hatte, sah ich auf dem Display... nein, ich sah meine eigene, sehr vertraute Physik, aber in Schwarz- und Blautönen. Rote und grüne Farben fehlten völlig.
Nach einem kurzen Showdown mit dem Debugger wurde Folgendes entdeckt: Das Schnittstellendatenregister enthielt nur 16 Datenbits pro Pixel, wobei die unteren 8 Bits an Ort und Stelle lagen Byte0 (siehe Abbildung oben), und die Ältesten sind an Ort und Stelle Byte2 . Räume Byte1 Und Byte3 sie waren leer. Bisher habe ich nicht verstanden, woher diese Diskrepanz zwischen Dokumentation und Realität kommt, und vielleicht werde ich mich an STM wenden.
Dadurch ist es uns gelungen, über die Schnittstelle ein Bild von der Kamera abzurufen DCMI, wenn auch nicht ohne einige Schwierigkeiten. In der Abbildung zeige ich ein Foto des Displays, auf dem das Bild des Demoboards angezeigt wurde STM32F3Discovery von meiner Kamera.

Folgendes werden wir in den Schlussfolgerungen sehen: EXTCLK, PIXCK, HSYNC Und VSYNC, wenn Sie einen Logikanalysator anschließen.

Alles sieht genau wie erwartet aus: 240 Impulse HSYNC passt in die Dauer von einem VSYNC, 320 PIXCK- in einem HSYNC. Während der aktiven Phase HSYNC Die Kamera erzeugt keine Signale PIXCK– genau so, wie sie eingerichtet wurde.
Generell hat mich die Benutzeroberfläche etwas enttäuscht. Das Fehlen eines „Standard“-Kamera-Taktgebers, das Fehlen mehr oder weniger interessanter integrierter Funktionen (wie wäre es mit einem Hardware-JPEG-Encoder?) und sogar das Tanzen mit einem Tamburin um ein halbgebackenes Produkt FIFO…
Organisation der Kameraarbeit bei Unterbrechungen PIXCK, HSYNC Und VSYNC Ich hatte nicht so große Probleme wie bei der Arbeit mit der Kamera mit Hardware DCMI.
In naher Zukunft werde ich jedoch versuchen, ein Bild aufzunehmen und zu komprimieren JPEG, und versuchen Sie, ein Bild auf die SD-Karte zu schreiben.
PS. Für alle Fälle gebe ich einen Link zum Projekt für „ Code::Blöcke„- plötzlich wird es für jemanden nützlich sein.

Die Anbindung der Karte erfolgt über zwei Funktionen:
1. Nutzung der Funktion disk_initialize Die Karte wird initialisiert.
2. Als nächstes müssen Sie es montieren f_mount.

Nachdem Sie diese Schritte erfolgreich abgeschlossen haben, können Sie verschiedene Vorgänge mit der Karte durchführen, wie zum Beispiel:
1. f_open– Öffnen einer Datei,
2. f_close– Schließen der Datei;
3. f_mkdir– Erstellen eines Verzeichnisses;
4. f_chdir– Verzeichnisauswahl;
5. f_write– Schreiben in eine Datei;
6. f_read– Lesen aus der Datei.

Ich habe beschrieben, wie man mit der Kamera und der SD-Karte arbeitet. Schauen wir uns nun an, wie das Programm als Ganzes funktioniert:
1. Initialisieren Sie die SD-Karte.
2. Initialisieren Sie das Kameramodul.
3. Öffnen Sie die Datei time.txt (die Datei sollte eine Zeile des Formats enthalten). 01.01.2014_12:00 ), das die Zeit zum Zählen des RTC-Timers speichert;
4. Lesen Sie Uhrzeit und Datum aus der Datei ab und richten Sie die RTC ein.
5. Schließen Sie die Datei time.txt;
6. Erstellen Sie ein Verzeichnis zum Speichern von Fotos „LinkSpritePhoto“;
7. Wenn Sie die PA0-Taste auf der Platine drücken, machen Sie ein Foto und speichern es auf der Karte (Während das Foto aufgenommen wird, leuchtet die blaue LED);
8. Wenn eine der Funktionen nicht ausgeführt wird, geraten wir in eine Endlosschleife und blinken die grüne LED.

Um die Kamera im Dauermodus zu betreiben, müssen Sie die folgenden Zeilen in main.c auskommentieren:

//EnabledButtonStart = 101; // Um ​​in einer Schleife zu laufen, entkommentieren Sie diese Zeile //Delay(300); // Verzögerung beim Start in der Schleife
Und kommentieren Sie diese Zeile aus:

EnabledButtonStart = 0; // Um ​​in einer Schleife auszuführen, kommentieren Sie diese Zeile aus
Wenn Sie es dann einschalten, beginnt die Kamera, kontinuierlich Fotos aufzunehmen.

Im Allgemeinen habe ich eine Beschreibung der Funktionsweise dieser Kamera zusammengestellt und kann nun das Ergebnis der Arbeit zeigen.

Es war einmal, als man eine Kamera von einem Mobiltelefon mit einem Mikrocontroller verband STM32F407VGT6(was auf der Tafel stattfindet STM32F4Discovery), habe ich gar nicht darüber nachgedacht, dass dieser Controller in diesem Zusammenhang über eine spezielle Hardware-Schnittstelle verfügt. Vielleicht habe ich das Datenblatt nicht sorgfältig gelesen, aber ich dachte immer, dass die Schnittstelle DCMI Nur für Chips in Paketen verfügbar UFBGA176 Und LQFP aus 144 Fuß. Vor nicht allzu langer Zeit entdeckte ich jedoch das stimmhafte Detail: 100 Beine STM32F407 hat auch DCMI an Bord.
Da ich ein großer Fan der Erforschung und gemeinsamen Einführung verschiedener mobiler Hardware (insbesondere LCDs und Kameras) mit MK bin, konnte ich an einer solchen Entdeckung einfach nicht vorbeigehen und beschloss, diese Lücke in der Erforschung von STM32-Peripheriegeräten zu schließen. Eigentlich ist dieses Material einer Beschreibung der Umsetzung der entstandenen Idee gewidmet.

Nur eine kleine Theorie.

Zunächst müssen Sie sich vorstellen, wovon wir sprechen – oder besser gesagt, was eine CMOS-Kamera ist und womit sie verwendet wird.
Dieser Kameratyp gibt Informationen vom Sensor in digitaler Form aus: RGB, YCbCr und auch in komprimierter Form – JPEG. Verschiedene Kameras haben ihre eigenen Nuancen in Bezug auf die Fähigkeiten. Ich werde einen ganz speziellen Fall einer Kamera mit niedriger Auflösung (VGA, 640 x 480) betrachten, die ich in der Antike aus meinem Telefon herausgeholt habe. Siemens C72"(Sensor PixelPlus PO2030N). Diese Kamera ist aufgrund ihrer einfachen Bedienung und ihrer Zugehörigkeit zu einem mehr oder weniger verbreiteten Typ für Studienzwecke am besten geeignet. Vor langer Zeit habe ich dafür eine kleine Platine gebaut (um den Anschluss zu erleichtern) – mit einem 2,8-V-Stabilisator und Pull-up-Widerständen am Bus I2C. Hier ist es (das Kamerakabel und der Stecker sind unter dem Gehäuse versteckt).

Neben Nuancen im Bereich des Datenformats können sich Kameras auch in der Anzahl der Synchronisationspins unterscheiden. Die meisten (meiner Meinung nach) Sensoren verfügen über spezielle horizontale und vertikale Synchronisationsstifte; Es gibt jedoch Kameras, die nur über einen Pixel-Strobe-Ausgang verfügen und Sie mithilfe spezieller übertragener Codes (z. B. 0x00 oder 0xFF). Die Kamera, die ich habe, verfügt über externe Synchronisierungspins.
Sie können eine ungefähre schematische Darstellung der Kamera in Form eines Blocks schätzen.

CMOS-Kameras werden größtenteils über eine Schnittstelle gesteuert I2C(obwohl ich Geräte gesehen habe, die von gesteuert werden UART). Über I2C werden verschiedene Parameter konfiguriert, wie zum Beispiel: Auflösung, Farbraum, Ausgabedatenformat usw.
Abschluss EXTCLK– Kamerataktung, die extern bereitgestellt werden muss. DCLK– ein Strobe-Signal, an dessen Vorder- oder Hinterkante Daten auf dem Kameradatenbus aufgezeichnet werden (z. B. ein Datenbyte eines Pixels der Matrix oder ein „Halbpixel“-Datenbyte, wenn die Kamera in Betrieb ist). RGB565). HSYNC– horizontales Synchronisationssignal, das den Beginn einer neuen Zeile anzeigt, und VSYNC– ein Synchronisationssignal, dessen aktiver Pegel den Beginn eines neuen Frames anzeigt. Schlussfolgerungen D0..D7– Datenbus; In der Regel handelt es sich bei solchen Kameras um 8-Bit.
Lassen Sie uns nun mehr über Synchronisationssignale sprechen.

Die Grafiken zeigen, dass die Kamera für Signalaktivität konfiguriert ist DCLK nur während der aktiven Phase HSYNC(Diese Phase interessiert uns nämlich; das Taktsignal während der „Line-Feed“-Periode ist für uns nicht interessant). Wenn die Kamera auf eine Auflösung von 320 x 240 eingestellt ist, dann bei jedem Impuls HSYNC 320 Impulse passen DCLK, und während des Zeitraums VSYNC – 240 HSYNC.
Wenn wir hineinzoomen, sehen wir, was auf dem Datenbus passiert.

Bei einer steigenden Flanke (in diesem Fall) wird ein Byte vom Datenbus entfernt, das direkt zur Anzeige an das Display gesendet oder zur anschließenden Verarbeitung in einen Puffer „gefaltet“ werden kann.
Theoretisch ist jetzt alles mehr oder weniger klar, was die Schnittstelle betrifft DCMI Mikrocontroller STM32.
Schnittstelle DCMI ist in der Lage, mit einem bis zu 14 Bit breiten Datenbus zu arbeiten, unterstützt sowohl Hardware- als auch Softwaresynchronisation sowie Datenformate: YCbCr, RGB und JPEG.
Außerdem, DCMI enthält einen Puffer FIFO, hat die Möglichkeit, Interrupts zu konfigurieren (einschließlich beim Füllen des Datenregisters) und den Betrieb über zu konfigurieren DMA.

Unterbrechungen von DCMI kann aufgerufen werden, wenn folgende Bedingungen eintreten: Leitungsende, Rahmenende, Empfangspufferüberlauf, Synchronisationsfehler erkannt (bei interner Synchronisation).
Etwas verwundert war ich über das Fehlen eines speziellen Kamera-Taktausgangs. Ich weiß nicht, warum die Entwickler aus SGS Mikroelektronik Es wurde aufgegeben, aber für mich wäre es zum Beispiel sehr praktisch, eine anpassbare Taktquelle zu haben.
Persönlich habe ich einen im PWM-Modus eingeschalteten Allzweck-Timer-Zähler verwendet, um eine Rechteckwelle mit einer Frequenz von 4 MHz zu erzeugen. Natürlich kann man mit einer solchen Uhr keine hohen FPS erreichen, aber ich mache gleich einen Vorbehalt – das Display, das ich verwende, ist nicht angeschlossen FSMC Daher ist die längste Funktion in der gesamten Kette die LCD-Ausgabefunktion, daher schlägt bei einer höheren Frequenz die Bildausgabe auf dem Bildschirm fehl. Deshalb schalte ich vor dem Entladen den Timer aus und danach wieder ein.
Hardwaremodul DCMI enthält zusätzlich zum Datenregister zehn Steuer-/Statusregister. Dies ist: Kontrollregister ( DCMI_CR), Statusregister ( DCMI_SR), Interrupt-Statusregister ( DCMI_RIS), Interrupt-Freigaberegister ( DCMI_IER), Interrupt-Maskenregister ( DCMI_MIS), Interrupt-Flag-Reset-Register ( DCMI_ICR), internes Taktcoderegister ( DCMI_ESCR), internes Clock-Code-Masken-Reset-Register ( DCMI_ESUR), Register der Startwerte beim Erfassen eines Teils des Frames ( DCMI_CWSTRT) und Frame-Fragment-Größenregister im CropWindow-Modus ( DCMI_CWSIZE). Und natürlich das Datenregister - DCMI_DR.
In diesem Fall sind Register, die sich auf die Erfassung eines Teils des Frames und die interne Synchronisierung beziehen, für uns nicht von Interesse. Ich habe mich auch entschieden, Interrupts vorerst in Ruhe zu lassen, daher lohnt es sich, nur das Steuerregister genauer zu betrachten DCMI_CR und Statusregister DCMI_SR.

Das Steuerregister gibt uns die Möglichkeit, das Format der Interaktion mit der Kamera vollständig anzupassen: Datenbusgröße, aktive Leitungspegel HSYNC Und VSYNC, usw.

In Ordnung. Bisschen AKTIVIEREN– Die Inbetriebnahme der Schnittstelle ist selbstverständlich. Feld EDM (erweiterter Datenmodus) – Datenbusgröße; Meine Kamera verfügt über einen 8-Bit-Bus, daher sollte dieses Feld auf „00“ eingestellt sein. Feld FCRC (Steuerung der Frame-Capture-Rate) ermöglicht eine leichte Anpassung des FPC: 00 – alle eingehenden Bilder werden erfasst, 01 – jedes zweite Bild, 10 – jedes vierte. Bits VSPOL Und HSPOL– aktive Ebenen der vertikalen und horizontalen Synchronisationslinien. Aktive Ebenen werden ignoriert und während aktiver Zeiträume werden keine Daten erfasst. Dies sollte berücksichtigt werden. PCKPOL– Bit des aktiven Pegels des Pixel-Strobe – an welcher Flanke des Signals Daten vom Bus gelesen werden sollen: vorne oder hinten. ESS– Bit zur Auswahl der Synchronisationsmethode: extern oder intern. JPEG– Wahl des eingehenden Datenformats – komprimiert oder nicht. ERNTE– Auswahlbit für die Frame-Fragment-Erfassung ( Zuschneidefenster). Wenn dieses Bit auf Eins gesetzt ist, erfasst die Schnittstelle Daten in einem Fenster, das durch die Werte in den Registern definiert wird DCMI_CWSTRT Und DCMI_CWSIZE.
Also, lasst es uns einrichten. Da ich es gewohnt bin, die Standard-Peripheriebibliothek von ST zu verwenden (obwohl ich sie in den ersten Iterationen der Arbeit mit neuen Peripheriegeräten nie verwende, bis ich manuell an den Registern herumbastele), habe ich die Einstellungen mithilfe der Bibliothek vorgenommen.

Void DCMIInitialRoutine(void) ( DCMI_InitTypeDef DCMI_CamType; DCMI_DeInit(); DCMI_CamType.DCMI_CaptureMode = DCMI_CaptureMode_Continuous; DCMI_CamType.DCMI_CaptureRate = DCMI_CaptureRate_All_Frame; DCMI_CamType.DCMI_ExtendedDataMode = DCMI_ExtendedData Mode_8b; DCMI_CamType.DCMI_Synch roMode = DCMI_SynchroMode_Hardware; DCMI_CamType(ENABLE);

Tatsächlich war es für meine Zwecke möglich, kein einziges Bit im Register zu berühren DCMI_CR– Standardmäßig sind sie zurückgesetzt – mit Ausnahme der Bits ERFASSEN Und AKTIVIEREN.
Die Schnittstelle ist konfiguriert und einsatzbereit. Nachdem ein Taktsignal an die Kamera gesendet wurde, beginnt die Schnittstelle, die Daten zu empfangen, die wir verarbeiten müssen.
Zunächst habe ich mir die einfachste Aufgabe gestellt – das Bild auf dem Display anzuzeigen, damit die Datenverarbeitung minimal ist.
Das Statusregister hilft uns beim rechtzeitigen Lesen von Daten aus dem Empfangspuffer DCMI_SR.

Zum Lesen stehen nur sehr wenige Bits zur Verfügung – nur drei. Bits HSYNC Und VSYNC signalisieren den Zustand der entsprechenden Leitungen: aktive Phase oder Leitungseinspeisung; Das Interessanteste ist das Gebiss FNE. Es sagt uns, dass wir den Puffer mit Daten füllen sollen. Oder weil Sie es nicht ausgefüllt haben.
Überprüfen des Status des Bits in einer vorgefertigten Schleife FNE V DCMI_SR, erfahren wir über die Ankunft von Daten im empfangenden 32-Bit-Puffer. In meinem Fall werden die Daten so lokalisiert:

Beim Setzen des Bits FNE im Statusregister DCMI_SR Der Empfangspuffer enthält vier Bytes, Daten von zwei benachbarten Pixeln: Byte0 Und Byte1 – 16 Pixelbits N, A Byte2 Und Byte3 – 16 Pixelbits n+1. Ich muss sie nur noch kombinieren und an die Anzeige senden. So sieht die Hauptschleife aus:

While (1) ( while ((DCMI_GetFlagStatus(DCMI_FLAG_FNE)) == RESET); //Warten auf den Puffer TIM_Cmd(TIM3, DISABLE); //CAM-Uhr deaktivieren cam_grab = (DCMI->DR); //Puffer lesen SendDataByte_LCD (cam_grab); cam_grab = (DCMI->DR)>>16; //2. Teil des Puffers lesen SendDataByte_LCD (cam_grab)

Das heißt, ich warte darauf, dass das Bit gesetzt wird FNE im Statusregister DCMI_SR, und dann lade ich in zwei Schritten 16 Bit Daten auf das Display hoch.
An dieser Stelle würde ich gerne zu einer logischen Schlussfolgerung kommen, aber dazu sollte es nicht kommen.
Nachdem ich die Firmware geflasht und den MK neu gestartet hatte, sah ich auf dem Display... nein, ich sah meine eigene, sehr vertraute Physik, aber in Schwarz- und Blautönen. Rote und grüne Farben fehlten völlig.
Nach einem kurzen Showdown mit dem Debugger wurde Folgendes entdeckt: Das Schnittstellendatenregister enthielt nur 16 Datenbits pro Pixel, wobei die unteren 8 Bits an Ort und Stelle lagen Byte0 (siehe Abbildung oben), und die Ältesten sind an Ort und Stelle Byte2 . Räume Byte1 Und Byte3 sie waren leer. Bisher habe ich nicht verstanden, woher diese Diskrepanz zwischen Dokumentation und Realität kommt, und vielleicht werde ich mich an STM wenden.
Dadurch ist es uns gelungen, über die Schnittstelle ein Bild von der Kamera abzurufen DCMI, wenn auch nicht ohne einige Schwierigkeiten. In der Abbildung zeige ich ein Foto des Displays, auf dem das Bild des Demoboards angezeigt wurde STM32F3Discovery von meiner Kamera.

Folgendes werden wir in den Schlussfolgerungen sehen: EXTCLK, PIXCK, HSYNC Und VSYNC, wenn Sie einen Logikanalysator anschließen.

Alles sieht genau wie erwartet aus: 240 Impulse HSYNC passt in die Dauer von einem VSYNC, 320 PIXCK- in einem HSYNC. Während der aktiven Phase HSYNC Die Kamera erzeugt keine Signale PIXCK– genau so, wie sie eingerichtet wurde.
Generell hat mich die Benutzeroberfläche etwas enttäuscht. Das Fehlen eines „Standard“-Kamera-Taktgebers, das Fehlen mehr oder weniger interessanter integrierter Funktionen (wie wäre es mit einem Hardware-JPEG-Encoder?) und sogar das Tanzen mit einem Tamburin um ein halbgebackenes Produkt FIFO…
Organisation der Kameraarbeit bei Unterbrechungen PIXCK, HSYNC Und VSYNC Ich hatte nicht so große Probleme wie bei der Arbeit mit der Kamera mit Hardware DCMI.
In naher Zukunft werde ich jedoch versuchen, ein Bild aufzunehmen und zu komprimieren JPEG, und versuchen Sie, ein Bild auf die SD-Karte zu schreiben.
PS. Für alle Fälle gebe ich einen Link zum Projekt für „ Code::Blöcke„- plötzlich wird es für jemanden nützlich sein.

Unter Zeitlupenfilmen versteht man das Filmen mit einer Frequenz, die unter der Standardaufnahme- und Projektionsfrequenz von 24 Bildern pro Sekunde liegt.

Nachdem ich begonnen hatte, STM32-Mikrocontroller zu studieren und „HelloWorld“ mit blinkender LED zu schreiben, wurde mir klar, dass ich etwas Komplexeres mit mehr Mikrocontroller-Peripheriegeräten implementieren musste, um die Funktionsweise des STM32 besser zu verstehen. So entstand die Idee, eine Zeitrafferkamera zu entwickeln.

Die von mir entwickelte Kamera nimmt etwa alle 5 Sekunden Fotos auf und speichert sie im JPEG-Format auf der SD-Karte. Anschließend müssen sie am Computer zu einer Videodatei zusammengefügt werden.

Um die Kamera zu erstellen, habe ich die folgenden Komponenten verwendet:

Die Anbindung der Karte erfolgt über zwei Funktionen:
1. Nutzung der Funktion disk_initialize Die Karte wird initialisiert.
2. Als nächstes müssen Sie es montieren f_mount.

Nachdem Sie diese Schritte erfolgreich abgeschlossen haben, können Sie verschiedene Vorgänge mit der Karte durchführen, wie zum Beispiel:
1. f_open– Öffnen einer Datei,
2. f_close– Schließen der Datei;
3. f_mkdir– Erstellen eines Verzeichnisses;
4. f_chdir– Verzeichnisauswahl;
5. f_write– Schreiben in eine Datei;
6. f_read– Lesen aus der Datei.

Ich habe beschrieben, wie man mit der Kamera und der SD-Karte arbeitet. Schauen wir uns nun an, wie das Programm als Ganzes funktioniert:
1. Initialisieren Sie die SD-Karte.
2. Initialisieren Sie das Kameramodul.
3. Öffnen Sie die Datei time.txt (die Datei sollte eine Zeile des Formats enthalten). 01.01.2014_12:00 ), das die Zeit zum Zählen des RTC-Timers speichert;
4. Lesen Sie Uhrzeit und Datum aus der Datei ab und richten Sie die Echtzeituhr ein.
5. Schließen Sie die Datei time.txt;
6. Erstellen Sie ein Verzeichnis zum Speichern von Fotos „LinkSpritePhoto“;
7. Wenn Sie die PA0-Taste auf der Platine drücken, machen Sie ein Foto und speichern es auf der Karte (Während das Foto aufgenommen wird, leuchtet die blaue LED);
8. Wenn eine der Funktionen nicht ausgeführt wird, geraten wir in eine Endlosschleife und blinken die grüne LED.

Um die Kamera im Dauermodus zu betreiben, müssen Sie die folgenden Zeilen in main.c auskommentieren:

//EnabledButtonStart = 101; // Um ​​in einer Schleife zu laufen, entkommentieren Sie diese Zeile //Delay(300); // Verzögerung beim Start in der Schleife
Und kommentieren Sie diese Zeile aus:

EnabledButtonStart = 0; // Um ​​in einer Schleife auszuführen, kommentieren Sie diese Zeile aus
Wenn Sie es dann einschalten, beginnt die Kamera, kontinuierlich Fotos aufzunehmen.

Im Allgemeinen habe ich eine Beschreibung der Funktionsweise dieser Kamera zusammengestellt und kann nun das Ergebnis der Arbeit zeigen.

• Anleitung

STM32F4Discovery – Kamera über DCMI-Schnittstelle anschließen

Es war einmal, als man eine Kamera von einem Mobiltelefon mit einem Mikrocontroller verband STM32F407VGT6(was auf der Tafel stattfindet STM32F4Discovery), habe ich gar nicht darüber nachgedacht, dass dieser Controller in diesem Zusammenhang über eine spezielle Hardware-Schnittstelle verfügt. Vielleicht habe ich das Datenblatt nicht sorgfältig gelesen, aber ich dachte immer, dass die Schnittstelle DCMI Nur für Chips in Paketen verfügbar UFBGA176 Und LQFP aus 144 Fuß. Vor nicht allzu langer Zeit entdeckte ich jedoch das stimmhafte Detail: 100 Beine STM32F407 hat auch DCMI an Bord.
Da ich ein großer Fan der Erforschung und gemeinsamen Einführung verschiedener mobiler Hardware (insbesondere LCDs und Kameras) mit MK bin, konnte ich an einer solchen Entdeckung einfach nicht vorbeigehen und beschloss, diese Lücke in der Erforschung von STM32-Peripheriegeräten zu schließen. Eigentlich ist dieses Material einer Beschreibung der Umsetzung der entstandenen Idee gewidmet.

Nur eine kleine Theorie.

Zunächst müssen Sie sich vorstellen, wovon wir sprechen – oder besser gesagt, was eine CMOS-Kamera ist und womit sie verwendet wird.
Dieser Kameratyp gibt Informationen vom Sensor in digitaler Form aus: RGB, YCbCr und auch in komprimierter Form – JPEG. Verschiedene Kameras haben ihre eigenen Nuancen in Bezug auf die Fähigkeiten. Ich werde einen ganz speziellen Fall einer Kamera mit niedriger Auflösung (VGA, 640 x 480) betrachten, die ich in der Antike aus meinem Telefon herausgeholt habe. Siemens C72"(Sensor PixelPlus PO2030N). Diese Kamera ist aufgrund ihrer einfachen Bedienung und ihrer Zugehörigkeit zu einem mehr oder weniger verbreiteten Typ für Studienzwecke am besten geeignet. Vor langer Zeit habe ich dafür eine kleine Platine gebaut (um den Anschluss zu erleichtern) – mit einem 2,8-V-Stabilisator und Pull-up-Widerständen am Bus I2C. Hier ist es (das Kamerakabel und der Stecker sind unter dem Gehäuse versteckt).

Neben Nuancen im Bereich des Datenformats können sich Kameras auch in der Anzahl der Synchronisationspins unterscheiden. Die meisten (meiner Meinung nach) Sensoren verfügen über spezielle horizontale und vertikale Synchronisationsstifte; Es gibt jedoch Kameras, die nur über einen Pixel-Strobe-Ausgang verfügen und Sie mithilfe spezieller übertragener Codes (z. B. 0x00 oder 0xFF). Die Kamera, die ich habe, verfügt über externe Synchronisierungspins.
Sie können eine ungefähre schematische Darstellung der Kamera in Form eines Blocks schätzen.

CMOS-Kameras werden größtenteils über eine Schnittstelle gesteuert I2C(obwohl ich Geräte gesehen habe, die von gesteuert werden UART). Über I2C werden verschiedene Parameter konfiguriert, wie zum Beispiel: Auflösung, Farbraum, Ausgabedatenformat usw.
Abschluss EXTCLK– Kamerataktung, die extern bereitgestellt werden muss. DCLK– ein Strobe-Signal, an dessen Vorder- oder Hinterkante Daten auf dem Kameradatenbus aufgezeichnet werden (z. B. ein Datenbyte eines Pixels der Matrix oder ein „Halbpixel“-Datenbyte, wenn die Kamera in Betrieb ist). RGB565). HSYNC– horizontales Synchronisationssignal, das den Beginn einer neuen Zeile anzeigt, und VSYNC– ein Synchronisationssignal, dessen aktiver Pegel den Beginn eines neuen Frames anzeigt. Schlussfolgerungen D0..D7– Datenbus; In der Regel handelt es sich bei solchen Kameras um 8-Bit.
Lassen Sie uns nun mehr über Synchronisationssignale sprechen.

Die Grafiken zeigen, dass die Kamera für Signalaktivität konfiguriert ist DCLK nur während der aktiven Phase HSYNC(Diese Phase interessiert uns nämlich; das Taktsignal während der „Line-Feed“-Periode ist für uns nicht interessant). Wenn die Kamera auf eine Auflösung von 320 x 240 eingestellt ist, dann bei jedem Impuls HSYNC 320 Impulse passen DCLK, und während des Zeitraums VSYNC – 240 HSYNC.
Wenn wir hineinzoomen, sehen wir, was auf dem Datenbus passiert.

Bei einer steigenden Flanke (in diesem Fall) wird ein Byte vom Datenbus entfernt, das direkt zur Anzeige an das Display gesendet oder zur anschließenden Verarbeitung in einen Puffer „gefaltet“ werden kann.

Theoretisch ist jetzt alles mehr oder weniger klar, was die Schnittstelle betrifft DCMI Mikrocontroller STM32.

Schnittstelle DCMI ist in der Lage, mit einem bis zu 14 Bit breiten Datenbus zu arbeiten, unterstützt sowohl Hardware- als auch Softwaresynchronisation sowie Datenformate: YCbCr, RGB und JPEG.
Außerdem, DCMI enthält einen Puffer FIFO, hat die Möglichkeit, Interrupts zu konfigurieren (einschließlich beim Füllen des Datenregisters) und den Betrieb über zu konfigurieren DMA.

Unterbrechungen von DCMI kann aufgerufen werden, wenn folgende Bedingungen eintreten: Leitungsende, Rahmenende, Empfangspufferüberlauf, Synchronisationsfehler erkannt (bei interner Synchronisation).
Etwas verwundert war ich über das Fehlen eines speziellen Kamera-Taktausgangs. Ich weiß nicht, warum die Entwickler aus SGS Mikroelektronik Es wurde aufgegeben, aber für mich wäre es zum Beispiel sehr praktisch, eine anpassbare Taktquelle zu haben.
Persönlich habe ich einen im PWM-Modus eingeschalteten Allzweck-Timer-Zähler verwendet, um eine Rechteckwelle mit einer Frequenz von 4 MHz zu erzeugen. Natürlich kann man mit einer solchen Uhr keine hohen FPS erreichen, aber ich mache gleich einen Vorbehalt – das Display, das ich verwende, ist nicht angeschlossen FSMC Daher ist die längste Funktion in der gesamten Kette die LCD-Ausgabefunktion, daher schlägt bei einer höheren Frequenz die Bildausgabe auf dem Bildschirm fehl. Deshalb schalte ich vor dem Entladen den Timer aus und danach wieder ein.
Hardwaremodul DCMI enthält zusätzlich zum Datenregister zehn Steuer-/Statusregister. Dies ist: Kontrollregister ( DCMI_CR), Statusregister ( DCMI_SR), Interrupt-Statusregister ( DCMI_RIS), Interrupt-Freigaberegister ( DCMI_IER), Interrupt-Maskenregister ( DCMI_MIS), Interrupt-Flag-Reset-Register ( DCMI_ICR), internes Taktcoderegister ( DCMI_ESCR), internes Clock-Code-Masken-Reset-Register ( DCMI_ESUR), Register der Startwerte beim Erfassen eines Teils des Frames ( DCMI_CWSTRT) und Frame-Fragment-Größenregister im CropWindow-Modus ( DCMI_CWSIZE). Und natürlich das Datenregister - DCMI_DR.
In diesem Fall sind Register, die sich auf die Erfassung eines Teils des Frames und die interne Synchronisierung beziehen, für uns nicht von Interesse. Ich habe mich auch entschieden, Interrupts vorerst in Ruhe zu lassen, daher lohnt es sich, nur das Steuerregister genauer zu betrachten DCMI_CR und Statusregister DCMI_SR.

Das Steuerregister gibt uns die Möglichkeit, das Format der Interaktion mit der Kamera vollständig anzupassen: Datenbusgröße, aktive Leitungspegel HSYNC Und VSYNC, usw.

In Ordnung. Bisschen AKTIVIEREN– Die Inbetriebnahme der Schnittstelle ist selbstverständlich. Feld EDM (erweiterter Datenmodus) – Datenbusgröße; Meine Kamera verfügt über einen 8-Bit-Bus, daher sollte dieses Feld auf „00“ eingestellt sein. Feld FCRC (Steuerung der Frame-Capture-Rate) ermöglicht eine leichte Anpassung des FPC: 00 – alle eingehenden Bilder werden erfasst, 01 – jedes zweite Bild, 10 – jedes vierte. Bits VSPOL Und HSPOL– aktive Ebenen der vertikalen und horizontalen Synchronisationslinien. Aktive Ebenen werden ignoriert und während aktiver Zeiträume werden keine Daten erfasst. Dies sollte berücksichtigt werden. PCKPOL– Bit des aktiven Pegels des Pixel-Strobe – an welcher Flanke des Signals Daten vom Bus gelesen werden sollen: vorne oder hinten. ESS– Bit zur Auswahl der Synchronisationsmethode: extern oder intern. JPEG– Wahl des eingehenden Datenformats – komprimiert oder nicht. ERNTE– Auswahlbit für die Frame-Fragment-Erfassung ( Zuschneidefenster). Wenn dieses Bit auf Eins gesetzt ist, erfasst die Schnittstelle Daten in einem Fenster, das durch die Werte in den Registern definiert wird DCMI_CWSTRT Und DCMI_CWSIZE.

Also, lasst es uns einrichten.

Da ich es gewohnt bin, die Standard-Peripheriebibliothek von ST zu verwenden (obwohl ich sie in den ersten Iterationen der Arbeit mit neuen Peripheriegeräten nie verwende, bis ich manuell an den Registern herumbastele), habe ich die Einstellungen mithilfe der Bibliothek vorgenommen.

Void DCMIInitialRoutine(void) ( DCMI_InitTypeDef DCMI_CamType; DCMI_DeInit(); DCMI_CamType.DCMI_CaptureMode = DCMI_CaptureMode_Continuous; DCMI_CamType.DCMI_CaptureRate = DCMI_CaptureRate_All_Frame; DCMI_CamType.DCMI_ExtendedDataMode = DCMI_ExtendedData Mode_8b; DCMI_CamType.DCMI_Synch roMode = DCMI_SynchroMode_Hardware; DCMI_CamType(ENABLE);
Tatsächlich war es für meine Zwecke möglich, kein einziges Bit im Register zu berühren DCMI_CR– Standardmäßig sind sie zurückgesetzt – mit Ausnahme der Bits ERFASSEN Und AKTIVIEREN.
Die Schnittstelle ist konfiguriert und einsatzbereit. Nachdem ein Taktsignal an die Kamera gesendet wurde, beginnt die Schnittstelle, die Daten zu empfangen, die wir verarbeiten müssen.
Zunächst habe ich mir die einfachste Aufgabe gestellt – das Bild auf dem Display anzuzeigen, damit die Datenverarbeitung minimal ist.
Das Statusregister hilft uns beim rechtzeitigen Lesen von Daten aus dem Empfangspuffer DCMI_SR.

Zum Lesen stehen nur sehr wenige Bits zur Verfügung – nur drei. Bits HSYNC Und VSYNC signalisieren den Zustand der entsprechenden Leitungen: aktive Phase oder Leitungseinspeisung; Das Interessanteste ist das Gebiss FNE. Es sagt uns, dass wir den Puffer mit Daten füllen sollen. Oder weil Sie es nicht ausgefüllt haben.
Überprüfen des Status des Bits in einer vorgefertigten Schleife FNE V DCMI_SR, erfahren wir über die Ankunft von Daten im empfangenden 32-Bit-Puffer. In meinem Fall werden die Daten so lokalisiert:

Beim Setzen des Bits FNE im Statusregister DCMI_SR Der Empfangspuffer enthält vier Bytes, Daten von zwei benachbarten Pixeln: Byte0 Und Byte1 – 16 Pixelbits N, A Byte2 Und Byte3 – 16 Pixelbits n+1. Ich muss sie nur noch kombinieren und an die Anzeige senden. So sieht die Hauptschleife aus:
while (1) ( while ((DCMI_GetFlagStatus(DCMI_FLAG_FNE)) == RESET); //Warten auf den Puffer TIM_Cmd(TIM3, DISABLE); //CAM-Uhr deaktivieren cam_grab = (DCMI->DR); //Puffer lesen SendDataByte_LCD (cam_grab); cam_grab = (DCMI->DR)>>16; //2. Teil des Puffers lesen SendDataByte_LCD (cam_grab);
Das heißt, ich warte darauf, dass das Bit gesetzt wird FNE im Statusregister DCMI_SR, und dann lade ich in zwei Schritten 16 Bit Daten auf das Display hoch.
An dieser Stelle würde ich gerne zu einer logischen Schlussfolgerung kommen, aber dazu sollte es nicht kommen.
Nachdem ich die Firmware geflasht und den MK neu gestartet hatte, sah ich auf dem Display... nein, ich sah meine eigene, sehr vertraute Physik, aber in Schwarz- und Blautönen. Rote und grüne Farben fehlten völlig.
Nach einem kurzen Showdown mit dem Debugger wurde Folgendes entdeckt: Das Schnittstellendatenregister enthielt nur 16 Datenbits pro Pixel, wobei die unteren 8 Bits an Ort und Stelle lagen Byte0 (siehe Abbildung oben), und die Ältesten sind an Ort und Stelle Byte2 . Räume Byte1 Und Byte3 sie waren leer. Bisher habe ich nicht verstanden, woher diese Diskrepanz zwischen Dokumentation und Realität kommt, und vielleicht werde ich mich an STM wenden.
Dadurch ist es uns gelungen, über die Schnittstelle ein Bild von der Kamera abzurufen DCMI, wenn auch nicht ohne einige Schwierigkeiten. In der Abbildung zeige ich ein Foto des Displays, auf dem das Bild des Demoboards angezeigt wurde STM32F3Discovery von meiner Kamera.

Folgendes werden wir in den Schlussfolgerungen sehen: EXTCLK, PIXCK, HSYNC Und VSYNC, wenn Sie einen Logikanalysator anschließen.

Alles sieht genau wie erwartet aus: 240 Impulse HSYNC passt in die Dauer von einem VSYNC, 320 PIXCK- in einem HSYNC. Während der aktiven Phase HSYNC Die Kamera erzeugt keine Signale PIXCK– genau so, wie sie eingerichtet wurde.
Generell hat mich die Benutzeroberfläche etwas enttäuscht. Das Fehlen eines „Standard“-Kamera-Taktgebers, das Fehlen mehr oder weniger interessanter integrierter Funktionen (wie wäre es mit einem Hardware-JPEG-Encoder?) und sogar das Tanzen mit einem Tamburin um ein halbgebackenes Produkt FIFO…
Organisation der Kameraarbeit bei Unterbrechungen PIXCK, HSYNC Und VSYNC Ich hatte nicht so große Probleme wie bei der Arbeit mit der Kamera mit Hardware DCMI.
In naher Zukunft werde ich jedoch versuchen, ein Bild aufzunehmen und zu komprimieren JPEG, und versuchen Sie, ein Bild auf die SD-Karte zu schreiben.
PS. Für alle Fälle gebe ich einen Link zum Projekt für „ Code::Blöcke„- plötzlich wird es für jemanden nützlich sein.