Technische Universität Berlin
DSP-Labor SoSe 2003
„auto focus on iris project“
Betreuer: Dr.-Ing. Guntram Liebsch Teilnehmer: Andreas Bresch Khalid Elazouzi Zhao Jiang Denny Gumlich Zheng Kuang Lech Modrzejewski Reik Schröder
Technische Universität Berlin
Inhaltsverzeichnis: 1 2 3
4
5
6 7
8
Einleitung............................................................................................................................................... 3 1.1 Die Idee. ........................................................................................................................................ 3 1.2 Die Hardware im Überblick................................................................................................................ 3 Die Kamera. ........................................................................................................................................... 5 Das MC-Board......................................................................................................................................... 6 3.1 Allgemeines. ................................................................................................................................... 6 3.2 Handhabung des MSP430 Microcontrollers. ......................................................................................... 7 3.2.1 Bedienung der Entwicklungsumgebung IAR Workbench................................................................... 7 3.3 Das Assemblerprogramm für unseres Projekt. ..................................................................................... 8 Das Videoboard......................................................................................................................................11 4.1 Hardware – Videomodul. .................................................................................................................11 4.1.1 Allgemein................................................................................................................................ 11 4.1.2 Funktionsweise. ....................................................................................................................... 11 4.1.3 Datenausgabe. ........................................................................................................................ 12 4.2 Software .......................................................................................................................................12 4.2.1 Die Steuerung der Karte. .......................................................................................................... 12 4.2.2 Bildskalierung und Bildausschnitt. .............................................................................................. 12 4.2.3 Weißabgleich. .......................................................................................................................... 13 Kommunikation zwischen DSP-Board und MC-Board. ..................................................................................15 5.1 Die McBSP als Kommunikationsschnittstelle zwischen DSP und Mikrocontroller. ......................................15 5.2 SPI-Mode (Serial Peripheral Interface) der McBSP-Schnittstelle. ...........................................................15 5.3 Kommunikationsablauf zwischen DSP und Mikrocontroller....................................................................16 5.4 Datenprotokoll. ..............................................................................................................................17 5.4.1 Übersicht. ............................................................................................................................... 17 5.4.2 Allgemeine Befehle................................................................................................................... 18 5.4.2.1 NOP ............................................................................................................................... 18 5.4.2.2 ACK ............................................................................................................................... 18 5.4.2.3 NACK ............................................................................................................................. 18 5.4.2.4 RESET ............................................................................................................................ 18 5.4.3 RS232 Kommunikation. ............................................................................................................ 18 5.4.3.1 TX_RS232 DSP ! MC ....................................................................................................... 18 5.4.3.2 RX_RS232 MC ! DSP....................................................................................................... 18 5.4.4 LED-Display. ........................................................................................................................... 18 5.4.4.1 SET_LED DSP ! MC......................................................................................................... 18 5.4.5 IGIO Port. ............................................................................................................................... 18 5.4.5.1 REQ_IGIO....................................................................................................................... 18 5.4.5.2 IN_IGIO ......................................................................................................................... 18 5.4.5.3 INT_IGIO........................................................................................................................ 19 5.4.5.4 OUT_IGIO....................................................................................................................... 19 5.4.5.5 DIR_IGIO ....................................................................................................................... 19 5.4.5.6 IE_IGIO.......................................................................................................................... 19 5.4.5.7 IES_IGIO........................................................................................................................ 19 5.4.6 GIO Port. ................................................................................................................................ 19 5.4.6.1 REQ_GIO ........................................................................................................................ 19 5.4.6.2 IN_GIO .......................................................................................................................... 19 5.4.6.3 DIR_GIO......................................................................................................................... 20 5.4.6.4 OUT_GIO........................................................................................................................ 20 5.4.7 Analog Eingänge. ..................................................................................................................... 20 5.4.7.1 IN_ADC .......................................................................................................................... 20 5.4.7.2 REQ_ADC ....................................................................................................................... 20 5.4.8 Pulsweiten modulierte Ausgänge. ............................................................................................... 20 5.4.8.1 SET_PWM ....................................................................................................................... 20 5.4.8.2 FINE_PWM ...................................................................................................................... 20 5.5 Initialisierung und Benutzung der McBSP. ..........................................................................................21 Kommunikation zwischen DSP-Board und Kameraboard. .............................................................................24 Focus....................................................................................................................................................25 7.1 Einleitung. .....................................................................................................................................25 7.2 Bildschärfebestimmung. ..................................................................................................................25 7.2.1 Transformation mit DCT............................................................................................................ 25 7.2.2 Auswertung der Transformationsdaten........................................................................................ 27 7.2.3 Ergebnisse. ............................................................................................................................. 27 7.3 Bestimmung des schärfsten Bildes. ...................................................................................................28 7.3.1 Beschreibung des Algorithmus. .................................................................................................. 29 7.3.2 Anmerkungen.......................................................................................................................... 29 7.3.3 Zweite Variante. ...................................................................................................................... 29 Fortsetzung folgt – Probleme, Ideen und Lösungen für Nachfolgeprojekte. ....................................................31
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 2
Technische Universität Berlin
1 Einleitung. 1.1 Die Idee. Die Grundidee unseres Projektes besteht darin, unser Vorgängerprojekt iScan weiterzuentwickeln. In dem Projekt iScan wird die Iris eines menschlichen Auges aufgenommen und mit Hilfe eines DSP ausgewertet, um so z.B. ein Zugangskontrollsystem zu ermöglichen. Dazu wird die Iris mit einem Kameramodul aufgenommen. Das Videosignal der Kamera wird in einer Videoplatine digitalisiert und zwischengepuffert. Diese Platine wurde so entwickelt, daß sie auf das Daughtercard Interface unseres DSP-Entwicklungsboard als Huckepackplatine aufgesteckt werden kann. Der DSP liest anschließend das Bild ein und wertet es aus. Da das Objektiv des Kameramoduls nur eine begrenzte Tiefenschärfe besitzt, muß vor jedem Scanvorgang darauf geachtet werden, daß das Bild der Kamera über eine ausreichende Schärfe verfügt. Diese konnte durch geschicktes Vor- und Zurückbewegen des Kopfes vor der Kamera beeinflußt werden ein Auge auf die Kamera und eins auf den Kontrollmonitor gerichtet. Unsere Idee war es nun, das Kameramodul durch einen Autofocus zu ergänzen.
1.2 Die Hardware im Überblick.
Bild 1.2.1 Die einzelnen Module des Projektes Da wir das Projekt iScan weiterentwickeln wollen, setzen wir natürlich auf die vorhandene Hardware auf. Als “zentrale Recheneinheit” diente das TMS320C6711 DSP Starter Kit (DSK) der Firma Texas Instruments 1. Hierauf arbeitet der Signalprozessor C6711 DSP (Texas Instruments) mit einem Takt von 150 MHz, 4/64 KByte Cache/RAM, zwei McBSPs, zwei Timern usw.. Das TMS320C6711 verfügt über ein Daughtercard Interface, worauf das Video-Board aufgesteckt wird. Das Video-Board wurde ebenfalls im Rahmen eines DSP-Projektes entworfen und später während einer Studienarbeit weiterentwickelt. Das Videoboard digitalisiert ein Videosignal mit Hilfe eines Videostream Decoders (Brooktree BT829A) und legt dieses dann in zwei FIFOs (Averlogic AL422) ab. Der C6711 und der BT829 kommunizieren über das I2C-Protokoll, die FIFOs werden über das EMIF (Extendent Memory Interface) von dem DSP ausgelesen. Das Videosignal liefert ein Schwarz/Weiß-Kameramodul (Conrad Elektronik, Best.-Nr. 116750). Dieses Modul verfügt über eine einfache Linse, welche wir durch ein komplettes Objektiv einer defekten Videokamera (Sony) ersetzten. Der Vorteil dieses Objektivs besteht in den schon vorhandenen Steuermotoren für Schärfe, Zoom und Blende, sowie den Endschaltern und Potentiometern zur Positionsbestimmung der einzelnen Motoren. 1
http://focus.ti.com/docs/prod/productfolder.jhtml?genericPartNumber=TMS320C6711
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 3
Technische Universität Berlin
Leider reichen die Möglichkeiten des AD/DA-Wandlers des TMS320C6711 für die Steuerung des Objektivs nicht aus, so dass wir dies einem Microcontroller überlassen müssen. Dafür entwickelten wir ein MCBoard, welches ebenfalls als Huckepackplatine auf dem Daughtercard Interface des TMS320C6711 aufgesteckt wird (zwischen TMS320C6711 und Video-Board). Als Microcontroller dient uns der MSP430 der Firma Texas Instruments 2. Der MC arbeitet mit einem Takt von 8 MHz, verfügt über zwei serielle Schnittstellen, 8-Kanal AD-Wandler, drei Timer, 48 kB integrierter Flashspeicher, sechs I/O-Ports und kann über ein kostenloses Programmiertool und über eine serielle Schnittstelle komfortabel programmiert werden. Der DSP kommuniziert mit dem MSP430 über eine serielle Schnittstelle mit einem in unserem Projekt entwickelten Protokoll. Somit sind wir in der Lage, die Motoren des Videokamera-Objektivs mit Hilfe des MC-Boards vom DSP so zu steuern, dass das Kameramodul ein scharfes Bild der Iris aufnimmt. 2
http://focus.ti.com/docs/prod/productfolder.jhtml?genericPartNumber=MSP430F148
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 4
Technische Universität Berlin
2 Die Kamera. Als Kameramodul verwendeten wir eine S/W Variante von Conrad Elektronik (Best.-Nr. 116750), das noch von vorherigen Projekten vorhanden war. Das Objektiv stammt aus einer defekten Videokamera der Marke Sony. Wir haben versucht, das Kameramodul auf das Objektiv aufzuflanschen. Leider ist uns das nur mäßig gut gelungen. Denn die Position des CCD-Chips der „neuen“ Kamera ist offensichtlich nicht dieselbe wie die des alten Chips. Dadurch hat die Kamera eine extreme Makrowirkung und der Fokus hat nur einen sehr stark begrenzten Bereich. Deshalb nutzten wir zur „Scharfstellung“ stattdessen den Zoom, um unnötige Verzögerungen durch mechanische Umbauten zu vermeiden. Der Schaltplan der Kamerabox:
Kamera.sch
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 5
Technische Universität Berlin
3 Das MC-Board. 3.1 Allgemeines.
Bu ffe r Bu ffe r
Po rt 6
M SP4 3 0 F1 4 8
Po rt 2
Po rt 4
Po rt 1
Po rt 5
Le ve l sh ifte r
Po rt 3
Bild 3.1.1 Übersichtsbild der MC-Platine Das vorhandene Objektiv besitzt je einen Gleichstrommotor für Zoom und Fokus. Der Fokus hat außerdem einen Endschalter für beide Richtungen. Der Zoom verfügt über ein Potentiometer zur Positionsbestimmung. Am Objektiv ist noch eine Blende integriert, die wahrscheinlich als mehere Zugmagnete realisiert ist. Da der DSP standardmäßig nur über synchrone serielle Schnittstellen verfügt, haben wir uns entschieden, einen zusätzlichen Microcontroller zur Ansteuerung der Motore und Magneten einzusetzen. Wobei der MC nur reine Steueraufgaben erledigt. Wir haben uns für einen TI MSP430F148 Microcontroller entschieden, da er leicht verfügbar und leicht zu programmieren ist. Er hat 2 serielle Schnittstellen, 8-kanal 12 Bit ADC, 2 Timer (3-fach und 7-fach) und 48 kB integrierter Flashspeicher. Die Entwicklungsumgebung ist kostenlos von der TI Homepage downloadbar und ermöglicht eine Programmierung in C oder Assembler. Der MC wird über eine RS232 Schnittstelle programmiert. Zu Debugzwecken und evt. Für spätere andere Anwendungen haben wir noch eine 7-Segment LED Anzeige und eine asynchrone serielle Schnittstelle (RS232) auf der MC-Platine integriert. Wir müssen noch empirisch ermitteln, ob die Motore nur mit Rechts-/Linkslauf oder mit PWM (Drehzahlregelung) angespochen werden. D.h. ob wir die Timer des MC programmieren oder einfach nur die Ports als digitale Ausgänge nutzen. Ich denke, für diese einfache Anwendung ist ein Assemblerprogramm ausreichend, da hauptsächlich nur Peripherieeinheiten de MC programmiert werden müssen.
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 6
Technische Universität Berlin
3.2 Handhabung des MSP430 Microcontrollers. 3.2.1
Bedienung der Entwicklungsumgebung IAR Workbench.
Als erstes erstellt man mittels File/New eine neues Projekt: Hier können jetzt neue Quelldateien erzeugt oder vorhandene eingefügt werden. Neue Dateien können mit File/New – Source/Text erstellt werden.
Zum einfügen in das Projekt startet man dann Project/Files und fügt die entspechenden Dateien mit Add hinzu : Es können C mit Endung .C oder Assembler mit Endung .s43 Dateien sein. Headerdateien (.h) werden über include Suchpfade automatisch gefunden. Sie können für Assembler oder C oder beides kombiniert benutzt werden. Da im Assembler ; einen Zeilenkommentar darstellt, kann man so bestimmten Code nur für C „sichtbar“ machen. Auch im Assembler werden Präprozessor Direktiven ausgewertet, d.h. auch #define, #ifdef ... können im Assembler benutzt werden. Für genauere Informationen zum Assembler und C-Compiler gibt es entsprechende Einträge in der Hilfe zur IAR Workbench. Man muß noch unter Project/Options... den Zielprozessor einstellen. Das tut man unter XLINK/INCLUDE. Dort stellt man unter XCL filename die Prozessorkonfiguration ein. Das ist in unserem Fall: „$TOOLKIT_DIR$\icc430\msp430F148A.xcl“ für Assembler und „$TOOLKIT_DIR$\icc430\msp430F148C.xcl“ für C Programme ein. Dadurch wird die Speicheraufteilung festgelegt. Das muß für alle Targets (Debug/Release) gemacht werden! Wenn der Sourcecode dann fertig ist, kann er mit Project/Make (Taste F9) oder dem Symbol erstellt werden. Dabei ist darauf zu achten, daß im Projekt-Fenster der richtige Modus ausgewählt ist : für den Simulator ! Debug und zum Laden auf das Target ! Release.
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 7
Technische Universität Berlin
Wenn man jedoch das Bootstaploader Tool BSL.EXE aus den Aplicationnote SLAA096B.PDF benutzen will, muß man noch, nachdem Release ausgewählt wurde, unter Project/Options... für den Linker das Ausgabeformat auf „msp430-txt“ gesetzt werden. Dann kann auch schon das Programm mittels bsl.exe auf das Target geladen werden. Dazu schließt man das serielle Kabel an die Prog-Buchse des MSP430DB an. Dann started man einfach „bsl PROJEKTPFAD\Release\PROJEKTNAME.txt“. Dabei ist darauf zu achten, daß im aktuellen Verzeichnis die Datei Patch.txt vorhanden ist. Sie wird von bsl.exe benötigt.
3.3 Das Assemblerprogramm für unseres Projekt. Für die Programmierung unseres Microcontrollers haben wir uns für ein Assemblerprogramm entschieden. Es beginnt so : #include "msp430x14x.h" #include "interface.h"
Definitionen für unseren Prozessor einbinden Definitionen für unser Protokoll und MSP430DB einbinden
#define
jiffies
R7
#define
RS232_PTR
R4
#define
RXSPIb
R5
#define
RXSPI_PTR
R6
allgemeiner Zeitzähler, wird durch TA0 Timer alle 10ms inkrementiert Zeiger auf nächstes zu sendendes RS232 Zeichen, Stop wenn Zeichen = 0 empfangenes Zeichen auf SPI Schnittstelle, wird manchmal auch direkt mit R5 angesprochen, da der Assembler offensichtlich nicht immer richtig zuordnen kann 0 wenn kein Word im Puffer steht, 1 wenn eines drin ist
RSEG DS
CSTACK 0
Stacksegment definieren
RSEG DS 32
IDATA0
RS232b
Datensegment definieren Puffer für Zahlenausgaben auf RS232 im RAM definieren Beachte : Im Datensegment sollten Definitionen immer mit DS (nicht DB oder DW) erfolgen, da sonst der Assembler über die Initialisierung von RAM meckert!
Reset
RSEG mov
CODE #SFE(CSTACK),SP
mov dint
Codesegment definieren (liegt im Flash) Stackpointer setzten, hier wird bei einem Reset gestartet, siehe auch Interruptvektortabelle #(WDTHOLD+WDTPW),&WDTCTL Watchdogtimer anhalten alle Interrupts abschalten
Dann wird der Quarzoszillator initialisiert und nacheinander alle Peripherieeinheiten eingestellt und angeschalten. Dabei wird für jeden Schritt der Initialisierung auf dem LED-Display eine Zahl weiter gezählt, d.h. Zahl 0 1 2 3 4 5 6 7 8
Bedeutung LED-Display wurde initialisiert Timer A wurde initialisiert Timer B wurde initialisiert Wird nicht benutzt. An dieser Stelle wartet das Board auf ein Signal des DSP, d.h. es wird erst weiter gezählt, wenn initMSP430DB() auf dem DSP aufgerufen wurde! USART1 (RS232) wurde initialisiert SPI Port wurde initialisiert Interrupt wurden global aktiviert und Begrüßungstext auf RS232 Schnittstelle ausgegeben Übertragung des Begrüßungstextes ist fertig, d.h. RS232 funktioniert ACK wurde zum DSP gesendet, um Bereitschaft anzuzeigen
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 8
Technische Universität Berlin
Jetzt ist das MSP430 Board bereit, Kommandos vom DSP zu empfangen. Das Hauptprogramm sieht dann so aus : Mainloop
CMDTab
cmp jz
#0, RXSPI_PTR Mainloop
wurde ein Befehl empfangen ? nein ! springe zurück zu Mainloop
clr cmp jz
RXSPI_PTR #NOP, R5 Mainloop
löschen des Empfangsflags Überprüfung auf NOP befehl wenn NOP, dann ignorieren und bei Mainloop weitermachen
mov swpb rrc rrc
R5, R14 R14 R14 R14
empfangenes Word nach R14 kopieren Bytes tauschen und dann ruter schieben, bis die 3 CMD Bits an 2. Stelle! stehen, denn die Verzweigungstabelle enhält 16 Bit Adressen!
rrc rrc
R14 R14
mov
R5, R15
call
CMDTab(R14)
jmp
Mainloop
dw
CMD0, CMD1, CMD2, CMD3, CMD4, CMD5, CMD6, CMD7
and
#0x00E, R14
CMD ausmaskieren empfangenes Word nach R15 kopieren, denn alle Unteroutinen erwarten Parameter in R15 Unterroutine ensprechend des CMDs aus der CMDTab aufrufen nach Ende dieser auf neue Befehle warten
Beispiel einer solchen Unterroutine : CMD6
; SET_PWM call mov call ret
#setPWM #ACK, R15 #sendSPIm
setPWM routine aufrufen und mit ACK beantworten zurück zu Hauptprogramm
Für Debugzwecke gibt es zwei Macros zum Ausgeben von Text auf der RS232 Konsole : PRINTSTRING label, sep PRINTPARAM reg, label, sep
schreibt erst das Label und dann den Separator (z.B.Komma) auf die Konsole schreibt erst das Label, dann den Inhalt des Registers als Hexzahl und dann den Separator auf die Konsole
Dabei sind unbedingt die “#“ anzugeben, denn sonst wird nicht die richtige Adresse sondern der Wert der dort steht benuzt. Einzige Ausnahme sind Sprünge, dort müssen Label ohne „#“ angegeben werden! Beispiel: PRINTPARAM R15, #textReqADC, #textSep ... textReqADC textSep
db "REQ_ADC called " db ", " even
unbedingt nach solchen Textdefinitionen angeben, damit nachfolgender Code wieder auf ein gerades Word aligned wird !!!
Es können Nullterminierte Strings direkt mit „“ angegeben werden; will man Sonderzeichen, wie CRLF benutzen, so sollten ‚’ den Text einschließen und dann mit Komma getrennt direkt dahinter die Sonderzeichen folgen. Die Null am Ende nicht vergessen!!
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 9
Technische Universität Berlin
Beispiel: textHallo
db 'Hello World!' , 13, 10,0
Um die Ausgaben zu aktivieren, muß man noch das Präprozessorsymbol _PRINTPARAMS definieren. das macht man in dem Projektoptionen unter A430/#define. Natürlich wieder für alle Targets, für die es aktiv sein soll. Durch diese Vorgehensweise kann man sehr leicht die RS232 Schnittstelle nur für den DSP benutzen, indem man das define einfach löscht.
Zur Kommunikation mit dem DSP dient die Routine sendSPIm: sendSPIm
; sends word in R15 manually without USART function keine neuen Interruptanfragen vom DSP erlauben bic.b #1, &P1IE Register retten push R15 push R14 push R13 push R12 Bit Maske initialisieren mit 1000 0000 0000 0000b mov #0x8000, R14 Register für empfanges Word löschen clr R13 FSX H! !L : Übertragung beginnt bic.b #STE, &P3OUT erste Taktflanke L! ! H bis.b #CLK, &P3OUT Schleife, die für jedes Bit durchlaufen wird sendSPIbitLoop erstmal 0 auf TxD schreiben bic.b #TXD, &P3OUT jetzt schauen, ob es wirklich eine 0 ist ? R14 = bit R14, R15
sendSPImT1
sendSPImR1
jz sendSPImT1 bis.b #TXD, &P3OUT ; transmit bit is set bic.b #CLK, &P3OUT
Bitposition falls wirklich eine 0, dann einfach weit sonst 1 auf TxD schreiben jetzt sollte TxD den richtigen Pegel haben also Taktflanke H! !L
; sample RX bit bit.b #RXD, &P3IN jz sendSPImR1 add R14, R13 bis.b #CLK, &P3OUT clrc rrc R14 jnz sendSPIbitLoop bis.b #STE, P3OUT mov R13, RXSPIb
nun RxD testen wenn RxD = 0 weiter machen wenn RxD = 1 Bitwert (R14) zum Ergebnis addieren Taktflanke L->H Carry Flag löschen, um es nicht in R14 zu schieben R14 um eins nach rechts schieben ! nächstes Bit solange, bis Word übertragen ist FSX H! !L : Übertragung zu Ende empfangenes Word in Puffer schreiben
mov
#1, RXSPI_PTR
Empfangsstatus auf 1 setzten
pop pop pop pop bis.b ret
R12 R13 R14 R15 #1, &P1IE
Register zurückholen
Interrupts vom DSP wieder erlauben
Den gesamten Quelltext für den MSP430 kann man hier nachlesen : DSP_Interface.s43
interface.h
Dem Schaltplan können Informationen über die Hardware entnommen werden. Dp_v102.sch DSP-Labor
Dp_v102.brd
SS 2003
Gruppe: FrVo
Seite 10
Technische Universität Berlin
4 Das Videoboard. Für die Aufnahme der Bilder verwenden wir eine Kamera, die bereits im Abschnitt 2 beschrieben wurde. Diese liefert schon ein analoges Video Signal (Composite), welches direkt an einem Monitor angezeigt werden kann. Da es sich bei diesem Signal aber um ein analoges Signal handelt, muss es erst digitalisiert werden, damit wir es mit dem DSP bearbeiten können. Hierfür benutzen wir ein Videomodul, welches von einer vorherigen Projektgruppe gefertigt wurde. Es besteht aus einem Videostream Decoder (Brooktree BT829A) und 2 FIFOs (Averlogic AL422). Der Videostream Decoder digitalisiert das Pal-Bild zeilenweise in das YUV2 4:2:2 Format. Da der DSP die Daten aber nicht schnell genug über das EMIF (Extendent Memory Interface) vom Videostream Decoder einlesen kann, müssen diese im FIFO zwischengespeichert werden. Die maximale Bildgröße beträgt 640x480 Pixel, die jedoch aus Geschwindigkeitsgründen auf 160x120 reduziert wurde.
4.1 Hardware – Videomodul.
Bild 4.1.1 Vereinfachtes Blockbild des BT829A Chips
4.1.1
Allgemein.
Die Konfiguration der Register des Videostream Decoders BT829A erfolgt über das I2C Bus-Protokoll oder JTAG. Zur Initialisierung des BT829A müssen die Timing-Parameter für eine bestimmte Auflösung eingestellt werden. Die Auflösung beträgt bei voller Bildgröße 640x480 Pixel oder wie wir für den Scherfäalgorithmus aus geschwindigkeitsgründen festgelegt haben 160x120 Pixel Weiterhin können Helligkeit (Brightness Control Register), Kontrast (Luma Gain Register) und Farbsättigung (Chroma (U) und Chroma (V) Gain Register) sowie Bildgröße und Bildausschnitt verändert werden. Die digitalisierten Videodaten werden dann vom FIFO des Videomoduls ausgelesen und per DMA Transfer in den schnellen Speicher des DSP Entwicklungsbords übertragen.
4.1.2
Funktionsweise.
Aus dem anliegenden Oszillatorsignal mit einer Frequenz von 35,47MHz (= 8*PAL fsc) generiert der Videochip 2 Clocks (CLKx1 und CLKx2), deren Raten der Oszillatorfrequenz bzw. ihrer Hälfte entsprechen. Die A/D-Wandlung des Composite-Videosignals erfolgt direkt mittels Flash A/D-Wandler bei CLKx2 also mit mehr als der doppelten zu erwartenden Videobandbreite. Für die Verwendung von PAL-Einganssignalen an CIN wird das Input-Format-Register IFORM mit den Default-Werten gesetzt (Auto-Formaterkennung). Die Decodierung des Videosignals wird nach der Digitalisierung durchgeführt. Zunächst erfolgen eine Tiefpassfilterung und eine anschließende Dezimierung der Rate auf CLKx1. Dann werden Chrominanz- und Luminanzsignal separiert (NotchFilter & Bandpass). Aus dem Chrominanzsignal werden per QAMDemodulation die Farbdifferenzsignale U und V gewonnen.
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 11
Technische Universität Berlin
Anschließend werden Einstellungen verschiedener Video-Filter für Kontrast, Helligkeit etc. durch setzen der entsprechenden Werte in den Register 0x0A bis 0x0F umgesetzt. Danach erfolgen die örtliche und zeitliche Skalierung des Videodatenstroms. Dazu müssen die entsprechenden Werte in den Registern 0x02 bis 0x09 gesetzt werden.
4.1.3
Datenausgabe.
Bei voller Auflösung steht uns vorerst ein Datenstrom mit 864X625x16bit/Pixel (inkl. aller BlankingIntervalle) zur Verfügung. Dies entspricht einer Auflösung von 720x576 aktiven Bildpunkten. Durch Setzen der entsprechenden Scaling- und Cropping-Register wird von uns die Pixelausgabe auf 640x480 aktive Pixel eingeschränkt um das Abspeichern eines kompletten Bildes im FIFO zu ermöglichen. Dabei wird nicht der eigentliche Datenstrom verändert, sondern nur das ACTIVE-Signal entsprechend angepasst. Bei dieser Auflösung ist es nicht möglich, beide Halbbilder des Videosignals als ein Vollbild auszugeben. Sie werden jeweils aufeinanderfolgend als 240x640 Pixel-Bilder ausgegeben. Welches der Halbbilder gerade ausgegeben wird, wird durch FIELD angezeigt. Synchronisationsinformationen werden bei uns nicht in den Datenstrom integriert. Das Output-Interface unterstützt grundsätzlich zwei verschiedene Formate. Zum einen, einen 16bitPixeldatenstrom (CLKx1) wobei jeweils ein Byte für das Helligkeits- und ein Byte für das Farbsignal (abwechseln U und V) stehen, zum anderen einen 8bit Pixeldatenstrom (CLKx2) wo Helligkeits- und Farbsignal byteweise zeitlich aufeinanderfolgen. Bei uns kommt das erste Format zum Einsatz, welches im OFORM-Register festgelegt wird. Von uns werden dort die Standardwerte gesetzt, was einen von Steuerinformationen freien 16bit-Datenfluss zur folge hat. Die 2 Bytes des Videodatenstroms werden auf 2 getrennten FIFO-Bausteinen geschrieben. Für uns ist hierbei nur das Byte/Pixel des Helligkeitssignals von Interesse. Über das Signal VRESET (Bildwechsel) wird der FIFO zurückgesetzt und bei den, als aktiv festgelegten Pixeln, mit den Videodaten beschrieben indem Write_Enable des FIFOs über das ACTIVE Signal des Videochips aktiviert wird. Zur Synchronisation liegen dort die Signale von CLKx1 an.
4.2 Software 4.2.1
Die Steuerung der Karte.
Diese erfolgt durch I2C Bus-Protokoll. Dies ist ein serielles Busprotokoll, das über zwei Signalleitungen (SDL und SCL) ausgeführt wird mit bis zu 100 kbits/sek. Wobei die SCL Leitung den asynchronen Takt zum Datenübernehmen liefert. Wahlweise gibt es die Möglichkeit den Videochip über JTAG Schnittstelle anzusteuern
4.2.2
Bildskalierung und Bildausschnitt.
Wenn gewollt, können die Bilder vor dem Übertragen und Bearbeiten durch entsprechende Einträge in die VSCALE, HSCALE und CROP Register skaliert und ausgeschnitten werden. Zwei als entsprechend schnell angepriesene Bibliotheksfunktionen (scale_vert und scale_horz) sind zwar vorhanden, sie sind in diesem Fall sogar wesentlich flexibler, jedoch sind sie für unser einfaches Anliegen zu komplex. Eine Skalierung kann nur jeweils horizontal oder vertikal durchgeführt werden, die Datenformate passen nicht zu unserer Anwendung (doppelter Speicherbedarf pro Bild) und es müssten extra entsprechende Filtermatrizen erzeugt werden. Da wir für den Schärfealgorithmus, aus Geschwindigkeitsgründen, skalierte Bilder brauchen, haben wir uns entschieden diese auf 160x120 Pixel direkt auf dem Videochip zu skalieren. Dies entspricht 16-facher Größenreduzierung (siehe Bild 4.2.3.1) im Verhältnis zur maximalen Bildgröße, die in die FIFO’s übertragen werden kann. Dabei wird die Datenmenge von 300kB auf 19kB reduziert. Nach der Skalierung müssen auch zusätzliche Filter eingeschaltet werden, da sonst das Bild sehr gestört am Ausgang vorliegt. (Zur Einzelheiten siehe die Quellcodedatei BT829.c) Ausschnitt aus BT829.c: #define #define #define #define #define #define #define
HSCALE VSCALE HACTIVE VACTIVE HDELAY VDELAY VTC
DSP-Labor
SS 2003
0x3CF2 0xFA00 160 480 6+50 0x16+50 0x01
Gruppe: FrVo
Seite 12
Technische Universität Berlin
Originalbildgröße: 640x460 Pixel
Skaliertes Bild: 160x120 Pixel
Bild 4.2.3.1 Skalierung der Bilder
4.2.3
Weißabgleich.
Nach der Bildskalierung haben wir aber zunächst feststellen müssen, dass manche Bilder, in weißen Flächen schwarze Flecken aufweisen (siehe Bild 4.2.3.2).
Skaliert ohne Weißabgleich
Skaliert mit Weißabgleich = -2
Skaliert mit Weißabgleich = - 6 Originalbild
Bild 4.2.3.2 Weißabgleich
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 13
Technische Universität Berlin
Es ist scheinbar ein Chipfehler!. Möglicherweise kommt es bei der Skalierung auf dem Chip zu einem Überlauf so, dass die weißen Pixel beim Aufsummieren auf schwarze Pixel abgebildet werden. Abhilfe schafft hier der Weißabgleich, der im WC_DN Register heruntergesetzt werden kann. Dieser führt allerdings zu Reduzierung des Kontrasts und damit zu Abnahme der Schärfewerte im Schärfealgorithmus.Wie wir aber durch Austesten festgestellt haben, ist dieser Einfluss nicht so stark, dass das Verfahren der Skalierung als solches nicht funktionieren würde. Für „normale“ Bilder reicht eine feste Einstellung des Weißabgleichwertes auf –6 (siehe Bild 4.2.3.3) vollkommen aus. Ausschnitt aus BT829.c: #define WCDN #define BTADC
DSP-Labor
SS 2003
0x7A 0x83
// white crush down for scaled picture = -6 // init + WhiteCrush on
Gruppe: FrVo
Seite 14
Technische Universität Berlin
5 Kommunikation zwischen DSP-Board und MCBoard. 5.1 Die McBSP als Kommunikationsschnittstelle zwischen DSP und Mikrocontroller. Die Mikrocontrollerplatine und das DSP-Board müssen miteinander kommunizieren können. Es bedarf also einer Schnittstelle, die beiden Kommunikationspartnern erlaubt miteinander Daten auszutauschen. Da der verwendete Mikrocontroller zwei serielle Schnittstellen beherbergt und das DSP-Board ebenfalls über zwei sogenannte McBSP’s (Multi Channel Buffered Serial Port) verfügt, entschieden wir uns für eine serielle Schnittstelle als Kommunikationskanal. Wir benutzen die „freie“ 2.McBSP (McBSP1), da die 1.McBSP (McBSP0) standardmäßig von dem auf dem DSP-Board integrierten ADC benutzt wird. Die McBSP’s des DSP sind synchrone serielle Schnittstellen, d.h. dass gleichzeitig Daten synchron in beide Richtungen über die Datenleitungen DX und DR gesendet und empfangen werden. Zur Synchronisation dienen zwei Taktsignale Daten-Clock(CLKX) und Frame-Sync(FSX). Alle Signale liegen als Leitungen bzw. Pins am Expansion Port des DSP-Board’s an und können somit leicht an den Mikrokontroller auf der Tochterkarte, die „huckepack“ auf dem DSP-Board aufgesetzt ist, geführt werden.
Bild 5.1.1 Blockschaltbild der McBSP-Schnittstelle (McBSP als Master oder als Slave) Exemplarisch als SPI-Konfiguration der Kommunikationspartner
5.2 SPI-Mode (Serial Peripheral Interface) der McBSPSchnittstelle. SPI ist ein standardisiertes Kommunikationsprotokoll bei synchronen seriellen Datenübertragungen. Hierbei ist ein Kommunikationspartner der Master und der andere der Slave, wobei der Master das Clock und das Frame-Sync Signal generiert und somit den Slave „taktet“. Wir entschieden uns, den Mikrocontroller als Master zu konfigurieren und somit den DSP als Slave zu benutzen.
Bild 5.2.1 Kommunikationskanal bzw. –leitungen zwischen DSP(Slave) und MC(Master)
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 15
Technische Universität Berlin
5.3 Kommunikationsablauf zwischen DSP und Mikrocontroller. Des weiteren benötigen wir eine weitere Signalleitung die es dem DSP (Slave) erlaubt, ein Sendewunsch dem Mikrocontroller (Master) anzuzeigen. Wir benutzten hierfür die Signalleitung CNTL0 auf dem DSPBoard, die bei steigender Flanke einen Interrupt am Mikrocontroller auslöst, so dass dieser die Kommunikation einleiten kann. Die Kommunikation zwischen DSP und Mikrocontroller läuft immer nach einem bestimmten Schema ab (siehe nachfolgendes Bild).
Bild 5.3.1: Kommunikationsablaufschema zwischen DSP und MC In diesem Ablaufschema sendet der DSP einen Befehl an den Mikrocontroller, dieser wiederum sendet nach der Verarbeitung ein Acknowledgment oder einen angeforderten Wert zurück. Im ersten Schritt wird das 16-bit Datenwort in den Sendebuffer des DSP geschrieben und danach wird durch einen Impuls auf der CNTL0-Leitung ein Interrupt am Mikrocontroller ausgelöst. Dieser schaltet nun die Clockleitung für die 16-Bit an und somit wird das Datenwort vom DSP zum MC übertragen. Nach der Befehls- bzw. Kommandoausführung sendet der Mikrocontroller ein ACK oder angeforderten Wert zurück. Dabei wird am Anfang der Übertragung die Frame-Sync Leitung (FSX) von High auf Low gesetzt, um somit dem DSP einen neuen Frame anzuzeigen, und wiederum wird durch 16 Takte auf der Clockleitung (CLKX) das Datenwort vom MC zum DSP gesendet. Am Ende der Übertragung wird die Frame-Sync Leitung (FSX) auf High gesetzt. Die Übertragung ist abgeschlossen und es kann ein neuer Befehl vom DSP aus gesendet werden.
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 16
Technische Universität Berlin
5.4 Datenprotokoll. Damit Daten, die zwischen zwei Kommunikationspartnern ausgetauscht werden, von beiden Seiten interpretiert werden können, müssen diese Daten in einem entsprechenden Format übermittelt werden. Somit ist ein sog. Datenprotokoll nötig, dass beide Kommunikationspartner verstehen (äquivalent einer Sprache bei der Kommunikation zwischen Menschen). Bei der Kommunikation zwischen dem DSP und dem Mikrocontroller setzen wir ein selbstdefiniertes Datenprotokoll ein. Dabei besteht ein Befehlsdatenwort des DSP bzw. Antwortdatenwort des MC aus 16 Bit (ein Frame). Die obersten 3 Bit charakterisieren den Befehl bzw. Kommando (z.B. set_LED, req_ADC, ...). Die darauffolgenden 3 Bit die, wenn für diesen Befehl nötige, Portnummer (z.B. bei req_ADC den zu lesenden ADC-Port) und die restlichen 10 Bit für notwendige Parameter (z.B. bei set_LED den anzuzeigenden Wert).
5.4.1 15
Übersicht.
14
13
12
CMD
11
10
9
8
7
6
[Port]*
5
4
3
2
1
0
[Parameter]*
Die Kommandos werden byteweise übetragen, dabei wird zuerst das High- und dann das Low-Byte übertragen. Beim DSP werden die Bytes gleich wordweise (16-Bit) empfangen. Der MC kann das leider nicht, da er nur ein 8 Bit Schieberegister in den USARTs hat. Da die Pinlogik des Eingangspins von USART0 (SOMI0)) auf dem Microntroller offensichtlich defekt war, wird jetzt auch auf dem Microcontroller wordweise gesendet und empfangen. Das passiert mit der Assemblerroutine sendSPIm (siehe Sourcecode)
MC DSP
CMD
Name
Beschreibung
0 0 0 0 1 1 2 3
NOP ACK NACK RESET TX_RS232 RX_RS232 SET_LED REQ_IGIO
no Operation
no params
acknowledge
no params
3 3 3 3 3
IN_IGIO INT_IGIO OUT_IGIO DIR_IGIO IE_IGIO
3 4
IES_IGIO REQ_GIO
4 4
IN_GIO DIR_GIO
4 5 5
OUT_GIO IN_ADC REQ_ADC
6
SET_PWM
get value of ADC input on Port GIO request ADC value, enables ADC port --> IN_ADC set params of PWM channel
7
FINE_PWM
set PWM fine mode without duration
DSP-Labor
SS 2003
↔ ↔ no acknowledge ↔ " resets MC " transmit byte to RS232 ! receive byte from RS232 " sets value on 7 segment LED display request transmission of IGIO input ---> " IN_IGIO get input from port IGIO
interrupt on port IGIO sets output register for port IGIO sets direction for port IGIO enables interrupts for port IGIO interrupt edge select for port IGIO request transmission of GIO input ---> IN_GIO get input from GIO sets direction for port GIO - disables ADCs! sets output register for port GIO
Gruppe: FrVo
! ! " " " " "
Parameter
no params no params byte to transmit received byte value (4Bit) dot (1Bit) no params input bitmask (10Bit) of IGIO interrupt flags (10Bit) of IGIO bitmask (10Bit) 0=L, 1=H bitmask (10Bit) 0=IN, 1=OUT bitmask (10Bit) 0=int disabled, 1=int enabled bitmask (10Bit) 0=(L->H),1= (H->L) no params
! "
input bitmask (8Bit) of GIO bitmask (8Bit) 0=IN, 1=OUT
" ! "
bitmask (8Bit) 0=L, 1=H
" "
portnumber (3Bit), value (12Bit) portnumber (3Bit), continous(1Bit) PWMport (2Bit), polarity(1Bit), speed(3Bit), duration (7Bit) PWMport (2Bit), polarity(1Bit), PWMval (10Bit)
Seite 17
Technische Universität Berlin
5.4.2
Allgemeine Befehle.
5.4.2.1
NOP
15
14
13
0
0
0
5.4.2.2
12
11
10
9
8
7
6
5
4
3
2
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
12
11
10
9
8
7
6
5
4
3
2
1
0
0
0
0
0
0
0
0
0
0
0
0
0
1
13
12
11
10
9
8
7
6
5
4
3
2
1
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
13
12
11
10
9
8
7
6
5
4
3
2
1
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
ACK
15
14
13
0
0
0
5.4.2.3
NACK
15
14
0
0
5.4.2.4
RESET
15
14
0
0
5.4.3
RS232 Kommunikation.
5.4.3.1
TX_RS232 DSP ! MC
15
14
13
0
0
1
12
11
10
9
8
7
6
5
4
3
2
1
0
-
-
-
-
-
b7
b6
b5
b4
b3
b2
b1
b0
b0..b7 ! Byte zum senden 5.4.3.2
RX_RS232 MC ! DSP
15
14
13
0
0
1
12
11
10
9
8
7
6
5
4
3
2
1
0
-
-
-
-
-
b7
b6
b5
b4
b3
b2
b1
b0
b0..b7 ! Byte, das empfangen wurde
5.4.4
LED-Display.
5.4.4.1
SET_LED
15
14
13
0
1
0
DSP ! MC
12
11
10
9
8
7
6
5
4
3
2
1
0
-
-
-
-
-
-
-
dp
b4
b3
b2
b1
b0
b0..b7 ! Ziffer, die Hexdezimal dargestellt werden soll dp ! Dezimalpunkt an oder aus
5.4.5
IGIO Port.
(noch nicht implementiert) 5.4.5.1
REQ_IGIO
15
14
13
0
0
1
12
11
10
9
8
7
6
5
4
3
2
1
0
1
1
1
-
-
-
-
-
-
-
-
-
-
fordert Eingangsregister an 5.4.5.2
IN_IGIO
15
14
13
0
1
1
12
11
10
9
8
7
6
5
4
3
2
1
0
0
0
0
b9
b8
b7
b6
b5
b4
b3
b2
b1
b0
Antwort auf REQ_IGIO b0..b9 ! Pegel an Anschluß IGIO 0 = 0V, 1 = 3.3 V
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 18
Technische Universität Berlin
5.4.5.3
INT_IGIO
15
14
13
0
1
1
12
11
10
9
8
7
6
5
4
3
2
1
0
0
0
1
b9
b8
b7
b6
b5
b4
b3
b2
b1
b0
Interrupt wurde durch IGIO Port ausgelöst b0..b9 ! Interruptflags 0 = kein Interrupt, 1 = Interrupt wurde ausgelöst dur Port Anschluß x von IGIO BEACHTE! : IE_IGIO muß für entsprechenden IGIO Anschluß auf 1 gesetzt sein 5.4.5.4
OUT_IGIO
15
14
13
0
1
1
12
11
10
9
8
7
6
5
4
3
2
1
0
0
1
0
b9
b8
b7
b6
b5
b4
b3
b2
b1
b0
Setze Ausgangsregister für Port IGIO b0..b9 ! Pegel, der gesetzt werden soll 0 = 0V, 1 = 3.3V BEACHTE!: DIR_IGIO muß für entsprechende Anschlüsse auf 1 gesetzt sein 5.4.5.5
DIR_IGIO
15
14
13
0
1
1
12
11
10
9
8
7
6
5
4
3
2
1
0
0
1
1
b9
b8
b7
b6
b5
b4
b3
b2
b1
b0
Setze Richtung (Ein-/Ausgang) für Port IGIO b0..b9 ! Richtung des entsprechenden Anschlusses 0 = Eingang, 1 = Ausgang 5.4.5.6
IE_IGIO
15
14
13
0
1
1
12
11
10
9
8
7
6
5
4
3
2
1
0
1
0
0
b9
b8
b7
b6
b5
b4
b3
b2
b1
b0
Erlaube Interrupts für entsprechenden Anschluß an Port IGIO 0 = kein Int. wird ausgelöst, 1 = Int. wird ausgelöst 5.4.5.7
IES_IGIO
15
14
13
0
1
1
12
11
10
9
8
7
6
5
4
3
2
1
0
1
0
1
b9
b8
b7
b6
b5
b4
b3
b2
b1
b0
Auswahl der Interruptflanke 0 = steigende Flanke (0V ! 3.3V), 1 = fallende Flanke (3.3V ! 0V)
5.4.6
GIO Port.
(noch nicht implementiert) 5.4.6.1
REQ_GIO
15
14
13
1
0
0
12
11
10
9
8
7
6
5
4
3
2
1
0
1
1
1
-
-
-
-
-
-
-
-
-
-
fordert Eingangsregister an 5.4.6.2
IN_GIO
15
14
13
1
0
0
12
11
10
9
8
7
6
5
4
3
2
1
0
0
0
0
-
-
b7
b6
b5
b4
b3
b2
b1
b0
Antwort auf REQ_GIO b0..b7 ! Pegel an Anschluß GIO 0 = 0V, 1 = 3.3 V
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 19
Technische Universität Berlin
5.4.6.3
DIR_GIO
15
14
13
1
0
0
12
11
10
9
8
7
6
5
4
3
2
1
0
0
1
1
-
-
b7
b6
b5
b4
b3
b2
b1
b0
Setze Richtung (Ein-/Ausgang) für Port GIO b0..b7 ! Richtung des entsprechenden Anschlusses 0 = Eingang, 1 = Ausgang 5.4.6.4
OUT_GIO
15
14
13
1
0
0
12
11
10
9
8
7
6
5
4
3
2
1
0
0
1
0
-
-
b7
b6
b5
b4
b3
b2
b1
b0
Setze Ausgangsregister für Port GIO b0..b7 ! Pegel, der gesetzt werden soll 0 = 0V, 1 = 3.3V BEACHTE!: DIR_GIO muß für entsprechende Anschlüsse auf 1 gesetzt sein
5.4.7
Analog Eingänge.
5.4.7.1
IN_ADC
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
1
0
1
p2
P1
p0
b9
b8
b7
b6
b5
b4
b3
b2
b1
b0
1
0
Antwort auf REQ_ADC b0 .. b9 Spannung an Eingang p0 .. p2 BEACHTE : Aus Zeitgründen (keine Zeit für richtige Impl. ;-(( ) jetzt noch so : 15 14 13 12 11 10 9 8 7 6 5 4 3 2 0
0
5.4.7.2
0
0
B11
b10
b9
b8
b7
b6
b5
b4
b3
b2
b1
b0
REQ_ADC
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
1
0
1
p2
P1
p0
-
-
-
-
-
-
-
-
-
-
Eingang p0..p2 an Port GIO auf ADC schalten, messen und Ergebnis senden
5.4.8
Pulsweiten modulierte Ausgänge.
5.4.8.1
SET_PWM
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
1
1
0
p1
p0
d
s1
s0
b7
b6
b5
b4
b3
b2
b1
b0
Schaltet PWM Ausgang für x * 10 ms ein p0 .. p1! Anschlußnummer d ! Polarität der Ausgangsspannung s0 .. s1 ! Geschwindigkeit (0 .. 3) b0 .. b7! Zeitspanne, die Ausgang aktiv bleibt in 10 ms 5.4.8.2
FINE_PWM
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
1
1
1
p1
p0
d
b9
b8
b7
b6
b5
b4
b3
b2
b1
b0
Schaltet PWM Ausgang dauerhaft ein p0 .. p1! Anschlußnummer d ! Polarität der Ausgangsspannung b0..b9 ! Ausgangsspannung
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 20
Technische Universität Berlin
Beispiel einer Kommunikation zwischen DSP und MC:
5.5 Initialisierung und Benutzung der McBSP. Um die McBSP-Schnittstelle benutzen zu können, muss diese zuerst initialisiert werden. Des weiteren benötigt man sogenannte Schreib- und Lesefunktionen. Bei der Initialisierung gibt es zwei Wege im Code Composer Studio. Der erste Weg ist die Initialisierung mit Hilfe des BIOS. Dabei kann man im GUI des CC die entsprechende McBSP „enablen“ und durch ein sog. Config-File konfigurieren.
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 21
Technische Universität Berlin
Nach Abschluss der Einstellungen im Bios-GUI werden zwei Dateien (xxx.c und xxx.h) generiert, die nun die nötige Initialisierungsroutine enthält. Der zweite Weg ist die Initialisierung per Hand bzw. zu Fuß. Dadurch braucht kein BIOS erzeugt werden. Dabei muss ein sog. McBSP-Handle erzeugt werden. Des weiteren eine Konfigurationsstruktur mit den Registereinstellungen (Tip: Diese Registereinstellungen kann man sich auch mit dem BIOS-GUI erzeugen. Stehen in der Kartei-Karte „Advanced“, spart Zeit sich die richtigen Stellen in den Registern herauszusuchen! # siehe Abbildung!!!). Das McBSP-Handle kann nun mit den Einstellungen der Konfigurationsstruktur geöffnet werden.
< Auszug aus der Datei msp430.c > #include #include #include #include
"msp430.h"
/*----------------------------------------------------------------------------*/ /* create a config structure for SPI Slave mode */ static MCBSP_Config ConfigSPI = { ..0x02001000, /* SPCR */ ..0x00000040, /* RCR */ ..0x00000040, /* XCR */ ..0x20000000, /* SRGR */ ..0x00000000, /* MCR */ ..0x00000000, /* RCER */ ..0x00000000, /* XCER */ ..0x0000000E, /* PCR */ };
MCBSP_Handle hMcbsp; CSL_init(); hMcbsp = MCBSP_open(MCBSP_DEV1, MCBSP_OPEN_RESET); MCBSP_config(hMcbsp,&ConfigSPI); MCBSP_enableSrgr(hMcbsp); MCBSP_enableRcv(hMcbsp); MCBSP_enableXmt(hMcbsp);
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 22
Technische Universität Berlin
Wir haben den zweiten Weg also Initialisierung per Hand eingeschlagen, da mit dem BIOS Probleme in der Stabilität des Systems bestanden (Absturz der Kommunikation zwischen DSP-Board und PC häuften sich). Nach der Initialisierung der McBSP-Schnittstelle kann diese nun mit den Funktionen MCBSP_write(hMcbsp, val); MCBSP_read (hMcbsp); aus der CSL (Chip Support Library) angesprochen werden. Da für wie schon im vorangegangenen Kapitel erläutert wurde ein festes Kommunikationsschema zwischen DSP und Mikrocontroller haben, benötigten wir eine Funktion für das Senden eines Befehls an den MC und warten auf die Rückantwort. Diese Funktion sieht nun folgendermaßen aus: < Auszug aus der Datei msp430.c > unsigned short MSP430write (unsigned short val) { unsigned short result=0; unsigned short counter = 4; if (!msp430IsInitialized) initMSP430DB (); // Falls nötig MCBSP und MSP430 initialisieren while (!MCBSP_xrdy(hMcbsp)); // warten bis letztes Senden zu Ende ist MCBSP_write(hMcbsp, val); // neuen Befehl ins Senderegister schreiben setCNTL0 (0); // Interrupt auf MSP430 auslösen setCNTL0 (1); // um Übertragung zu starten setCNTL0 (0); while (!MCBSP_xrdy(hMcbsp)); // warten bis NOP wieder ins TX Reg geschrieben werden kann MCBSP_write(hMcbsp, 0); // wenn TX Reg nicht geladen wird, wird der letzte eingetragene // Wert übertragen --> sollte immer NOP sein while (result == 0 && counter) { while (!MCBSP_rrdy(hMcbsp)); // warten auf NOP (wird zum lesen benutzt) result = MCBSP_read (hMcbsp); counter--; } return result; }
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 23
Technische Universität Berlin
6 Kommunikation zwischen DSP-Board und Kameraboard. Zur Kommunikation zwischen dem DSP und Kameraboard wird das I2C Protokoll benutzt. Dies ist ein serielles Busprotokoll, das über zwei Signalleitungen (SDL und SCL) ausgeführt wird mit bis zu 100 kbits/sek. Wobei die SCL Leitung den asynchronen Takt zum Datenübernehmen liefert. Dieses Protokoll wurde bereits von einer der Vorgängergruppen entwickelt. Daher soll es an dieser Stelle nicht weiter betrachtet werden. Zum Verständnis und Einarbeitung sei genaueres studieren der Abschlussberichte von den vorangegangenen Projekten empfohlen.
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 24
Technische Universität Berlin
7 Focus. 7.1 Einleitung. Man versteht unter Bildschärfe, die Fähigkeit, kleine Details einer photographischen Schicht noch getrennt wiederzugeben. Ein Maß für die Schärfeleistung einer Schicht ist das "Auflösungsvermögen". Es ist definiert als die Anzahl der Linienpaare, die von einer Schicht noch getrennt wiedergegeben werden. Zur Schärfebestimmung könnte ein unkomplizierter Ansatz der örtlichen Ableitung in Betracht gezogen werden. Hierbei summiert man dann einfach die Beträge der örtlichen Ableitungen. Eine weitaus effektivere Lösung bietet die Analyse des Amplitudendichtespektrums einer örtlich frequenzabhängigen Transformation. Da sich ein scharfes Bild vor allem durch den Gehalt an hohen Frequenzen auszeichnet, können über einen Vergleich der Transformationskoeffizienten leicht Aussagen über die Bildschärfe gemacht werden.
7.2 Bildschärfebestimmung. Zur Bearbeitung werden nur skalierte Bilder benutzt (160*120 Pixel), damit wird das Eingangsbild auf 1/16 der Originalgröße reduziert. Um die Intensität der hochfrequenten Anteile über das Betragsspektrum zu bestimmen, wird eine zweidimensionale FFT über das gesamte aufgenommene Bild implementiert. Die Implementierung des FFT Algorithmus wäre sicherlich nicht schwer gewesen, jedoch hätte sich ein vergleichsweise hoher Rechenaufwand ergeben, bedingt vor allem durch viele Fließkommaoperationen in nicht optimalem Code. Eine andere Variante um die Intensität der hochfrequenten Anteile über das Betragsspektrum zu bestimmen, wäre die Transformation mit diskreter Cosinus-Transformation (DCT).
7.2.1
Transformation mit DCT.
Unter Transformation versteht man die Konvertierung der einzelnen Grauwerte der Pixel einer Zeile, welche eine Kurve mit diskreten Werten beschreiben in einen anderen Raum. Bei Bildformaten wird vor allem die diskrete Cosinus-Transformation angewendet, die die Farbwerte dann als eine Überlagerung von Cosinus-Wellen darstellt. Diese Abbildung ist bijektiv. Man kann also aus den DCT-Koeffizienten die ursprünglichen Pixelgrauwerte ohne Verlust zurückrechnen. Zur Transformation wird das skaliertes Bild zuerst in 8x8 Blöcke zerlegt, auf die dann die DCT angewendet wird (sieh Bild 7.2.1.1).
Bild 7.2.1.1 Zerlegung des Eingangsbildes (160*120) in 8*8 Blöcke
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 25
Technische Universität Berlin
Ein solcher Block wird nun als Vektor, bestehend aus 64 Pixelwerten, den Koeffizienten, eines geeigneten Vektorraums interpretiert. Die DCT vollzieht nun einen Basiswechsel.
Bild 7.2.1.2 Ein 8*8 Block Die Transformation im Zweidimensionalen wird durch folgende Formel, die 2D-DCT, erreicht, deren Laufzeit auch durch eine Zerlegung des Bildes in Blöcke begünstigt wird:
Man kann sich diese Hintransformation (FDCT) als einen harmonischen Zurücktransformation (IDCT) als eine harmonische Synthese vorstellen.
Analysator
und
die
Nachfolgend sind die Basisbilder dargestellt, die aus der Formel der 2D-DCT resultieren. Die Basisbilder bestehen jeweils aus kosinusförmigen Helligkeitsverläufen mit der horizontalen Frequenz und vertikalen Frequenz .
Bild 7.2.1.3. Ausschnitt aus der Matrix von DCT- Basisbildern für N=8*8
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 26
Technische Universität Berlin
Vorteil der Benutzung der DCT Funktion ist, dass sie schon als Bibliotheksfunktion existiert. Diese Funktion fdct_8x8 erwartet als Bilddatenargumente short-Werte, was eine Umwandlung unseres nur halb so großen Formats unsigned char erfordert. Die Bibliotheksfunktion benutzt für die Berechnung der Transformationskoeffizienten den schnellen Chen-Algorithmus.
7.2.2
Auswertung der Transformationsdaten.
Um einen verlässlichen Wert für die Bildschärfe zu erhalten, werden die Beträge der relevanten Transformationskoeffizienten aufsummiert, Phaseninformationen sind ja nicht von Belang. Der optimale Bereich hierfür wurde durch Tests ermittelt, die zum Ziel hatten, eine bestmögliche Unterscheidbarkeit von scharfen und unscharfen Bildern zu liefern. Die Summation wird dann über alle 20*15= 300 berechneten Transformationsmatrizen ausgeführt. Folgendes Bild zeigt den von uns verwendeten Koeffizientenbereich:
Bild 7.2.2.1 Summationsbereiche in den DCT- Koeffizientenmatrizen Die niederfrequenten Anteile werden selbstverständlich nicht in die Auswertung mit einbezogen. Die sehr hochfrequenten Bereiche werden ebenfalls ausgelassen, da die entsprechenden Beträge sehr klein sind und sich eher in den Bereich von möglichen Bildstörungen einordnen lassen.
7.2.3
Ergebnisse.
Nach der Datenumstrukturierung, wird das Bild mit der Bibliotheksfunktion transformiert. Dann folgt die partielle Summation über die 300 DCT Blöcke. Der erhaltene Summenbetrag wird durch die Bildgröße dividiert und zurückgegeben. Nachfolgend sind die Beispielbilder und die zugehörigen Bildschärfe Wert dargestellt (sieh Bild 7.2.3.1.) Die Bilder sind mit verschiedene Schärfeeinstellung aufgenommen.
Sharpness=123,11
Sharpness=105,12
Sharpness=78,35
Sharpness=45,78
Bild 7.2.3.1 Ergebnisse der berechneten Schärfe
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 27
Technische Universität Berlin
Mit solchen Algorithmus kann man scharfe und unscharfe Bilder vergleichen. Die Bilder mit größten Schärfewerten sind am schärfsten, weil für das scharfe Bild die Koeffizienten höherer Ordnung wesentlich stärker ausgeprägt sind, was auf das Vorhandensein von entsprechenden höher frequenten Strukturen hinweist.
7.3 Bestimmung des schärfsten Bildes. Um das schärfste Bild zu bestimmen, wird im Hauptprogramm das Verfahren (Bild 7.3.1) verwendet:
Bild 7.3.1 Blockschaltbild 1
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 28
Technische Universität Berlin
7.3.1
Beschreibung des Algorithmus. • • • • • • •
Beim Start des Systems wird ein Bild (Initial Bild) aufgenommen. Mittels Sharpness Funktion wird Schärfe bestimmt Der Motor wird vorwärts oder rückwärts angesteuert Nehmen wir an, dass der Motor vorwärts (ein Schritt). Neues Bild wird aufgenommen. Die Sharpness des Bildes wird erneut bestimmt. Die beiden Sharpness Werte werden verglichen.
1 Fall (neu Sharpness ist größer) • • • •
Neu Sharpness wird als alt Sharpness gespeichert. Motor wird wieder ein Schritt vorwärts angesteuert. Bild wird aufgenommen. Sharpness wird bestimmt und mit dem alten Wert verglichen
Diese Routine wird wiederholt, bis neu Sharpness kleiner als alt Sharpness ist. In diesem Fall wird der Motor ein Schritt rückwärts angesteuert. An dieser Position des Motors, wird das Bild als Scharfbild angenommen. 2 Fall (alt Sharpness ist größer) • • • •
7.3.2
Der Motor wird zwei Schritte rückwärts angesteuert. Bild wird aufgenommen. Sharpness wird bestimmt und mit dem alten Wert verglichen Wenn neu Sharpness größer ist, dann wird der Motor ein Schritt rückwärts angesteuert
Anmerkungen.
Im Bereich, wo die Bilder nicht scharf sind, sind die Sharpness_Werte sehr klein und liegen nah zueinander. Wenn der Focusmotor sich in diesem Bereich befindet besteht die Gefahr das sich der Motor „auf der Stelle“ bewegt, da die Steigung der Schärfekurve nicht Monoton ist. Der neu berechnete Wert kann durch aus kleiner sein, als der vorherige, was dazu führen könnte, dass der Motor entgegengesetzt zum Schärfebereich dreht und immer wieder pendelt, bzw. falschen Wert als scharf annimmt.
Bild 7.3.2.1 Berechnete Sharpness Aufgrund der Fehlentscheidung, kam diese Variante des Algorithmus für uns nicht in Frage.
7.3.3
Zweite Variante.
Um sicher zu stellen, dass der Motor gestoppt wird, nur wenn das scharfe Bild ermittelt wurde, haben wir andere Variante des Algorithmus erstellt (siehe Blockschaltbild 2 im Bild 7.3.3.1). Der Unterschied zwischen den beiden Algorithmen besteht darin, dass beim Starten der Motor in der zweiten Variante initialisiert werden muss, d.h. die Richtung wird auf rückwärts gesetzt (Zoom ganz Vorn), und die Schrittweite wird mit konstanter Größe festgelegt.
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 29
Technische Universität Berlin
Nach der Initialisierung, wird der Motor mit konstanter Schrittweite zurück angesteuert, und die Sharpness ermittelt. Der Motor wechselt die Richtung nur wenn die aktuelle Sharpness kleiner als die vorherige Sharpness plus eine Konstante ist. Ausserdem wid dann die Schrittweite halbiert. Die Motorsteuerung, die Bildaufnahme und die Berechnung der Sharpness bleiben in einer Schleife, bis die Schrittweite gleich Null ist. Dann wird das scharfe Bild gefunden.
Bild 7.3.3.1 Blockschaltbild 2
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 30
Technische Universität Berlin
8 Fortsetzung folgt – Probleme, Ideen und Lösungen für Nachfolgeprojekte. Ein sehr großes Problem bei der Lösung unserer Aufgabe, ein Kamerabild scharf zu stellen, ist die Zeit, die dafür benötigt wird. Wir haben festgestellt, dass sehr viel Zeit für die Aufnahme eines Bildes benötigt wird. Deshalb könnte man durch Veränderungen an der Videoplatine, den Algorithmus sehr viel beschleunigen. Man müsste durch entsprechende Logik (die sehr einfach sein müsste), die FIFOs automatisch enablen, so dass immer genau ein Bild aufgenommen wird. Wenn es im FIFO ist, muss ein Interrupt ausgelöst werden, der dann den EDMA initialisiert. Dieser könnte dann das Bild in einen Buffer laden und dabei gleich die Bytes auf Words erweitern und den Zeilenversatz auflösen. Somit würde der DSP nur noch die Aufnahme anstoßen und wäre dann frei, um die Schärfe des Bildes davor zu berechnen. Für diesen Ansatz müssen natürlich zwei Buffer genutzt werden. Ein weiterer Ansatz, das Verfahren zu beschleunigen, ist die Kommunikation mit den MC durch Interrupts zu implementieren und entsprechend Buffer einzusetzen, damit der DSP nicht immer auf die Beendigung eines Befehls warten muss. Ein sehr wichtiger und entscheidender Punkt ist die Befestigung des Videomoduls an dem Objektiv. Diese muss dahingehend verbessert werden, dass das Modul dichter an das Objektiv heran kommt. Dadurch hat das Objektiv nicht mehr so starke Makroeigenschaften und vielleicht lässt sich dann auch der echte Fokus zur Scharfstellung nutzen. Dieser hat einen sehr viel kürzeren Bewegungsraum und kann somit schneller angesteuert werden. Vorschlag zur Befestigung des Moduls am Objektiv: Man muss das nebenstehende Formteil aus ca. 0,51mm dickem Blech fertigen. Zu beachten ist, dass die zwei kleinen Bohrungen in der Mitte mit M2 Innengewinde zu versehen sind. Alternativ kann bei Messing oder Kupferblech auch eine Mutter angelötet werden. Dann wird dieses Passstück an dem Objektiv festgeschraubt. danach entfern man vom Kameramodul den runden Aufsatz auf dem CCD durch lösen der beiden Befestigungsschrauben. Dann sollte das Modul mit zwei M2 Schrauben von hinten durch auf dem Passstück festgeschraubt werden. Ich hoffe, dass dann der CCD dicht genug an das Objektiv herankommt, um eine ordentliche Scharfstellung mittels Fokus zu ermöglichen.
Alle Angaben in mm
Μ2,0
∅10,0
4,4
4,4 8,0 15,0 30,0
15,0 30,0
∅2,5
Es besteht auch Bedarf die Videobearbeitungsdateien nachzubessern. Um Vollbildaufnahmefähigkeit zu behalten haben wir zunächst die vorhandenen Dateien um die Bildskalierung nur erweitert und später aus Zeitmangel nicht mehr korrigiert. Es ergeben sich zwar dadurch keine Geschwindigkeitsnachteile aber der Code ist schwer lesbar und einige Stellen weisen „unschöne“ Lösungen auf. Hier noch ein paar nicht weiter ausformulierte Ideen als Stichpunkte: - nur einen kleinen Teil des Bildes betrachten (Ausschnitt) und nur wenn hier kein befriedigender Schärfewert ermittelt wird (weil nur Pupille sichtbar), dann Ausschnitt vergrößern - paralleles Abarbeiten - während das alte Bild noch ausgewertet wird, fährt der Motor schon in die (vermutlich) nächste Position - eine Schärfezunahme-Kurve berücksichtigen, um die Schrittweite des Motors "intelligent" zu setzen (z.B. drei aufeinanderfolgende Bilder auswerten)
DSP-Labor
SS 2003
Gruppe: FrVo
Seite 31
