Home

Diplomarbeit - Fachhochschule Brandenburg

1. Testbeschreibung Ergebnis Sichtpriifung Setzen des Eingabekanals 0 OK OK Read YUV 360x288 OK OK Read RGB24 720x756 OK OK Mmap RGB24 360x288 OK OK Mmap RGB24 720x576 OK OK Overlay RGB24 320x288 OK OK Test mit 2 Eingabekan len xvtmmap two OK OK loop Setzen des Eingabekanals 2 vctrl i 3 OK OK Setzen des Eingabekanals 3 vctrl i 3 OK OK Setzen eines nicht definierten Farbformates OK nicht durch vetrl d 15 gef hrt Setzen einer nicht definierten Bildgr e OK nicht durch 640x480 gef hrt Auslesen der Controls vetrl l OK nicht durch gef hrt Setzen der Helligkeit vetrl b 255 OK OK Setzen der Helligkeit vetrl b 0 OK OK Setzen des Kontrasts vetrl c 0 OK OK Setzen des Kontrasts vetrl c 128 OK OK Setzen der Farbe vctrl h 0 OK OK Setzen der Farbe vctrl h 64 OK OK Setzen der S ttigung vetrl s 0 OK OK Setzen der S ttigung vetrl s 64 OK OK 126 C 3 Wellenformsimulation 127 Seite austauschen 128 C 4 Langzeittests 129 Seite austauschen 130 Seite austauschen 131 Seite austauschen 132 Seite austauschen 133 Anhang D CD Inhalt Verzeichnis driver src fgpa src testing tools literatur fpga test Inhalt Treiberquelltexte Hardwaresourcen der FPGA Programmierung Testprogramme die auf dem Lartboard lauff hig sind Den Programmen liegt der Sourcecode bei Beispielprogramme f
2. unsigned long BUFSIZE 1 106 fb_out_align char unsigned long fb_out BUFSIZE 1 amp unsigned long BUFSIZE 1 else 90 fb_in_align fb_in fb_out_align fb_out How many frames to test the number of entries in frames 4 for j 0 j lt sizeof frames sizeof struct frame j height width bytes per pixel framesize 100 frames j height frames j width frames j colorbytes frame will copied in blocks of BUFFSIZE buffs_for_frame framesize BUFSIZE get time before work cll clock for k 0 k lt FRAMES_PER_SECOND SECONDS k bufinent fb_in_align 110 bufoutent fb_out_align for i 0 i lt buffs_for_frame i ifdef ARM_LINUX if asmepy asm volatile align 4 stmfd sp rO r11 push register r0 r11 ldr r0 0 rO wordbufin 120 ldr ri 1 ri wordbufout mov r3 32 1024 4 Bytes 8 words copy LDMIA rot r4 r11 read 8 words to register STMIA r1 r4 r11 write 8 words to memory SUBS r3 r3 1 dec r3 BNE copy loop if r3 not 0 ldmfd sp rO r11 pop register r0 r11 m bufincnt m bufoutcnt 130 else memcpy bufoutent bufincnt BUFSIZE 107 else endif memcpy bufoutent bufincnt BUFSIZE bufoutent BUFSIZE bufincnt BUFSIZE get time after work cl2 clock time of work in se
3. 5 3 1 DMA Modul 4 non Sana ana BR 5 3 2 Adressgenerator zu ass rare 5 3 3 Datenpuffer 2 24 bee san 2 aaa 2 a 5 3 4 Videoeingabe lt lt V er rg mer ae di 532 Videoausgabe a cae ee AR naeh 5 3 6 StrongARM Interface 2 22 2222er 54 Ger letreiber 4 coe 184 dan ae ehe ehe 54 1 Framebuffer 666 2 bbe ze 8 su u EEN 5 4 2 VideodLin x i264 24 20 2 0m n Eu He we 543 PC Treiber ak be eh tn oe oe doe eo 5 5 Testverfahren ee Be dee pee ee ee ee Implentierung 6 b PGP s e Zi oe eee ee Oba ee eee Os hee 6 1 1 Das DMA Modul 4 a 4 ua 0 2 u EN aaa aa a 6 1 2 Wandlung der Farbbereiche 6 1 3 Austastrahmen f r die Videoausgabe 6 1 4 GCompilerprobleme 2 2 22 8 2220 e EE 6 2 Ger tetreiber 4 4 440 amp oR ara ea 6 2 1 Framebuffer a ek os hom a ee are E eg 622 Videos Heu 2 2 208 2d wann ew an ew e 6 2 3 PC Treiber tege ee ae ee 6 3 Schnittstellen zu Applikationen 6 4 Nachweis der Funktionalit t Zusammenfassung und Ausblick Analyse A 1 berpr fung der Speichertransferleistung A 1 1 A 1 2 A 1 3 A 1 4 bertragung mit memepy bertragung mit asmepy e Speicheradressen b ndig Das Programm mem2mem 95 59 58 60 60 63 65 66 66 68 70 73 73 74 76 76 78 79 81 sl 81 84 86 87 87 88 90 93 94 95 B Listings 109 B 1 AHDL Quelleode 2 4
4. chers f r einen Frame Abbildung 3 5 Overlay mit Clip Abbildung 3 4 einfaches Overlay ping oder Chromakey Eine weitere Methode ist das Einblenden des Videobildes der Grafikkarte F r diese Methode gibt es je nach Hardware verschiedene Ans tze Beim Overlaying Verfahren berlagert die Grafikkartenhardware das Videobild aus dem Video4Linux Treiber bei der Videoausgabe Overlaying muss von der Grafikkarte unterst tzt werden Der Speicher der Grafikkarte kann auch an den Video4Linux Treiber bergeben werden Die Videograbberhardware schreibt die Daten dann di rekt in den Grafikkartenspeicher Hier muss die entsprechende Funktionalit t durch den Video4Linux Treiber oder die Videohardware gestellt werden Bei der einfachen Variante des Overlaying bleibt das Videobild immer im Vordergrund Abbildung 3 4 Es existieren Erweiterungen das Videobild von anderen GUI Fenstern berlagern zu lassen Abbildung 3 5 ol Clipping definiert ber eine Liste von Rechtecken Bereiche die durch das Video nicht berschrieben werden d rfen Chromakey definiert den transparenten Bereich mit einer festgelegten Farbe Dieses Verfahren kommt aus der Videotechnik Die Videotechnik be vorzugt als Farbe ein kr ftiges Blau In der Computertechnik hat sich ein grelles Purpur durchgesetzt Abbildung 3 6 Chromakey Verfah Abbildung 3 7 Clipping um die ren die Farbe definiert den trans angegebenen Bereiche herum wird parenten Bereich das Bild
5. gt count gt MAX_CAPTURE_BUFFERS req gt count MAX_CAPTURE_BUFFERS type V4L2_BUF_TYPE_CAPTURE The buffer length needs to be a multiple of the page size buflen dev gt clientfmt sizeimage PAGE_SIZE 1 amp PAGE_SIZE 1 if req gt count buflen gt dev gt map size req gt count dev gt map_size buflen 30 for i 0 i lt req gt count i dev gt stream_buf i requested 1 dev gt stream_buf i vidbuf index i dev gt stream_buf i vidbuf type type dev gt stream_buf i map_dma dev gt map_dma i buflen offset must be unique for each buffer and a multiple of PAGE_SIZE on 2 4 2 dev gt stream_buf i vidbuf offset PAGE_SIZE i 1 dev gt stream_buf i vidbuf length buflen 40 dev gt stream_buf i vidbuf bytesused 0 120 dev gt stream_buf i vidbuf flags 0 dev gt stream_buf i vidbuf timestamp 0 dev gt stream_buf i vidbuf sequence 0 memset amp dev gt stream_buf i vidbuf timecode 0 sizeof struct v4l2_timecode we calc here the fpga register so we are faster while interrupt dev gt stream_buf i dadrso dev gt stream_buf i map_dma 50 dev gt stream_buf i dadre dev gt stream_buf i map_dma dev gt clientfmt height dev gt clientfmt bytesperline if dev gt clientfmt height 288 dev gt stream_buf i dadrse dev gt stream_buf i map_dma l
6. Techniken der farbsegmentierung Technical report Technischen Fakult t der Universit t Bielefeld 2000 http www kaihuebner de RoboCup main htm 135 Int98 Intel Intel StrongARM SA 1100 Multimedia Development Board with Companion SA 1101 Development Board 1998 http developer intel com Int99 Intel Intel Strong ARM SA 1100 Microprocessor Developer s Manual 1999 http www lart tudelft n1 278088 pdf Int00a Intel Intel StrongARM SA 1100 Microprocessor Specification Update 2000 http www lart tudelft nl 27810525 pdf Int00b Intel Memory to Memory Trans fer using the SA 1100 DMA 2000 http www intel com design strong applnots mem2mem pdf Jac96 Keith Jack Video Demystified A Handbook for the Digital En geneer Harris Semiconductors Virginia second edition edition 1996 Ker02 Kernelnewbies org 2002 http www kernelnewbies org Kno02 Gerd Knorr video4linux hq 2002 http bytesex org v4l KS02 Guido Kuhlmann and Frank Schwanz LART Video Hardware amp Programmable Logic Manual Tigris Elektronik GmbH Berlin 2002 Lar00 The schematics for revision 4 of the LART main board 2000 http www lart tudelft nl lartware plint Lart rev 4 pdf LARak LARTware Mainboard 2000 http www lart tudelft nl lartware plint Mar99 Kevin Van Maren The fluke device driver framework master s thesis Master s thesis Univerity of Utha 1999 NEC97 NEC Datasheet MO
7. gt encaddr LARTVIO_ENCC ENCC_RESET par gt encaddr LARTVIO_ENCC amp ENCC_CLOCK_ENABLE ENCC_LOGIC_ENABLE else enable and reset encoder par gt encaddr LARTVIO_ENCC ENCC_LOGIC_ENABLE 40 ENCC_RESET ENCC_CLOCK_ENABLE udelay 1000 par gt encaddr LARTVIO_ENCC amp ENCC_RESET udelay 1000 we reseted the encoder so we need to init it again par gt adv gt driver gt command par gt adv ADV7170_INIT amp arg arg VIDEO_MODE_PAL 50 par gt adv gt driver gt command par gt adv SET_VIDEO_NORM amp arg par gt adv gt driver gt command par gt adv ENABLE_OUTPUT amp nblank if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 return 0 endif 119 B 3 Ausz ge aus lartvio_vin c Video4Linux2 Treiber B 3 1 Die Funktion mmap_request_buffers ER 2 mmap_request_buffers setup streaming buffers it trys to setup reg gt count buffers 7 but if no such many buffers available it change reg gt count dev device structure a req request structure v4l2_requestbuffers Returns 1 success 0 failed 10 static int mmap_request_buffers struct capture_device dev struct v4l2_requestbuffers req int i lineoffset u32 buflen u32 type if dev stream_buffers_mapped return 0 can t make requests if buffers are mapped if req gt count lt 1 20 req gt count 1 if req
8. lt bei Framebuffer 45 treibern jede Graphikkarte eine eigene Minor Nummer Der Bereich beider Nummern l uft von 0 bis 255 Seit der Kernelversion 2 4 k nnen diese Eintr ge beim Laden des jeweili gen Treibers durch das Modul devFS erzeugt werden Bei der Standardinstal lation des LART Boards ist diese Option deaktiviert Die Eintr ge m ssen manuell mit dem Programm mknod angelegt werden F r den ersten Frame buffer w re der Eintrag dev fb0 mit der Major Nummer 29 und der Minor Nummer 0 anzulegen Ymknod dev fbO c 29 0 Die Option c weist auf ein Zeichenger t hin F r Blockger te muss die Option b angegeben werden Ger tetreiber werden in zwei Grundklassen ein geteilt Zeichenger te arbeiten mit einem Zeichenstrom Die Daten werden sequenti ell gelesen oder geschrieben Der Zugriff auf solche Ger te erfolgt ber die Systemaufrufe open close read und write Ein Beispiel f r ein Zei chenger t ist der Consoletreiber Die unterst tzten Operationen und deren Einsprungspunkte werden mit der Struktur file_operations defi niert Der Treiber bergibt diese Struktur mit der Registrierung an den Kernel Blockger te arbeiten hnlich den Zeichenger ten verarbeiten jedoch Bl cke fester Gr sse Typische Blockgr ssen sind Zweierpotenzen von 512 bis 64536 Die Bl cke k nnen hnlich dem Zeichenger ten gelesen und ge schrieben werden Jeder Block kann dabei adressiert werden Daf r steht der Systemaufruf seek
9. r die Erstprogrammierung des Bootloa ders Desweiteren erm glicht es den Zugriff auf andere periphere Elemente zur Laufzeit wie zum Beispiel auf den DRAM Bereich unter Umgehung des laufenden Betriebsystems Der High Speed Connector Der 100 polige High Speed Connector enth lt Adress Daten und Steuer leitungen f r den Zugriff auf ROM und DRAM Bereiche Desweiteren sind einige General Purpose I O Pins verf gbar die in Abschnitt 2 2 2 beschrie ben werden Da ber den High Speed Connector das LartVio mit dem LART Board verbunden wird werden die Signale detailliert aufgef hrt e alle prozessorexternen Adressleitungen A0 A25 e die Datenleitungen D0 D32 e DRAM Steuerleitungen nRASO nRAS3 e Byteauswahlleitungen nCASO nCAS3 e ROM Steuerleitungen nCS2 und nCS3 e Read und Write Signalleitung e die General Purpose I O Pins GP21 GP27 e sowie Signale zur Ansteuerung von PCMCIA Geraten 2 2 2 Prozessor Das Herz des Lart Boards ist der StrongARM SA1100 Es handelt sich da bei um einen Microcontroller f r Embedded Ger te Abbildung 2 3 zeigt ein Blockschaltbild des Prozessors Neben der zentralen Verarbeitungseinheit in tegriert der Microcontroller unter anderem mehrere serielle Schnittstellen 16 einen LCD Controller und digitale Ein Ausgabeports Die internen Peri pheriemodule werden durch zwei DMA Controller unterstiitzt Die DMA Controller untersttitzten nur interne Peripheriemodule Zum Kopieren von Speicherbereichen
10. r die Verwendung des LartVIO Den Programmen liegt der Sourcecode bei Literatur aus dem Literaturverzeichnis sofern Sie aus dem Internet geladen wurde Wellenformsimulationen der FPGA Module 134 Literaturverzeichnis A1t01 Ana01 ARMO1 BBD 01 BH02 BHK96 Dir02 H b00 Altera Coorperation ACEX 1K Programmable Logic Device Fa mily 2001 http www altera com literature ds acex pdf Analog Devices Inc Digital PAL NTSC Vi deo Encoder with 10 Bit SSAF and Advan ced Power Management ADV7170 ADV7171 2001 http www analogdevices com productSelection pdf ADV7170_1_a pdf ARM Limited ARM Developer Suite Version 1 2 Assemb ler Guide 2001 http www arm com support 574F KU FILE ADS_AssemblerGuide_B pdf Michael Beck Harald B hme Mirko Dziadzka Ulrich Kunitz Ro bert Magnus Claus Schr ter and Dirk Verworner Linux Ker nelprogrammierung Algorithmen und Strukturen der Version 2 4 Addison Weslay Verlag 2001 Ingo Boersch and Prof Dr Joachim Heinsohn Pro jekt R Cube Initiative las Intelligente Autono me Systeme Technical report Fachhochschule Bran denburg 2002 http ots fh brandenburg de mod php mod userpage amp menu 1301 amp page_id 6 Klaus Beuth Richard Hanebuth and G nter Kurz Nachrichten technik Elektronik 7 Vogel Verlag und Druck GmbH W rzburg 1996 Bill Dirks Video for linux two 2002 http www thedirks org v4l2 Kai H bner
11. tpusrar trop tosg n 1 typo trp 2 1 wobei n die Anzahl der Spaltenzugriffe innerhalb eines Burstzyklus sind F r die Auffrischung der DRAM Speicherzellen sind 4096 Refreshzyklen innerhalb von 64 ms notwendig 64000 Zyklen s Ein RAS before CAS Zy klus ist 89 ns tosr trc NEC97 lang 5 696 ms pro Sekunde werden demnach f r die Auffrischung der DRAM Speicherzellen ben tigt In dieser Zeit steht der Bus f r die Daten bertragungen nicht zur Verf gung Abz glich der Zeit f r Refreshzyklen sind 1s 5 696 x 1073s 11 836 952 84 x 10 9s einfache Schreib Lesezugiffe m glich Die Daten bertragungsleistung liegt bei Zugriffe xa Bytes Zugriff Der SA 1100 unterst tzt Burstzugriffe bei DMA Operationen sowie beim F llen und Leeren der Cacheline mit 4 und 8 Spaltenzugriffen in einem Burst Ein Burst of Eight ben tigt P 45 15M Byte s 11 836 952 11ns 38ns 8 1 20ns 30ns 219ns In der theoretisch freien Buszeit sind 4 540 200 Burstzyklen innerhalb einer Sekunde m glich Das entspricht einer maximalen Datentransferleistung von 138 MByte s Werden Burst of four f r den Speicherzugriff genutzt sinkt die bertragungsleistung auf 109 MByte s Der Prozessor arbeitet synchron mit dem Prozessortakt mit 221MHz 7 Der Bustakt betr gt jeweils CPUTakt 2 also 110 5 Mhz Ein Bustakt ist 9 05 ns lang Die DRAM B nke werden in den StrongARM Registern MDCNFG und MDCASO MDCAS3
12. 1100 kann theoretisch mit 400 MBit s Da ten vom und zum Prozessor bertragen wenn pro Bustakt ein 32 Bitwort gelesen wird M glich ist diese Geschwindigkeit mit entsprechenden SRAM Bausteinen und PCMCIA Ger ten die in einem Bustakt addressiert und ein 32 Bit Datenwort lesen oder schreiben k nnen Doch mit welcher Ge schwindigkeit kann der verbaute DRAM Speicher den Prozessor mit Daten versorgen Die bertragung zwischen EDO RAM Speicher und Prozessor erfolgt asynchron Der Takt spielt nur prozessorseitig eine Rolle NEC97 spezi fiziert die Zugriffe f r den verbauten DRAM Grundlage f r die weiteren Berechnungen sind die Spezifikationen f r die nPD4265165 50 Bausteine Ein einfacher Schreib oder Lesezyklus ben tigt tro 84ns Die Schreib und Lesezyklen im Burstmode ergeben sich aus den Zeiten f r die bertragung von Zeilen und Spaltenadressen Die bertragung der Daten erfolgt inner halb des Spaltenzyklus Die Zeit f r die bernahme der Zeilenadresse trop betr gt minimal 11 ns In dieser Zeit wird die Zeilenadresse im DRAM Baustein zwischengespeichert und liegt nun f r weitere Spaltenzugriffe an Ein vollst ndiger Spaltenzyklus typc dauert mindestens 20 ns Der erste Spaltenzyklus wird begrenzt durch die nCAS Haltezeit tesy 38ns Nach einem Burstzyklus wird eine Zeit spanne trp gt 30ns ben tigt die die G ltigkeit der Zeilenadresse beendet 3 Bustakt CPUTakt 2 21 Ein Burstzyklus ergibt sich aus
13. 50 6 48 9 86 0 768 576 2 30 0 50 7 51 0 86 0 768 576 3 20 0 50 7 33 9 86 0 Tabelle A 3 Datentransferraten mit angepassten Startadressen beide Auf rufe mit align Bei Leseoperationen wurden weiterhin mit Burst Of Eight auf den Spei cher zugegriffen Schreiboperationen erzeugten zwei Burst Of Four In Int99 6 3 Write Buffer WB wird die Gr sse der Write Buffer Bl cke mit bis zu 16 Byte angegeben was bei einem Flush Burst Of Four erzeugt Burst Of Eight werden beim Zur ckkopieren des Cache durch den Write Buffer erzeugt Ex perimente mit dem Leeren des Datencaches zeigten Burst Of Eight Perioden 104 Da aber der ganze Cache zurtickgeschrieben wurde beinflusste das Leeren des Datencache das Ergebnis negativ Da die Ergebnisse nicht reproduzierbare Werte ergaben wurden sie nicht aufgenommen Die Speichertests wurden an dieser Stelle abgebrochen da die Ergebnis se bereits Aussagen im Vergleich zu den berechneten Speichertransferraten zulassen A 1 4 Das Programm mem2mem Test to get the maximum transfer rate on a system moving frames from a memory area to an other You can add your own frame size in structur frames Be shure the defined frames in structur frames are smaller than MAX_FRAMESIZE Author Frank Schwanz EMail schwanz at fh brandenburg de Version 1 2 Date 2002 03 21 Revision 1 0 2002 03 18 initial 10 7 1 1 2002 03 20 assembler memcpy added 1 2 20
14. Abbildung 2 16 Funktionsdiagramm SA1100 und SA1101 Developement Board Int98 Figure 4 13 F r die Grafikausgabe auf einem Monitor befindet sich auf dem SA 1101 Development Board eine Grafikkarte Die Erweiterungskarte nutzt f r den Zugriff auf den Hauptspeicher den Busmastermode der in Abschnitt 2 2 3 beschrieben wurde Die Grafikausgabe auf der Erweiterungskarte wurde f r den Anschluss von Monitoren entwickelt ber das Farbformat des Grafik speichers wurde keine Aussage getroffen Da ein PC Monitor RGB Signale ben tigt muss bei nicht RGB Farbformaten eine Farbraumkonvertierung im CPLD erfolgen der die bertragung der Daten an den VGA Controller bernimmt Beschrieben wurden zwei Varianten die sich in der Lage des Grafikspeichers unterscheiden Im Haupspeicher untergebracht ben tigt das Erweiterungsboard keinen eige nen Grafikspeicher Nachteilig ist die zus tzliche Belastung des Speicher busses der bereits Video und TV Ausgabestrom bew ltigen muss F r 41 h here Aufl sungen ist diese Variante nicht geeignet Externer Grafikspeicher auf der Erweiterungsplatine wird ebenfalls ber den CPLD angesteuert der den Busmasterzugriff auf den Hauptspeicher vornimmt Die bertragung der Grafikdaten f r den Bildaufbau belas ten den Hauptspeicherbus in dieser Konfiguration nicht 42 Kapitel 3 Betriebssystem und Ger tetreiber Dieses Kapitel befasst sich eingehend mit dem Betriebssystem des LART Boards Der erste T
15. Aufbau der Arbeit 2 04 4 an nn RA Hardware 2 1 Das BN Board ssc ga arrr uari era nein 22 LART Board ua re en a a a OR eae 2 2 1 Die Schnittstellen des LART Boards 22 2 Prozessor EE E es 2 2 3 Speicher A so fe En By ee ee 2 3 Videoerweiterung LartVio 2 22 2 onen 2 3 1 Analoge und digitale Videotibertragung 2 3 2 Der Videodecoder SAA7113 0 2 3 3 Der Videoencoder ADV7171 23 4 PC Bus 4 4 24 e oes BERR RSE OEE A 2 35 Der Videocontroller ACEX1K 2 4 SA 1100 Multimedia Development Board Betriebssystem und Ger tetreiber 3 1 Das Betriebssystem des LART Board 2 Li xkernel eos s wich wen HO ed wR Be ee 3 3 Ger tetreiber und Ger teklassen 2 22222200 3 3 1 Adressr ume e 33 2 ENEE yk arte u ren ee was kr 3 4 Framebuffer 2 248 4664 2 4 0 a Se es 3 4 1 Das aktuelle Framebuffer Subsystem 3 4 2 Das Framebuffer Subsystem im Kernel 2 5 3 5 Video4Lin x es s s roii a e DSR eet ra ee 3 5 1 Die Video4Linux APl 2 2 6 ee 220 88 804 3 5 2 Die VideodLinux2 APl 4 ease ee eR a 8 84 3 6 Das I C Subsystem lt zu ie A Acta Heed Bad si Anforderungen an das BV Board 4 1 Videoempabe oa au 0a 0 du bo eed EN ne aa nn 41 2 Videoausgabe 25 fa fae Bee Da a at Entwurf 5 1 Grundentwurf 3 hos 3 Zar ar Gee Kew ee Yee ed 5 2 Busm sterbetrieh us N I wa ds en ee 8 3 Module des Videocontrollers
16. Basiszellen erreicht Adresse Daten Funktion all al0 OR XNOR XOR NAND 0 0 0 1 0 1 0 1 1 0 1 1 1 0 1 0 1 1 1 1 1 1 0 0 Tabelle 2 6 Funktion einer Lookup Table LUT Altera bezeichnet diese Funtionsbl cke als Logikelemente Die Funktion der Logikelemente wird durch Lookup Tables LUT realisiert Sie sind auf gebaut wie eine normaler Speicher wobei f r jede der 2 Kombinationen an n Eing ngen eine Speicherzelle adressiert wird Der Inhalt der Speicherzellen bestimmt die logische Funktion Tabelle 2 6 zeigt beispielhaft unterschiedli che Funktionen in Abh ngikeit von den Inhalten der Speicherzelle Der ACEX 1K implementiert in jedem Logikelement eine LUT mit vier Eing ngen Neben der LUT besitzt jedes Logikelement eine Registerstufe die als D T JK oder RS Flipflop konfiguriert werden kann Das Register kann ber den Clock und den Clock Enable synchron betrieben werden Die Setz und R cksetzeing nge PRN und CLRN erlauben den asynchronen Betrieb des Registers unterst tzt von der Clear amp Preset Logic Control Einheit Der Carry Chain Block erm glicht die Verkn pfung mehrerer Logikelemente zu 10Die Beschreibung der Logikelemente bezieht sich auf die Altera Architektur 34 Carry In Cascade In Register Bypass Programmable Register data Look Up To FastTrack data2 Table data3 LUT Interconnect data4 To LAB Local Interconnect
17. Datestrom ist demnach 25 775M Byte s 2 2 x 25 775M Byte s SC 2 x 25 775M Byte s 128 875Mbyte s Von den 625 Zeilen einen Bildes nach CCIR werden 576 Zeilen f r das aktive Bild verwendet Die Zeit des aktiven Bildbereichs eines Halbbildes betr gt 288 x 64us 18 43 us 61 ca 52000 ns Bilddaten 20 ms 312 5 Zeilen AE KK WA WA GS d Liz V de 288 Zeilen y W de LO XXXXXXXXX OK SHEE a 2525 Ee SEN es Sed BS SE SE 225 EE 322223 recesses 2222 SET 3222 2202022 recess 9222222 EE 222 2232323 besesesd EE SE SE EE SE SE SE 1 SE Gesamtzeile 64000 ns Abbildung 5 2 aktive Bild und Austastzeiten eines Halbbildes Abbildung 5 2 veranschaulicht diese zeitlichen Zusammenh nge Werden die Austastzeiten f r die bertragung mit genutzt reduziert sich die maximale Datentransferrate durch die zeitliche Verteilung des Daten stroms Die notwendige Gr sse des Puffers ergibt sich aus Ts der Zeit die bisher f r die bertragung nicht genutzt wurde Eyes die Gesamtzeit die f r die bertragung zur Verf gung steht nu die Anzahl der Bytes die in der Zeit t zu bertragen sind Nbuf der notwendige Puffer die bertragung auf treer auszuweiten tleer NU Nouf Loes F r eine Pufferung der Daten in der horizontalen Austastzeit m ssen ca 64000n
18. Dazu wird das Signal newRow eingef hrt das veranlassen soll den Burst zu beenden Danach beginnt ein neuer Burst der mit der bertragung der Zeilenadresse eingeleitet wird Die Schnittstellen zu Videoeingabe und Videoausgabe sind sehr hnlich Lediglich die Datenrichtung ist unterschiedlich zu behandeln Es wird im folgenden nur die Schnittstelle zur Videoeingabe beschrieben DEC_dma_req fordert eine Daten bertragung zum Hauptspeicher an Das Signal muss nur einen Takt lang aktiv sein und kann nur ber DEC_dma_exit_req zur ckgesetzt werden Die Anforderung wird je nach Zustand des DMA Moduls sofort bear beitet oder die Anfrage notiert Damit ein DMA Zugriff eingeleitet wird muss DEC_dma_en aktiv sein Das Deaktivieren von DEC_dma_en beendet sofort die Daten bertragung 5 3 2 Adressgenerator Die Adressierung des Speichers wird ber das Busmastermodul erfolgen Da her erscheint es sinnvoll den Adressgenerator der beiden Videomodule direkt an das Busmastermodul zu koppeln Bei der Adressierung des Grafikspeichers wird von einem linearen Speicherbereich ausgegangen Interlacing und Deinterlacing kann durch die Zuordnung der Startadresse einer Zeile gel st werden Die Startadresse einer Zeile kann aus der Zeilen nummer nzeile und der Anzahl der Bytes einer Zeile Ga berechnet werden Ad Zeie Ad FB Nigeite I Zeile Adr rg enspricht der Startadresse des Grafikspeichers Diese Berechnung kann der Adressgenerator ebenfalls ber
19. Initialisierungphase wird die Funktion int lartviofb_init_fpga struct lartvio_par par aufgerufen In der Funktion lartviofb_init_fpga wird zun chst die Spei cherbank2 initialisiert In dieser Speicherbank liegen die Register des Lart VIO Der Bustakt des LART Board wird auf das LartVIO geschalten Ab jetzt konnen die Register des LartVIO gelesen und geschrieben werden Das Vorhandensein der Hardware wird iiber das Register IDSTR gepriift Die Register des Lart VIO sind im LART Video Hardware amp Programmable Lo gic Manual KS02 erl utert F r die Kommunikation mit dem Encoderchip ADV7171 ist der I C Treiber adv7170 zust ndig Bevor der Treiber initiali siert werden kann muss der I C Adaptertreiber i2c_lartvio geladen sein Der I C Adaptertreiber gew hrleistet den Zugriff auf den I C Bus des LartVIO Beide Module werden ber die Funktion request_module geladen Der Ker nel l d dann automatisch die Module nach sofern sie nicht bereits geladen sind Anschlie end wird ein linearer nicht gecachter Speicherbereich angelegt der sp ter die Bilddaten enth lt Der Speicherbereich wird entsprechend der maximalen Bildgr e angelegt Das sind derzeit 720 x 576 x 3Byte 1 3M Byte Dieser Speicherbereich ndert sich bei Ver nderungen der Bild gr e nicht Arbeiten auf dem LART Board verschiedene Applikationen kann der Speicher nach einer gewissen Zeit stark fragmentiert sein Das Erneute Anlegen eines linearen Speicherbereic
20. Now that we checked it we alter var The reason being is that the video mode passed in might not work but slight changes to it might make it work This way we let the user know what is acceptable switch var gt bits_per_pixel case 24 RGB 888 if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 var gt red offset 0 var gt red length 8 var gt green offset 8 var gt green length 8 var gt blue offset 16 var gt blue length 8 var gt transp offset 0 var gt transp length 0 endif break default return EINVAL if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 var gt red msb_right 0 var gt green msb_right 0 var gt blue msb_right 0 var gt transp msb_right 0 endif return 0 B 2 2 Die Funktion lartviofb_set_par pe lartviofb_set_par Alters the hardware state info frame buffer structure that represents a single frame buffer Using the fb_var_screeninfo in fb_info we set the resolution of the this particular framebuffer This function alters the par and the Jb_fix_screeninfo stored in fb_info It doesn t not alter var in fb_info since we are using that data This means we depend on the data in var inside fb_info to be supported by the hardware KR X X X x NEEN In 2 4 x useing var from vpar E 113 lartviofb_check_var is always called before lartviofb_set_par to ensure this 90 100 110 10 if LINUX_VERSION_C
21. Spaltensignale eines Burst of Eight in der aktuellen Konfiguration e aoaaa bode ee See a Se Be 24 Blockschaltbild des Lert VIO a 228 4 28 are hae ee ke 27 DO Bus Bit Transfer nach Phi01 Fig 4 32 DO Bus Daten Transfer nach Phi01 Fig 6 33 DC Schreiboperation bei SAA7113 und ADV7110 7111 33 DC Leseoperation bei SAA7113 und ADV7110 7111 34 Logikelement in der ACEX 1K Architektur von Altera aus STEE 35 Blockschaltbild des SA 1100 Multimedia Development Board Int98 Figure 4 1 oa 3 08 wR Sea ze stern 38 Blockschaltbild der Videodigitalisierung des SA 1100 Multi media Development Board Ausschnitt aus Int98 Figure 4 2 39 Blockschaltbild der Videoausgabe des SA 1100 Multimedia Develop ment Board Ausschnitt aus Int98 Figure 4 6 40 Funktionsdiagramm SA1100 und SA1101 Developement Board Int98 Figure 4 13 2 2 22 24 un eee ae nen 41 Monolithisehe Architektur ur 4 a8 ser nase ex 45 Mikrokern Architektur 45 Prozess und Interruptebene nach Mar99 47 einfaches Overlay 51 Overlay mit Clipping oder Chromakey 51 Chromakey Verfahren die Farbe definiert den transparenten Bereichs ee Be le OE ee a Re Se 52 3 7 3 8 5 1 5 2 5 3 5 4 5 9 5 6 5 7 5 8 5 9 5 10 6 1 6 2 6 3 6 4 A l Clipping um die angegebenen Bereiche herum wird das Bild geschrieben 2 4 408 4 hese eo ead a we ES See eel Struktur des DC Subsystems 2 2 222 s
22. Video4 Linux Treiber verbunden Ein weiterer Treiber wird den Zugriff auf den I C Bus des LartVIO gew hrleisten Abbildung 5 10 zeigt das Zusammenspiel der zu implementierenden Treiber untereinander und zu den Subsystemen Applikation Applikation m 1i2c core Framebuffer i i Video4Linux2 API subsystem 12c algo bit fbcon c WE i i2c lartvio I2C Busadapter lartvio_fb adv7170 saa7113 lartvio_vin Framebuffertreiber 12C Client 12C Client V4L2 Treiber Hardware Hardware Hardware Abbildung 5 10 bersicht ber das Treiberdesign Da ein Gro teil der Funktionalit t in den FPGA verschoben wurde liegt die Hauptaufgabe der Treiber in der Abstraktion der Hardware sowie den allgemeinen Ger tetreiberanforderungen wie in Abschnitt 3 3 beschrieben 75 5 4 1 Framebuffer In Abschitt 3 4 1 wurde das Framebuffer Subsystem der aktuellen stabilen Kernelversion untersucht Die generischen Funktionen aus fbcon c entspre chen in der Struktur in weiten Teilen dem Design in der aktuellen Entwicker version des Framebuffersubsystems Unterschiede liegen vor allem in den Ubergabeparametern der Funktionen Viele Funktionsaufrufe fiir die Console sind in das Subsystem integriert k nnen aber auch durch eigene Implemen tierungen ersetzt werden Das Framebuffersystem der stabilen Kernelversion ist somit dem des Entwicklerkernel hnlich Die Dok
23. den Strongarmspeicherbus sind physische Adressen und Busadressen gleich 3 3 2 Interrupts Ein Ger tetreiber behandelt Anfragen von Applikationen system calls und Hardwareunterbrechnungen interrupts Anhand der Richtung der Anfragen werden die Anforderungen unterteilt in top halfs den Systemaufrufen des Betriebssystems und bottom halfs den Hardwareanforderungen Die Trei berfunktionalit t kann so in zwei Schichten Prozess und Interrupt Ebene unterteilt werden Die Schichten arbeiten meist asynchron Da sich beide Schichten einen gemeinsamen Status teilen m ssen Zugriffe auf den shared Bereich synchronisiert werden System Calls N Prozess Ebene Top Half Interrupt Ebene Bottom Half LL Hardware Interrupts Abbildung 3 3 Prozess und Interruptebene nach Mar99 47 Fiir die Synchronisation sind Warteschlangen Semaphoren und Unter brechungssperren oft ausreichende Mechanismen Werden mehrere top half Zugriffe vom Ger tetreiber zugelassen m ssen ebenfalls entsprechende Syn chronisationsmethoden implementiert werden Linux verwendet in diesem Zusammenhang den sogenannten Bottom Half Handler Softwareinterrupts die nach der Abarbeitung zeitkritischer Hardwareinterrupts zeitunkritische Funktionen ausl sen k nnen 3 4 Framebuffer Grafikkarten besitzen meist einen eigenen Grafikspeicher in dem die Bildda ten f r das Bild einen Frame liegen F r diese framebuffer basierten Aus g
24. der Maximal OK nicht durch nicht durch breite der virtuellen Aufl sung gef hrt gef hrt 1024x576 Virtueller Bereich 640x576 klei OK nicht durch nicht durch ner als die sichtbare Aufl sung gef hrt gef hrt 720x576 berschreitung der Maximalh he OK nicht durch nicht durch des sichtbaren Aufl sung 720x768 gef hrt gef hrt Virtueller Bereich 720x575 kein OK nicht durch nicht durch Teiler von 4 gef hrt gef hrt Virtueller Bereich kleiner als die OK nicht durch nicht durch sichtbare Aufl sung 720x768 gef hrt gef hrt Kleinstm gliche Aufl sung OK OK OK 144x80 RGB24 Standardaufl sung 320x240 OK OK OK RGB24 Falsche Farbtiefe bergeben OK nicht durch nicht durch 320x240 RGB16 gef hrt gef hrt 124 Test beschreibung Ergebnis Sichtpriifung Farbtest Aufl sung Nicht darstellbares Farbformat OK Farbformat OK bergeben bergeben 320x240 nicht BGR BGR24 Anmerkung Farbformat sollte korrigiert werden Offset Ubergeben 40x40 bei OK OK OK 320x240 offset 40x40 Offset nicht durch 4 teilbar offset OK nicht durch nicht durch 50x50 gef hrt gef hrt Nicht darstellbare Aufl sung ver OK nicht durch nicht durch wendet 364x288 gef hrt gef hrt Nicht darstellbare Aufl sung ver OK nicht durch nicht durch wendet 320x576 gef hrt gef hrt 125 C 2 Video4Linux2 Test
25. des Registers MD CNFG gibt an ob die Verschiebung mit jedem CPU Takt oder jedem Bustakt erfolgt Eine 1 in der Bitstelle entspricht einem High Zustand der nCAS Leitung eine 0 dem Low Zustand Die Spaltenadresse wird einen CPU Takt vor der Aktivierung von nCAS angelegt MDCASO 1100 0111 0001 1100 0111 0000 0011 1111 MDCAS1 1111 1111 1100 0111 0001 1100 0111 0001 MDCAS2 1111 1111 1111 1111 1111 1111 1111 1111 Tabelle 2 4 DRAM Wellenform Register im Kernel 2 4 18 Der StrongARM nutzt diese Methode fiir alle Schreib und Lesezugriffe auf den DRAM Der Speicherzugriff endet wenn die Anzahl der nC AS Pulse mit der Burstgr e bereinstimmt Dabei wird ein einfacher Speicherzugriff als Burst of One angesehen MDCASO MDCAS1 LSB MSB LSB oru rekt UU UU UU UU UU UU aen LLL LU UU PU UU Sa ie ga 5 Bustakte nRAS nCAS V Row Col Col 4 Col 8 Gol X Coie N Cov20 X Gei Col28 II Abbildung 2 6 Zeilen und Spaltensignale eines Burst of Eight in der aktu ellen Konfiguration Die Zugriffszeit f r einen Burst Of Eight ergibt sich aus 54 CPU Takte der Wellenform einem Takt zwischen der Deaktivierung von nCAS und nRAS sowie 5 TRP 1 Bustakte zwischen zwei nRAS Zyklen BurtOf Eight 294ns 54 1 4 525ns TRP 1 9 05ns Abz
26. geschrieben ber ioctl Kommandos sind Informationen ber das Ger t Eingabe kan le und Bildeigenschaften erh ltlich Eingabekanal und Bildeigenschaften k nnen ver ndert werden Wie bereits erw hnt ist diese API seit der stabilen Version 2 2 Bestandteil des Kernel Viele Applikationen greifen ber diese API auf Multimediager te zu 3 5 2 Die Video4Linux2 API Bill Dirks berarbeitete die Video4Linux API bereits 1999 Die Unterst tzung der verschiedenen Multimediager te wurde erweitert Die neue API unterteilt die Ger te in folgende Schnittstellen e Video Capture Interface dazu geh ren alle Arten von Videograbbern aber auch Audio Karten e Video Effect Interface f r die Bildmanipulation 52 e Video Codec Interface Komprimierer und Dekomprimierer und Ger te die das Video in anderer Weise ver ndern e Video Output Interface Ausgabe von Bildstr men die auch als Over lay im Framebuffer angezeigt werden k nnen e Data Service Interface Schnittstelle f r Teletext RDS etc F r die Videodigitalisierung ist das Video Capture Interface von besonde rem Interesse Auf die weiteren Schnittstellen wird im folgenden nicht weiter eingegangen Auff lligste nderung ist die M glichkeit das Ger t von mehreren Ap plikationen zu ffnen Die Operationen werden I O und no I O Operationen unterschieden Ein Ausgabe Operationen k nnen weiterhin nur von einer Applikation aufgerufen werden Die Eigenschaften d
27. xres 4 var gt yres 4 var gt xres_virtual 4 var gt yres_virtual 4 var gt xoffset 4 var gt yoffset 4 size must be modulo 4 return EINVAL we have only one fullsizeflag for both vertical and horizontal so both must be fullsize or halfsize if var gt xres gt 360 amp amp var gt yres lt 288 var gt xres lt 360 amp amp var gt yres gt 288 return EINVAL if var gt xres gt var gt xres_virtual if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 var gt xres_virtual var gt xres else return EINVAL endif if var gt yres gt var gt yres_virtual if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 var gt yres_virtual var gt yres else return EINVAL endif if var gt xres_virtual lt var gt xoffset var gt xres if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 var gt xres_virtual var gt xoffset var gt xres else return EINVAL endif if var gt yres_virtual lt var gt yoffset var gt yres if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 var gt yres_virtual var gt yoffset var gt yres else return EINVAL endif fe Memory limit line_length get_line_length var gt xres_virtual var gt bits_per_pixel if line_length var gt yres_virtual gt par gt videomemorysize return ENOMEM 112 50 60 70 80
28. 02 03 21 align buffer ES include lt stdio h gt include lt string h gt include lt time h gt 20 define MAXFRAMESIZE 1024 1024 2 2 MB define BUFSIZE 1024 define FRAMES_PER_SECOND 25 to get better results we need to run more than a second define SECONDS 10 30 struct frame int height int width int colorbytes Different frame sizes to test 105 height width bytes per pixel Ka struct frame frames 40 320 240 2 320 240 3 640 480 2 640 480 3 768 576 2 768 576 3 k int main int argc char argv 50 char fb_in fb_out char fb_in_align fb_out_align char bufincnt bufoutcnt int i j k asmcpy 0 memalign 0 framesize buffs_for_frame clock_t cll cl2 float time printf s asm align n argv 0 printf asm using assembler memcpy n 60 printf align using align memory address n n for i 1 i lt argc i if stremp argv i asm 0 asmcpy 1 printf Using assembler memcpy n if stremp argv i align 0 memalign 1 70 printf Using align memoryaddress n create in and out buffers 7 fb_in char malloc MAXFRAMESIZE BUFSIZE fb_out char malloc MAXFRAMESIZE BUFSIZE 7 80 make address align to 1024 to enable Burst Of Eight if memalign fb_in_align char unsigned long fb_in BUFSIZE 1 amp
29. 2 15 Blockschaltbild der Videoausgabe des SA 1100 Multimedia Development Board Ausschnitt aus Int98 Figure 4 6 Fiir die Videoausgabe auf dem SA 1100 Multimedia Development Board wurde der LCD Controller genutzt Dieser liest die Videodaten aus dem Hauptspeicher iiber einen integrierten DMA Controller und stellt diese ein schlie lich horizontalen und vertikalen Synchronisationssignalen an den GPIO Pins zur Verf gung Diese L sung belastet den Speicherbus nur mit Lese zugriffen Die Synchronisationssignale f r LCD Displays werden in Video 40 synchronisationsignale gewandelt und an einen Videoencoder bertragen Die Arbeit erledigen zwei CPLD Schaltkreise Beschrieben wurde ebenfalls die Nutzung eines Videoencoders ADV7175 statt des zu programierenden CPLD Schaltkreises Das Videobild muss im Framebuffer bereits interlaced vorliegen da der LCD Controller eine solche Funktionalit t nicht besitzt Entsprechend m ssen Anwendungen ebenfalls ein Interlaced Bild erzeugen will man neben Video daten auch Grafik ausgeben Address 25 0 PCMCIA Control PS 2 Trackpad SA 1101 SA 1100 Data Bus 31 0 N NIT nOE n nRASI1 0 nCAS S 0 E LCD and Video Frame Buffer in DRAM Parallel Port Keypad Address Bus 11 0 Data Bus 15 0 nRAS nCAS nWE LCD Display Low Speed Analog PWM Video out 1024 x 768 Video Frame Buffer in DRAM 1M x 16
30. 4 5 3 Module des Videocontrollers Die Implementierung eines Busmasters zieht weitreichende Folgen mit sich Da der Prozessor an der Datentibertragung nicht mehr beteiligt ist muss jegliche Funktionalit t die den Datenstrom verarbeitet in die Videomodule integriert werden In Tabelle 5 1 werden die in Abschnitt 4 ausgef hrten funktionalen Anforderungen zusammengefasst Die Tabelle beschr nkt sich auf die den Videostrom ver ndernden Funktionen Videoeingabe Videoausgabe Adresssteuerung Adresssteuerung Deinterlacing Interlacing Skalierung Bild 2 optional stu optionale Skalierung Bild 2 fenlose Skalierung optional Cropping Farbkonvertierung nach RGB24 Farbkonvertierung von RGB24 optional weitere Konverter nach YCbCr Schnittstelle f r weitere Farbkon verter optional Speicherung in Planes optional Lesen von Planes Tabelle 5 1 Bildver ndernde Funktionalit t von Videoein und Videoausgabe Die Resourcen des FGPA ACEXIK sind begrenzt Wie viele Resourcen die einzelnen Funktionen beanspruchen war schwer abzusch tzen Das De sign wurde dementsprechend so entworfen dass weiterere Funktionen nach tr glich m glichst ohne nderungen an der vorhandenen Funktionalit t im plementiert werden k nnen Die Speicherung in Planes also im Hauptspeicher getrennten Farbbe reichen wurde verworfen Diese Funktion w rde die Implementierung von Burstzugriffen erschweren da st ndig verschiedenen Speicherbereiche ang
31. 6Bit breite FIFOs bertragen W hlbar ist die bertragung eines Videos mit 32Bit bertragungsbreite oder zwei 16Bit breite Videostr me Ein weiter CPLD bernimmt die prozessorseitige Ansteuerung der FIFOs und die bertragung des FIFO HalfFull Signals Das HalfFull Signal ist mit dem GPIO1 verbunden Die FIFOs arbeiten mit der gleichen Geschwindigkeit wie der Hauptspeicher und wird in ber die DRAM Bank3 in den Haupt speicher eingeblendet 39 Auf die Ubertragung von Videosynchronsignalen wurde verzichtet Die Synchronisation des Videostromes kann ber Kontrollcodes ermittelt wer den die am Anfang jeder Zeile und bei der vertikalen Syncronisation auftre ten Vgl Abbildung 2 5 Der HalfFull Interrupt liest den Videostrom bis zur Framestartkennung und beginnt dann mit der bertragung der Video daten Der FIFO wird mit Bursts of Eight ausgelesen und in den Hauptspei cher geschrieben Bei der Berechnung der Bandbreite rechnet Intel dabei mit 32 x 8 x 30ns 7680ns f r das Leeren eines FIFO 30ns als Zeit f r einen CAS Zyklus Diese Zeit liegt ca 2 5ns ber dem technisch machbaren vlg Abschnitt 2 2 3 Se nn 12 27MHz LCDclk LCDVsync LCDHsync 12 27MHz GPIO26RcIk LCDclk peop Clock Doubler Iya TVVsync TVHsync 24 5MHZz TVclk SA 1100 LCD OUTPUT TV CRT SCART video out a a a a a a ala eo D FER 3283 TV VIDEO AND e lt lt LL Abbildung
32. A als g ltig betrachtet w hrend sich im Low Zustand von SCL der Zustand von SDA ndern darf Die Daten werden dem entsprechend mit der steigenden Flanke von SCL bernommen Eine Ausnahme bilden die Start und Stopbedingung Hier ndert sich die Datenleitung w hrend die Taktlei tung sich im High Zustand befindet Die Start S und Stopbedingung P werden nur vom Master erzeugt Sie leiten ein Datentransfer ein bzw been den ihn Eine Stopbedingung gibt den Bus wieder frei Die Startbedingung kann auch wiederholt auftreten Sr ohne Beendigigung des Transfers durch eine Stopbedingung 32 Abbildung 2 9 DC Bus Daten Transfer nach Phi01 Fig 6 Ein Datenwort besteht aus 8 Bit und einem Acknowledge Bit Wahrend der bertragung kann der Slave die Taktleitung auf Low ziehen Der Master wartet dann bis die Taktleitung wieder auf High ist Nach dem achten Daten bit folgt das Acknowledge Bit Der Sender gibt die Datenleitung frei High Zustand W hrend der High Periode des Taktimpules muss der Empf nger den Empfang durch den Low Zustand der Datenleitung best tigen Eine bertragung beginnt mit der Adressierung des Slave Ger tes der 7 Bit breiten Slaveadresse Das achte Bit des Datenwortes ist das Read Write Flag welches die Datenrichtung angibt Das entsprechende Slave Ger t qui tiert die bertragung im Acknowledge Bit und bleibt bis zur n chsten Stop bedingung aktiv In den Datenbl ttern werden h ufig je ein
33. Bit Adressbereich Davon stehen 26 Adressleitungen A0 A25 am externen Bus zur Verf gung Den Adressbereich teilt der Prozessor in mehrere Speicherb nke Die Signale f r die Steuerleitungen der Speicherb nke nRASO nRAS3 werden ber die Adressbits A27 A31 gebildet Es sind 27 Bytes 64 MByte in jeder Bank adressierbar Int99 2 4 Memory Map Der Adressbereich fiir die DRAM Banke Int99 2 4 Memory Map er streckt sich von BankO 0xC000 0000 OxC7FF FFFF Bank 0xC800 0000 OxCFFF FFFF Bank2 0xD000 0000 OxD7FF FFFF Bank3 0xD300 0000 OxDFFF FFFF Auf dem LART Boord werden nur zwei DRAM B nke genutzt Die Steu erleitungen nRASO und nRASI entsprechen den DRAM B nken 0 und 1 und sind folgenden Teiladressen zugeordnet A31 A30 A29 A28 A27 nRASO 1 1 0 O nRAS1 1 1 0 0 1 nRAS2 1 10 1 0 nRAS3 1 1 oO 1 1 An den Adresseing ngen der DRAM Bausteine liegen die Adressleitun gen A10 A20 und A24 des Prozessorbusses an Lar00 LART Memory Ent sprechend Int99 10 3 1 DRAM Overview werden fiir die Zeilenadresse die Adressleitungen A24 und A20 10 benutzt fiir die Spaltenadresse A23 A21 und A9 A2 Die Adressleitungen AO und Al entsprechen den Steuerleitungen nCASO nCAS3 Der pPD426165 nutzt in der Spaltenadresse nur die unteren 10 Adressbits NEC97 S 4 19 AO A1 A2 A9 A10 A20 A21 A22 A23 A24 A27 prozessorseitig speicherseitig nRASO nRAS1 nCASO nCAS3 Bytesteuerung Row11 Row0 10 Speicher
34. C Treiber F r die Kommunikation mit den Encoder und Decoderchips mussten drei Treiber implementiert werden Der Adaptertreiber stellt die Kommunikation mit dem P C Bus bereit F r die Abstraktion der Chipeigenschaften wurde f r jeden Chip ein eigener Treiber implementiert Die beiden Leitungen des I C Bus SCL und SDA k nnen ber das Re gister COMC1 gelesen und geschrieben werden Dieses Verfahren unterst tzt 93 der im Kernel vorhandene Bit Algorithm Layer Im Adaptertreiber fiir das LartVIO mussten lediglich vier Funktionen implementiert werden die die Zust nde der Leitungen SCL und SDA lesen und schreiben k nnen In In itialisierung des Treibers wird der FPGA initialisiert und Encoder sowie De coderchip resetet Danach bleiben beide Chips im eingeschalteten Zustand Die Chiptreiber sind unabh ngig von den Besonderheiten des LartVIO Sie k nnen daher auch von anderen Treibern genutzt werden Im Linuxker nel ist es blich f r jeden Chip nur einen Treiber zu implementieren der von verschiedenen Hardwaretreibern genutzt wird Die Kommunikation der Hardwaretreiber erfolgt ber die Funktion int command struct i2c_client client unsigned int cmd void arg die der ioctl Funktion herk mmlicher Treiber entspricht Die Kommandos des jeweiligen Treibers sind in den Headerdateien der Treiber definiert 6 3 Schnittstellen zu Applikationen Der Zugriff auf den Framebuffertreiber und die Video4Linux2 API wird f r die einfac
35. DV7171 ist 8 Bit breit Die auszugebenden 32Bit Vi deodaten miissen in Bytes gesplittet an den Datenbus des Encoder Chip bergeben werden Der ADV7171 erzeugt im Mastermodus die Videosyn chronsignale Die Videoeingabe kann sich darauf beschr nken auf die Syn chronsignale zu reagieren Die Farbkonvertierung liegt wie bei der Videoeingabe in Datenflussrich tung vor dem FIFO Nachdem der FIFO das full Signal setzt diirfen keine weiteren Daten mehr in den FIFO geschrieben werden Sollten fiir die Farb konvertierung eine oder mehrere Pipelinestufen n tig sein muss das full Signal entsprechend der Pipelinetiefe fr her gesetzt werden Videoencoder Schnittstelle Datenpuffer RGB gt YCbCr Skalierung Abbildung 5 9 Datenfluss Videoausgabe Abbildung 5 9 zeigt den Datenfluss und die Bestandteile der Videoausga be Die Skalierung wurde in das Videobearbeitungsmodul integriert da keine weiteren Module zur Ver nderung des Videostromes vorgesehen sind 5 3 6 StrongARM Interface F r die Kommunikation mit dem Prozessor und die Einstellung der Eigen schaften wird ein Modul ben tigt das diese Kommunikation zum Prozessor bernimmt Die Eigenschaften werden f r den Prozessor als sichtbarer Spei cher in der statischen Speicherbank 2 ansprechbar sein Die Beschreibung der 73 Register kann KS02 entnommen werden Neben den Eigenschaftsregistern ben tigen die Treiber einige Inte
36. EQ Signal wieder Wurde in der Zeit der externen Busaktivit ten im StrongARM das Re freshflag gesetzt f hrt der Prozessor nach R ckgabe des Busses einen Refresh durch 26 2 3 Videoerweiterung Lart Vio Das LartVIO wird das LART Board um eine Videoein und Videoausgabe erweitern Ein CAN Buscontroller soll die Kommunikation mit anderen Mo dulen des R Cube erm glichen Auf dem LartVIO werden drei verschiedene Spannungen ben tigt Aus 3 3V des Lart Board werden 2 5V und 5V er zeugt da die verschiedenen Schaltkreise mit unterschiedlichen Spannungen arbeiten Abbildung 2 7 zeigt ein Blockschaltbild des LartVIO wobei die Spannungsversorgungen nicht beriicksichtigt sind Video Video Video Video CAN In In2 In3 In4 Conn ZN FAN MO y V V Z TV OUT Videoencoder Videodecoder CAN Bus ADV7171 SAA7113 Anpassung A d PC IL avd IL CAN Controller Videocontroller ACEXIK K gt SJA1000 ZN Z High Speed Connector Abbildung 2 7 Blockschaltbild des LartVIO Die Konfiguration der Encoder und Decoderschaltkreise erfolgt ber einen I C Bus Encoder Decoder und CAN Schaltkreis haben eine eigene Takt 27 versorgung die iiber den Videocontroller einzeln an un
37. Fachhochschule Brandenburg Konzeption und Implementierung einer Videodigitalisierung und Videoausgabe unter Embedded Linux Diplomarbeit zur Erlangung des akademischen Grades Diplom Informatiker FH vorgelegt von Frank Schwanz Brandenburg 2002 Eingereicht am 21 Oktober 2002 1 Gutachter Dipl Informatiker Ingo Boersch 2 Gutachter Dipl Ing Henry Westphal Erklarung Hiermit erkl re ich da ich diese Arbeit selbst ndig und nur mit den zugelassenen und aufgef hrten Hilfsmitteln erstellt habe Brandenburg 21 Oktober 2002 Frank Schwanz Aufgabe Im Rahmen des Projektes Initiative Intelligente Autonome Systeme wird an der FH Brandenburg ein Kernel fiir intelligente autonome Systeme entwi ckelt Eine Teilkomponente des R Cube Systems ist eine eigenst ndige Bild verarbeitungskarte mit Strong ARM Prozessor und ARM Linux Zielstellung des Themas ist die Konzeption und Implementierung der Videodigitalisierung und Videoausgabe der Bildverarbeitungskarte Hierbei sind Schnittstellen zum Auslesen der Bilddaten vorzugsweise Video4Linux und Ausgabe von Bilddaten vorzugsweise Framebuffer Device zu entwi ckeln Die Umsetzung soll besonderen Wert auf die m gliche Nutzung in kommenden Linux Kernelversionen sowie die Performance der L sung legen Die Funktionsf higkeit des Systems ist durch geeignete Teststellungen zu evaluieren Inhaltsverzeichnis Einleitung 1 1 Aufgaben des BV Boards 22 22 22 nennen 1 2
38. Framebuffertreiber basiert auf der Beispiellmplementierung skele ton c der Kernelversion 2 5 20 aus dem Verzeichnis drivers video In der Bei spiellmplementierung sind die notwendigen Funktionen f r die Anbindung an das Framebuffersubsystem dokumentiert In dieser Version ist die Struk tur display auf die in Abschnitt 3 4 eingegangen wurde noch notwendig Im Laufe der Entwicklung soll diese Struktur bis zur Fertigstellung der Kernel version 2 4 6 entfernt werden Die Funktionen in der Datei skeleton c entspre chen in weiten Teilen den Funktionen in fbcon c der aktuellen Kernelversion 2 4 18 Lediglich die bergabeparameter sind unterschiedlich Um redundan ten Code zu vermeiden wurde f r beide Kernelversionen nur ein Treiber geschrieben Unterschiede wurden ber Preprozessorbefehle eingebettet Das folgende Codebeispiel zeigt die Anpassung der bergabeparameter anhand der Funktion lartviofb_set_par die weiter unten erl utert wird Das Makro KERNEL_VERSION setzt die bergebene Version in eine Integerzahl um if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 static int lartviofb_set_par struct fb_info info struct lartvio_par par struct lartvio_par info gt par struct fb_var_screeninfo var amp info gt var else static void lartviofb_set_par const void vpar struct fb_info_gen gen 1 struct lartvio_par par struct lartvio_par vpar struct fb_var_screeninfo var amp par gt mvar endif 88 In der
39. HDL Eine Funktionsbibliothek mit vorgefertigten Standardlogikelementen unterst tzt die Entwicklung F r die Verifikation steht eine statische Wellenform Simu lation zur Verf gung Beide Produkte bieten Schnittstellen f r Produkte von Fremdanbietern F r die komplexe Verifikation stellt Altera ebenfalls das 36 Produkt ModelSim Altera eine eingeschr nkte Version von ModelSim der Firma Model Technology zur Verfiigung ModelSim Altera kann nur mit den kostenpflichtigen Versionen von MAX Plus II und Quartus II genutzt werden 37 2 4 SA 1100 Multimedia Development Board F r den SA1100 wurde von der Firma Intel bis Mai 2000 ein Multimedia Development Board f r die Evaluierung eigener StrongARM Entwicklungen vertrieben und diente gleichzeitig als Referenzdesign Das Benutzerhandbuch Int98 beschreibt Aufbau und Funktionsweise der Komponenten des Boards Im Folgenden werden die Videoeingabe und ausgaben des SA1100 Multime dia Development Board vorgestellt Analog Audio Mux U TV Video l TV Video ond A Input LCD Output i y PC Monitor LED Display Keyboard and DSP SA 1100 Communications SA 1101 Development Board Memory Address and Data SODIMM 16 Mb 32 Mb EDO DRAM Abbildung 2 13 Blockschaltbild des SA 1100 Multimedia Development Board Int98 Figure 4 1 Das SA1100 Multimedia Development Board besteht aus einer Haupt platine und der Erweiterungsplati
40. IO_EBORDER_ENCXB par gt encaddr LARTVIO_ERCNTO rowoffset 4 lt lt 16 amp LARTVIO_ERCNTO_ROWOFFSET rowcount 4 amp LARTVIO_ERCNTO_ROWCNT if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 100 return 0 endif I 115 B 2 3 Die Funktion lartviofb_init_fpga lartviofb_init_fpga Setup communikation to Lart VIO par hardware parameter structure Setup membank2 check LartVIO and setup i2c driver Returns negative errno on error or zero on success static int lartviofb_init_fpga struct lartvio_par par int arg 0 setup_membank2 enable_busclock FPGA available if lartvio_available return ENODEV par gt encaddr ioremap_nocache LARTVIO_ENC_ADR LARTVIO_ENC_ADR_SIZE if par gt encaddr return ENOMEM enable and reset encoder par gt encaddr LARTVIO_ENCC ENCC_LOGIC_ENABLE ENCC_RESET ENCC_CLOCK_ENABLE udelay 1000 par gt encaddr LARTVIO_ENCC amp ENCC_RESET udelay 500 init the i2c_driver load needed modules request_module i2c_lartvio request_module adv7170 par gt adv i2c_get_client I2C_DRIVERID_ADV7170 12C_HW_B_LARTVIO I2C_ALGO_BIT par gt adv if par gt adv printk KERN_ERR no ADV7170 driver found return EINVAL if i2c_use_client par gt adv lt 0 printk KERN_ERR unable to use ADV7170 driver return EINVAL we reseted the en
41. Jabel e cear labctrl2 l Preset Logic Chip Wide Reset Clock Select labctrl3 labctrl4 Carry Out Cascade Out Abbildung 2 12 Logikelement in der ACEX 1K Architektur von Altera aus Alt01 Z hlern und Addierern w hrend die Cascade Signale bei Funktionen mit mehreren Eing ngen kurze Verz gerungszeiten garantieren sollen Jeweils acht Logikelemente sind zu einem Logic Array Block LAB zu sammengeschalten Die Carry und Cascade Signale der einzelnen Logikele mente in einem Logic Array Block sind mit dem jeweils nachfolgenden Logi kelement verbunden Diese Verschaltung erm glicht eine h here Integration und schnellere Signallaufzeiten Neben den Logikbl cken sind im ACEX 1K flexible RAM Bl cke EABs integriert Diese k nnen wie Lookup Tables f r die Generierung komplexer Funktionen oder als Speicher genutzt werden Der Speicher kann von zwei Seiten mit unterschiedlichem Takt angesprochen werden dual port RAM Die Konfiguration erm glicht die Nutzung des Speichers als Speicherblock oder FIFO First In First Out jeweils mit der Option single port oder dual port Die einzelnen Bl cke k nnen zu Gr en von 256x16 Bits 512x8 Bits 1024x4 Bits oder 2048x2 Bits geschalten werden Auf dem Lart VIO wurde ein ACEX 1K im 208 Pin PQFP Geh use vorge sehen Die Platine kann mit den pinkompatiblen Versionen EP1K30 EP1K50 und EP1K100 best ckt werden Die Unterschiede zwischen den Versionen sind in Tabelle 2 7 aufgef hr
42. Logikeinheiten des FPGA verbinden In weiteren Tests wurden hnliche Fehler in anderen Zustandsmaschinen entdeckt Die Probleme wurden wenn auch nicht vollst ndig nach dem glei chen Muster wie bei der oben beschriebenen Zustandsmaschine umgangen Eine Besonderheit stellt die Zustandsmaschine zur Speicheransteuerung dar Diese muss in den IDLE Zustand zur ckkehren da der IDLE Zustand das Ende einer bertragung kennzeichnet Ger t die Zustandsmaschine in einen nicht definierten Zustand geht sie mit dem n chsten Takt in den IDLE Zustand ber 6 2 Ger tetreiber Applikationen greifen auf die Hardware ber die Ger tetreiber Framebuffer und Video4Linux2 zu Beide Ger tetreiber kommunizieren mit den Encoder 87 bzw Decoderchips ber I C Treiber Die Implementierung von Framebuffer treiber und Videl4Linux2 Treiber erfolgte in zwei Schritten Im ersten Schritt wurden ein Grundgeriist der Treiber und die Schnittstellen implementiert Im zweiten Schritt wurde Hardware angebunden Diese Zweiteilung wurde aufgrund von Verz gerungen in der Hardwareherstellung vorgenommen Die Schnittstellen konnten so bereits vor der vollst ndigen Implementierung teil weise getestet und die Funktion mit Standardapplikationen nachgewiesen werden 6 2 1 Framebuffer Die in diesem Abschnitt besprochenen Funktionen und Strukturen sind der Datei lartviofb c entnommen Listings besprochener Funktionen k nnen in Anhang B 2 nachgeschlagen werden Der
43. Mar 2002 GY 0 00000 s 13 47 29 Abbildung A 1 Steuerleitungen nRAS und nCAS bei Datentransfer mit memcpy Framegr sse memcpy Frames s MByte s 320 240 2 172 4 50 5 320 240 3 115 2 50 6 640 480 2 43 1 50 5 640 480 3 28 8 50 6 768 576 2 29 9 50 6 768 576 3 19 9 50 6 Tabelle A 1 Datentransferraten mit memcpy 103 Im Vergleich zur Funktion memepy sind die Ubertragungsraten um 50 hoher Die Ubertragung erfolgt mit Burst Of Eight bei Lesezugriffen und zwei Burst Of Two und einem Burst Of Four bei Schreibzugriffen Framegr sse memcpy asm Frames s MByte s 320 240 2 263 2 77 1 320 240 3 65 8 77 4 640 480 2 43 2 77 1 640 480 3 43 9 77 2 768 576 2 45 8 17 3 768 576 3 30 5 17 3 Tabelle A 2 Datentransferraten mit asmcpy A 1 3 Speicheradressen b ndig Die unterschiedlichen Zugriffsarten lie en vermuten dass die Startadressen der Puffer nicht durch 64 teilbar sind Int99 10 1 5 Transaction Summary Eine berpr fung der angeforderten Pufferadressen best tigte die Vermu tung Das Programm mem2mem wurde um den Parameter align erweitert der die Startadressen der Puffer auf durch 64 teilbare Adressen legt Framegr sse memcpy memcpy asm Frames s MByte s Frames s MByte s 320 240 2 1736 50 8 294 1 86 2 320 240 3 115 2 50 6 195 3 85 8 640 480 2 43 2 50 7 13 3 85 9 640 480 3 28 8
44. ODE gt KERNEL_VERSION 2 5 6 static int lartviofb_set_par struct fb_info info else struct lartvio_par par struct lartvio_par info gt par struct fb_var_screeninfo var amp info gt var static void lartviofb_set_par const void vpar struct fb_info_gen gen endif struct lartvio_par par struct lartvio_par vpar struct fb_var_screeninfo var amp par gt mvar unsigned int ressize rowoffset rowcount unsigned int xborder yborder yvideolen xvideolen if LINUX _VERSION_CODE lt KERNEL_VERSION 2 5 6 endif memcpy amp lartviofb_var amp par gt mvar sizeof struct fb_var_screeninfo PAL if NTSC will be added you will need to change it depends on the standard yvideolen 287 xvideolen 359 par gt encaddr LARTVIO_EADRSO par gt map_dma var gt xoffset var gt bits_per_pixel 8 var gt yoffset get_line_length var gt xres_virtual var gt bits_per_pixel if var yres gt 288 par gt encaddr LARTVIO_EADRSE par gt encaddr LARTVIO_EADRSO get_line_length var gt xres_virtual var gt bits_per_pixel rowoffset 2 var gt xres_virtual var gt xres var gt bits_per_pixel 8 zvideolen var gt xres available border half for a border left and same rigth second half comes from technical manual LartVIO xborder 2 xvideolen 1 var gt xres 2 2 zvideolen va
45. S integrated circuit pPD42S65165 4265165 1997 http www eecg toronto edu lemieux z50 NEC D4265165 pdf Oet97 Frank Oettel Der RAM Speicher Techni cal report TU Chemnitz 1997 http www tu chemnitz de informatik RA kompendium vortraege_97 ram index html 136 Phi99 Phio1 RCO1 Sch02 Sik01 Sim01 Sim02a Sim02b Sto95 Sty02 T 02 Urb99 Wan98 Philips Semiconductors Datasheet SAA 7113 9 Bit video input processor 1999 http www semiconductors philips com acrobat datasheets SAA7113H_1 pdf Philips Semiconductors The PC Bus Spezification Version 2 1 2001 http www semiconductors philips com acrobat various I2C_BUS_SPECIFICATION_3 pdf Alessandro Rubini and Jonathan Corbet Linux Device Drivers O Reilly amp Associates Inc second edition edition 2001 Frank Schwanz LartVIO Softwareinstallation und Programmie rung Tigris Elektronik GmbH Berlin 2002 Axel Sikora Programmierbare Logikbauelemente Architekturen und Anwendungen Carl Hanser Verlag M nchen 2001 James Simmons Linux Framebuffer Driver Writing HOWTO 2001 http linuxconsole sourceforge net fbdev HOWTO James Simmons First new fbdev dri ver Mailingliste linuxconsole dev 2002 http sourceforge net mailarchive forum php thread_id 262694 amp forum id 5379 James Simmons editor Reconstruction ofthe TTY layer for linux to deal with Embedded techology Ottowa Linux S
46. S170 hat einen darstellbaren Bereich von 640 Pixel x 480 Zeilen NTSC National Television System Committee ist ein Farbvideostan dard in den USA Kanada Japan und in Teilen von S damerika PAL ist eine Abwandlung von NTSC vor allem in Europa und Australien verbreitet PAL und NTSC definieren die Farb bertragung auf einem BAS Signal Das entstehende Signal wird FBAS Signal genannt Bei beiden Verfahren wer den zus tzlich zum Y Signal oder Luminanzsignal zwei Farbdifferenzsignale bertragen Es sind die Signale R Y und B Y wobei R und B f r die Farben aus dem RGB Farbsystem stehen Es entspricht dem YUV Farbsystem Y 0 3R 0 59G 0 11B U R Y 0 7R 0 59G 0 11B V B Y 0 3R 0 59G 0 89B F r die digitale Video bertragung wurde von der CCIR Comittee Con sultatif International des Radio Communications eine Empfehlung ausgear 28 beitet die ITU R BT 601 ehemals CCIR601 Als Farbformat wurde das YCbCr Farbsystem entwickelt Das YCbCr Format ist eine skalierte und nullpunktverschobene Variante des YUV Farbsystems Die Helligkeitswerte definiert das Y Signal zwischen 16 und 235 Die Farbsignale Cb und Cr sind zwischen 16 und 240 definiert wobei der Nullpunkt bei 128 liegt Y 0 592 Y 16 U 0 503 Cb 128 V 0 710 Cr 128 Das 4 2 2 YCbCr Format tastet f r jeweils zwei Luminanzwerte Y ein Cb und ein Cr Signal ab blicherweise werden die Signale mit 8 bis 10 Bit Aufl sung abgetastet Ein 8 Bit abge
47. Speichertransferleistung In Abschnitt 2 2 3 wurde die Speichertransferleistung rechnerisch ermittelt Die Berechnungen sollen unter realen Bedingungen getestet werden Das Pro gramm sollte reale Bildgr ssen von einem Speicherbereich in einen anderen Speicherbereich kopieren mit dem Versuch Burst Of Eight Zugriffe auf den Speicher zu generieren Die Zugriffe auf den Speicher m ssen verifiziert wer den A 1 1 bertragung mit memcpy In der ersten Version des Programmes mem2mem wurde der Speicherbereich mit der Funktion memcpy bertragen memcpy ist bereits assembleropti miert Kernel 2 4 18 rmk6 arch arm lib memcpy S Die Speicherzugriffe wurden mit einem Zweistrahl Oszilloskop an den Steuerleitungen nRAS und nCAS berpr ft Die bertragung erfolgte mit Burst Of Four Speicherzugriffen Die Datentransferrate liegt ca 35 unter der berechneten Transferrate Wahrscheinlich verlangsamt der Zugriff auf die Funktion die Geschwindigkeit A 1 2 bertragung mit asmcpy Da die bertragungsleistung von memcpy nicht mit Burst Of Eight erfolg te wurde eine Assemblerroute in das Programm mem2mem integriert Die Assemblerroutine nutzt Multiple Load und Multiple Store Befehle Mit ei nem Befehl werden acht 32Bit Register gleichzeitig geschrieben oder gelesen Die Funktion wird durch bergabe des Parameters asm gestartet 102 eg a hee gt mm 3 80 V 4 20 v 60 0ns 172ns Ch soy Te S00V TH Doone A care 270 V 20
48. Vorgang des Bildeinlesens 2 ist Wird ein Bild gefunden bergibt read ohne Verz gerung das Bild an die Applikationen Da read die Bilder in einen Applikationspuffer kopiert kann der Bildpuffer danach wieder in die Warteschlange zum F llen gestellt werden Der Bildspeicher kann nur ein Bild der Gr e 720x576 fassen Daher ist die eben beschriebene Funktion nur f r Bilder mit dem Format 360x288 Bildpunkte g ltig Wird der Bildspeicher auf die Gr e zweier Bilder im Format 720x576x24Bit erweitert ist die Funktion auch f r diese Bildgr en gew hrleistet Es darf daher nicht verwundern dass nur 12 5Bilder s in der Aufl sung 720x576 eingelesen werden Die Interruptroutine stellt nach je dem Bildeinzug fest dass keine weiteren Bildpuffer zur Verf gung stehen und unterbricht die bertragung Der Vorgang kann fr hestens mit zum bern chsten Bild wieder gestartet werden Bei Ver nderungen der Bildeigenschaften werden die Bildpuffer ber die Prozedur void mmap_unrequest_buffers struct capture_device dev gel scht da nderungen an den Bildeigenschaften auch die Bildpuffer gr e ver ndern k nnen Die Overlayfunktion die das Videobild in den Fra mebuffer schreibt speichert die Bildeigenschaften in eigenen Variablen Der Aufruf der Previewfunktion beeinflu t die Bildpuffer nicht Diese Impelemen tation erm glicht Applikationen in schneller Folge Bilder mit unterschiedli chen Eigenschaften einzulesen Grunds tzlich w r
49. a tentransferraten bersteigen die real erreichbaren Datentransferraten 5 2 Busmasterbetrieb In Abschnitt 2 4 wurde das SA 1100 Multimedia Development Board vorge stellt Die Grafikausgabe auf der Erweiterungplatine SA 1101 Development Board steuert den Speicher im Busmastermodus an Der Prozessor ist bei den Speicherzugriffen unbeteiligt Diese Methode reduziert den Datenstrom um den Datenfluss zum Prozessor In Abbildung 5 3 wurde diese Methode auf die Videomodule angewandt Ein Puffer f r die Nutzung der horizonta len Austastphase wurde bereits ber cksichtigt Der Busmaster verwaltet die Zugriffsanfragen beider Videomodule auf den Speicher und legt die Daten elemente im Speicher ab Die Datentransferrate reduziert sich auf 64 38M Byte s sofern die Bus masterimplementierung die Datentransferraten des StrongARM erreicht Geht man von den Speicherzugriffen des Prozessors aus stehen ca 30 der ge samten Datentransferleistung f r den Prozessor zur Verf gung wenn beide Videomodule aktiv sind 63 5 Speicher an N S g a Es Q RGB24 64 38MByte s Busmaster RGB24 i L MByte s 5 E 5 5 amp a Videomodul Videomodul A YCbCr A YCbCr 25 775 MByte s 25 775 MByte s Abbildung 5 3 Datenfluss der abstrahierten Videomodule mit Puffer zur Nut zung der horizontalen Austastphase Ein DMA Modul koordiniert die Spei cherzugriffe 6
50. a 300 Logikeinheiten des FPGA Danach traten mit verschiedens ten Compilereinstellungen keine Fehler mehr auf Die Module des FPGA Designs wurden danach auf m glichst geringen Resourcenverbrauch an Lo gikeinheiten optimiert Die Fehlerrate der Kompilate sank mit der Veringe rung benutzer Logikeinheiten Nun stellte sich die Frage wie der Nachweis der vollst ndigen Funktion eines Kompilates zu f hren ist Fehler traten mit einigen Kompilaten erst nach einem oder mehreren Tagen auf Die Funk tionstests wurden auf mehrere Wochen ausgedehnt F r diese Tests zeigte sich insbesondere das Programm xvtmmap geeignet da es den Prozessor 97 den Speicherbus und den FPGA stark belastet xvtmmap wurde von Ingo Boersch entwickelt Es ist ein um eine Bildanalyse erweitertes vtmmap xvtmmap verarbeitet einen RGB Bildstrom und extrahiert die Rotanteile des Bildes Ein Fadenkreuz zeigt den Schwerpunkt der ermittelten Rotantei le Das Ergebnis wird auf dem Videoausgabeger t angezeigt Die Protokolle der Langzeittests sind in Anhang C 4 aufgef hrt Ein ent g ltiger Nachweis der uneingeschr nkten Funktion ist ber diese Tests nicht gegeben Die Treiber wurden f r zwei Kernelversionen implementiert Bis zum Ab schluss der Arbeit ver nderten sich die Schnittstellen von Framebuffersub system und Video4Linux2 API Das neue Framebuffersubsystem ist seit der Version 2 5 6 im Kernel integriert Es waren klare Aussagen ber noch zu erwartende nderun
51. abeger te wurde das Framebuffer Device Subsystem geschaffen das seit der Version 2 1 107 fester Bestandteil des Linuxkernel ist Applikationen k nnen ber eine hardwareabstrahierte Schnittstelle auf die Ausgabeger te zugreifen Ein Framebuffer stellt sich als linearer Speicherbereich mit standardisierter Kodierung der Pixelwerte dar 3 4 1 Das aktuelle Framebuffer Subsystem Die Implementation des Framebuffer Device Subsystem entspricht dem seit der Version 2 1 107 im Kernel befindlichen Subsystem Ein Framebuffertreiber ist ein Zeichenger t Es unterst tzt dem entspre chend read und write Operationen auf dem Framebufferspeicher ber die Systemoperation ioctl k nnen die Parameter des Ger tes gelesen und ver ndert werden Zus tzlich bietet die Schnittstelle die M glichkeit den Gra fikspeicher in den Adressraum der Applikation mittels mmap einzublenden Diese Methode ist effizienter als read und write da die Daten nicht von und zum Userspace kopiert werden m ssen Das Framebuffer Device Subsystem wurde im ersten Schritt f r die An bindung des Console Subsystems an framebuffer basierte Ger te geschaffen Das Console Subsystem greift ber den den Framebuffer Console Treiber auf die Framebufferger te zu Da die Console nur max 16 Farben benutzt wurden Farbtabellen eingef hrt die die 16 Farben auf einzelne darzustellen de Farben des Framebufferger tes abbildet Ein geringer Anteil der Ger te unterst tzt solche Farbtabellen
52. ags amp VAL2_BUF_FLAG_QUEUED printk KERN_INFO QBUF buffer jd is already queued n i return 0 30 buf gt vidbuf flags amp V4L2_BUF_FLAG_DONE v4l2_q_add_tail amp dev gt stream_q_capture amp buf gt qnode buf gt vidbuf flags V4L2_BUF_FLAG_QUEUED dev gt ready_to_capture 1 if streaming and buffers was emtpy the grabber will be disabled to get more space on the bus Now we have to enable it again x if dev gt state STREAMING dev gt state READING 40 if dev gt grabber_enabled capture_grab_frame dev return 122 B 3 3 Die Funktion mmap_unrequest_buffers mmap_unrequest_buffers unrequest all mapped buffers dev device structure static void mmap_unrequest_buffers struct capture_device dev int i if dev gt grabber_enabled 10 grabbing_enable dev 0 if dev gt stream_buffers_requested 0 dev gt stream_buffers_mapped return for i 0 i lt MAX_CAPTURE_BUFFERS i dev gt stream_buf i requested 0 dev gt stream_buffers_requested 0 d 123 Anhang C Test protokolle C 1 Framebuffer API Test Testbeschreibung Ergebnis Sichtpr fung Farbtest Aufl sung PAL 720x576 Gr sse normal OK OK OK RGB24 berschreitung der Maximal OK nicht durch nicht durch breite der sichtbaren Aufl sung gef hrt gef hrt 1024x576 Uberschreitung
53. aphisch darstellen kann Jedes dieser Boards zeichnet sich durch seine Autonomie aus Alle Boards sind mit Mikroprozessoren best ckt die auf das entsprechende Board abge stimmt sind Bereits f r eigenst ndige Verwendung sind Anwendungsf lle vorhanden In Kombination mit anderen Boards er ffnen sich weitere An wendungsszenarien Das LART Board ein StrongARM basiertes Embedded Linux Board der Universit t Delft ist die Grundlage von CPU Board und Bildverarbeitungs karte Die um eine Videodigitalisierung und ausgabe erweiterte Bildverar beitungskarte im weiteren BV Board genannt soll die Bildaufnahme bis zur semantischen Analyse des Bil derstroms leisten und ber eine CAN Schnittstelle mit dem rest lichen System kommunizieren BH02 Das Auge des Systems BV Board Das Unternehmen Tigris Elektronik GmbH entwickelte eine Erweiterungs karte f r Videodigitalisierung und ausgabe f r das LART Board im folgen den kurz LartVIO genannt Diese Diplomarbeit umfasst die Konzeption und Entwicklung der Treibersoftware f r die Videodigitalisierung und Vi deoausgabe sowie die Integration der LartVIO Hardware im Umfeld des LART Board Die CAN Busschnittstelle des LartVIO ist kein Bestandteil dieser Diplomarbeit Haupteinsatzgebiet des BV Boards ist die Bildaufnahme und verarbeitung eines Bilderstroms Die Aufgabe der Arbeit war neben der Konzeption und Umsetzung der Software eine umfassende Analyse der Hardware Als Ergeb
54. as DMA Modul tibergibt jeweils 32Bit Werte in denen die RGB Werte unterschiedlich angeordnet sind Teilt man die 32Bit Werte in je 8Bit Werte ergeben sich die in Tabelle 6 1 aufgef hrte Konstellationen Die Vorkommastellen bezeichnen die 32Bit Werte in der Reihenfolge des Einle sens also 0 f r den ersten 32Bit Wert und 2 f r den letzten 32Bit Wert Die Nachkommastellen geben den 8Bit Wert innerhalb der 32Bit Werte an wobei 0 das niederwertigste Byte beschreibt RGB Wert R G B 1 0 0 0 1 02 2 0 3 10 11 3 1 2 13 2 0 4 2 1 22 2 3 Tabelle 6 1 Zuordnung der Farbkan le RGB zu den eingelesenen 32Bit Wer ten Mit drei 32Bit Werten werden vier RGB Werte bernommen die sich in zwei YCbCr Werte bertragen lassen Die RGB Werte 2 und 3 sind ber zwei 32Bit Werte verteilt Der aktuelle Wert wird bei der bergabe zwischen gespeichert ber eine Zustandsmaschine erfolgt die Zuordnung der RGB Wert zu den 32Bit Werten entsprechend Tabelle 6 1 Mit der bernahme des dritten 32Bit Wertes stehen zwei RGB Werte zur Verarbeitung an der dritte und vierte RGB Wert Die Berechnung der YCbCr Werte beginnt mit der bernahme des 32Bit Wertes Der vierte RGB Wert wird einen Takt nach der bernahme des dritten 32Bit Wertes in die Berechnungspipeline bergeben Wie aus den obigen Gleichungen ersichtlich sind f r die Konvertierung eines RGB Wertes neun Multiplikationen und neun Additionen erforderlich F r die Berechnung
55. as LartVIO an ver nderte Hardware leicht anpassen und erweitern Das Ergebnis nach der Implementierung war berw ltigend Bilder mit einer Aufl sung von 720x768 Bildpunkten und 16 Millionen Farben konn ten mit 25 Bilder pro Sekunde von der Kamera bertragen und wieder auf einem TV Ger t ausgegeben werden Der Videocontroller belastet den Hauptspeicherbus dabei mit ca 65 Mehr als ein Drittel steht damit noch Anwendungen zur Verf gung Wird die Videoausgabe abgeschalten stehen Anwendungen 60 zur Verf gung Kleinere Anwendungen mit Bildanalyse konnten 25 Bilder pro Sekunde der Gr e 360x288 mit 16 Millionen Farben verarbeiten Getr bt wird das ber positive Gesamtbild von einigen Kompilierfeh lern die den Videocontroller betreffen Es wurden verschiedene Ma nahmen getroffen die die Fehler minimierten Bis zum Abschlu der Arbeit konnte die Ursache der Fehler nicht vollst ndig gekl rt werden Bedingt durch die 100 se Fehler konnte der Nachweis der Funktionstiichtigkeit des Produktes nicht vollst ndig erbracht werden Die leichte Erweiterbarkeit des Designs ist dadurch beeintr chtigt Zum Einen ist der Funktionsnachweis sehr langwierig zum Anderen war eine Ma nahme zur Minimierung der Kompilerfehler die Reduzierung der Codegr e Ist die Ursache f r die Kompilerfehler gefunden kann das Produkt auch f r den industriellen Einsatz uneingeschr nkt empfohlen werden 101 Anhang A Analyse A 1 berpr fung der
56. bildung 3 8 Struktur des DC Subsystems Clienttreiber abstrahieren die Funktionalit t des jeweiligen Chips Diese Treiber werden ber das Treiberinterface angesprochen Wird ein Clienttrei ber geladen bergibt der i2c core Treiber jedem registrierten Busadapter den Clienttreiber Der Busadapter sucht dann eine Kommunikation mit dem Chip auf seinem Bus Kann eine Kommunikation aufgebaut werden wird der Cli enttreiber am Busadapter registriert 54 Kapitel 4 Anforderungen an das BV Board Durch die aus den Kapiteln 1 2 und 3 gewonnenen Kenntnisse von Hard und Software sind die M glichkeiten und Grenzen bekannt Fiir den Framebuffer und die Videoeingabe wird die zu entwickelnde Funktionalitat festgelegt In Abschnitt 1 1 wurden bereits einige Anforderungen an das Produkt gestellt Ausgehend von den Zielgruppen die das Ger t benutzen k nnen folgende Aussagen getroffen werden Private Anwender und Ausbildung e Die Grundfunktionalit t muss f r Anwender ohne tiefe Einarbei tung erreichbar sein e Die Treiber m ssen kompatibel zu Standardsoftware sein um fer tige Produkte ohne Anpassungen nutzen zu k nnen Forschung und Industie e Forschung und Industie w nschen zus tzlich M glichkeiten der Performanceoptimierung Ihrer Produkte e Die Funktionalit t der Treiber muss erweiterbar sein e F r Portierungen bereits vorhandener Software ist die bereits bei privaten Anwendern und Ausbildung erw hnte Kompatibilit t zu Standa
57. chert Der Framebuffer sollte mindestens das gr sste Bild der Videoeingabe dar stellen k nnen Da die bertragung eines vollen PAL Bildes den Bus entspre chend stark belastet ist eine kleinere Darstellung ebenfalls sinnvoll Deswei teren muss der Framebuffer abschaltbar sein Im Gegensatz zur Videoeingabe definiert sich die Dauer Hardwarenutzung nicht ber die Nutzung des Trei bers Wenn eine Applikation den Zugriff auf den Framebuffer beendet muss dieser weiterhin das Bild anzeigen Zusammengefasst werden folgende Anfor derungen an die Videoeingabe gestellt Bildformate e mindestens die Maximalgr sse der Videoeingabe also 720x576 58 e Interlacing des Videobilder e optional QSIF 360x288 Farbformate e RGB24 e optional Speicherung in Planes sofern die Videoeingabe diese Funk tionalit t erh lt Performance e Der Prozessor muss gen gend Leistungsreserven f r die Verarbei tung der Bilder haben Die Anforderung versch rft sich gegen ber der Videoeingabe da sowohl Videoeingabe Videoausgabe und Bildverarbeitung gleichzeitig arbeiten Bildeigenschaften e optional Helligkeit Kontrast S ttigung einstellbar Das Frame buffersubsystem stellt keine Schnittstelle f r solche Einstellungen zur Verf gung Zugriff auf Bilder e eine einfache Methode Bilder auszugeben und zur ckzulesen e wahlfreien Zugriff auf den Grafikspeicher Leistungsaufnahme e die Videoausgabe muss an und abschaltbar sein e o
58. chliessen sich aus Treten die Signale ENC_DMA und DEC_DMA zeitgleich auf wird das Videoausgabemodul zur ckgestellt Abbildung 6 2 verdeutlicht Arbeitsweise der Zustandsmaschine f r die DMA Anfragen Die erste Version der Implentierung zeigte h ufig fehlerhaft eingelese ne und geschriebene Werte Messungen an den Adress und Steuerleitungen 83 zeigten kurze Zwischenimpulse wie in Abbildung 6 3 zu sehen Diese Impul se treten durch unterschiedliche Verz gerungszeiten einzelner Logikeinheiten auf Es ergaben sich kurzzeitig unerw nschte Zust nde die auf die Aus gangsleitungen geschalten wurden Die Adress Daten und Steuerleiten die mit dem High Speed Bus verbunden sind wurden ber D Flipflops gepuffert Die Signale dec_read und enc_write mussten entsprechend um einen Takt verz gert werden Abbildung 6 3 Zwischenzust nde auf den Adress und Steuerleitungen 6 1 2 Wandlung der Farbbereiche Beispielhaft f r die Videobearbeitungsmodule wird die Konvertierung von RGB nach YCbCr beschrieben Jack beschreibt die Konvertierung in Jac96 YCbCr Color Space mit den Formeln 84 Y 0 257R 0 504G 0 098B 16 Cb 0 148R 0 291G 0 439B 128 Cr 0 439R 0 368G 0 071B 128 in denen bereits eine Angleichung an die Wertebereiche des RGB24 For mats enthalten ist Fiir die Konvertierung von RGB nach YCbCr sind zwei Pixel RGB 48 Bit erforderlich die in einen 16Bit YCbCr Werte gewan delt werden D
59. coder so we need to init it again 116 10 20 30 40 par gt adv gt driver gt command par gt adv ADV7170_INIT amp arg arg VIDEO_MODE_PAL par gt adv gt driver gt command par gt adv SET_VIDEO_NORM amp arg return 0 50 B 2 4 Die Funktion lartviofb_encode_fix vr lartviofb_encode_fiz fill in the fix structure based on the values in the par structure fix fb_fix_screeninfo which will be filled vpar parameter structure gen fbinfogen includes all parameter structures KR RR Returns negative errno on error or zero on success eg static int lartviofb_encode_fix struct fb_fix_screeninfo fix 10 const void vpar struct fb_info_gen gen struct lartvio_par par struct lartvio_par gen gt info par memset fix 0 sizeof struct fb_fix_screeninfo strepy fix gt id MODULENAME fix gt line_length get_line_length lartviofb_var xres_virtual lartviofb_var bits_per_pixel fix gt smem_start par gt map_dma fix gt smem_len par gt videomemorysize 20 fix gt type FB_TYPE_PACKED_PIXELS fix gt type_aux 0 fix gt visual FB_VISUAL_TRUECOLOR fix gt ywrapstep 0 fix gt xpanstep 0 fix gt ypanstep 0 fix gt accel FB_ACCEL_NONE return 0 B 2 5 Die Funktion lartviofb_encode_var lartviofb_encode_var return current var structure var fb_var_screeninfo which will be filled vpar parame
60. conds time float c12 cl1 float CLOCKS_PER_SEC printf FRAMESIZE d d 4d d Bytes n frames j height frames j width frames j colorbytes frames j height frames j width frames j colorbytes printf TIME to copy d FRAMES f n FRAMES_PER_SECOND SECONDS time printf FRAMES PER SECOND n float FRAMES_PER_SECOND SECONDS time printf MB PER SECOND n float FRAMES_PER_SECOND SECONDS framesize time 1024 1024 2 A free fb_in free fb_out return 0 108 140 150 160 Anhang Listings B B 1 AHDL Quellcode B 1 1 YCbCr_YCbCr tdf Auszug Subdesign Section SUBDESIGN YCbCr_YCbCr data 31 0 INPUT YCbCr Daten data en INPUT Signal f r neue Daten am Eingang reset INPUT R cksetzten der Logik Parameter FULLSIZE INPUT 0 Am Ausgang soll nur jeder zweite Pixel 10 ausgegeben werden Halfsize High Misc signals enable INPUT Enable Decoder Logik Clock INPUT Takt q rd OUTPUT Neues Datenwort liegt bereit 1 Takt q 31 0 OUTPUT Datenwort in der Form YCbCrYCbCr 20 Variable declaration VARIABLE Y1 7 o NODE Y2 7 0 NODE Cr 7 0 NODE Cb 7 o NODE 109 TOGGLE_SM MACHINE WITH STATES FIRST SECOND 30 Implementing design BEGIN _ RR VOhOr gt YObCr Konvertierung H
61. d bertragen werden existieren 43 auf dem LART Board daher nur bis zum n chsten Reset Eine weitere Methode den Flash als Festplatte anzusprechen erm glicht das Jornaling Flash File System Vorteil dieser Methode ist die persistente Speicherung der Daten Die 4 MB Flash ROM des LART Boards abz glich Bootloader und Kernelimage erlauben dann nur ein minimales Linuxsystem da im Gegensatz zur Ramdisk das Journaling Flash File System die Daten bisher nicht komprimiert Diese Option soll in einer der n chsten Versionen hinzukommen 3 2 Linuxkernel Der Linuxkernel stellt den eigentlichen Betriebssystemkern die Schnittstelle zur Hardware dar Begonnen als Programmier bung des Informatikstudenten Linus Torwald stellt der aktuelle Kernel mit knapp 140 MB Sourcen ein be achtliches Projekt dar Die Zahl der Entwickler ist kaum mehr berschaubar Die Entwicklung des Betriebssystems l uft in mehreren Str ngen stable kernel werden von Linus Torvald f r die allgemeine Nutzung als ge n gend stabil erachtet Stable Kernel erhalten immer eine gerade Minor Nummer also 2 0 oder 2 4 development kernel entspricht den Entwicklerversionen Die Minor Nummern sind immer ungerade Die Entwicklungsreihe ist h ufig weitreichenden Anderungen unterzogen Viele Entwicklungen neuerer Kernelversion werden auf ltere Versionen por tiert sofern die nderungen nicht die Stabilit t des Kernel gef hrden und die nderungen in den Schnittstellen vo
62. d abschaltbar sind Die Abschaltung des Taktes versetzt die Schaltkreise in einen Ruhezustand 2 3 1 Analoge und digitale Video bertragung F r das Verst ndnis der Kodierung und Dekodierung von Videosignalen ist ein kurzer Einblick in die Videosignaltechnik und digitale Videostandards notwendig Die Techniken werden in Sto95 BHK96 und Jac96 ausf hrlich beschrieben Videosignale enthalten Bildinhalt und Zeitinformationen Zu den Zeitin formationen geh ren die horizontalen und vertikalen Synchronisationsimpul se Sie markieren den Anfang einer Zeile bzw den Beginn eines Halbbildes Die Bilder werden in der Fernsehtechnik im Zeilensprungverfahren interla ced bertragen Dabei wird das Bild in zwei Halbbilder geteilt Das erste Halbbild enth lt alle ungeraden Zeilen das zweite Halbbild alle geraden Zei len Nach CCIR Norm besteht ein Bild aus 625 Zeilen wovon 575 Zeilen Bildinformationen enthalten Die Bildwiederholrate liegt bei 25Hz Eine Zei le ist 64ps lang Davon werden 52ns f r die bertragung der Bilddaten einer Zeile genutzt Die verbleibenden us werden f r die horizontale Synchoni station verwendet Das amerikanische RS170 Videosignal enth lt 525 Zeilen Die Bildwieder holrate liegt bei 30Hz Das Seitenverh ltnis von 4 3 gilt f r beide Standards Das Seitenverh ltnis gibt an wie die Aufl sung eines Bildes aufgeteilt ist Bei CCIR liegt diese Aufl sung bei 768 Pixel x 576 Zeilen im darstellbaren Bereich R
63. daten des Videodecoders unter Umgehung von Hauptspeicher und Prozessor ist m glich in dem die Videosynchronsignale und Videodaten des Videodeco ders direkt an den Videoencoder bertragen werden Der ADV7171 arbeitet dann im Slavemodus Sind die Grafikdaten wahlfrei verf gbar kann man auf die erzeugten Videosynchronsignale des ADV7171 reagieren und die ent sprechenden Grafikdaten dem Videoencoder bermitteln Der Videoencoder muss dazu in den Mastermodus versetzt werden Implementiert wurde ein dreistufiges Powermanagement Der Low Power Mode reduziert die Leistung der DACs um 45 Im Sleep Mode wird der Stromverbrauch auf 200nA reduziert Alle Funktionen bis auf den DC Bus werden abgeschaltet F r die Konfiguration der internen Register bringt der ADV7171 einen DC Bus mit Uber das Pin ALSB kann die 7Bit Slaveadresse auf 0x25 oder 0x26 eingestellt werden 2 3 4 TC Bus Videoencoder und Videodecoder nutzen fiir die Konfiguration der internen Register den I C Bus Alle Register mit Ausnahme des Adressierungsregis ters k nnen gelesen und geschrieben werden Die Adressierung der Register ist bei beiden Chips gleich und wird im letzten Teil dieses Abschnitts vorge stellt Der DC Bus wurde von Philips Phi01 f r die Kommunikation zwi schen integrierten Schaltkreisen entwickelt Eingesetzt wurde er zuerst in der Fernseh und Videotechnik Die St rken dieses seriellen Zweidrahtbusses liegen in der einfachen Kommunikationsschicht und de
64. dos VIDIOC_REQBUFS und VIDIOC_QUERYBUF 76 die M glichkeit mehrere Bildpuffer zu durch den Treiber verwalten zu lassen Die Bildpuffer werden zum F llen dem Treiber ber das ioctl Kommando VIDIOC_QBUF gestellt und nach vollst nder Bild bertragung mit VIDIOC DQBUF wieder entnommen VIDIOC_QBUF und VIDIOC_DQBUF verwenden dabei Strukturen die den ensprechenden Bildpuffer und das eingelesene Bild beschrei ben Gestartet und gestoppt wird die bertragung mittels VIDIOC_STREAMON und VIDIOC_STREAMOFF ioctl Kommandos Die Applikation kann sich ber die poll Funktion den Stand des Einle seprozesses abfragen oder warten bis das n chste Bild bertragen wur de Die optionale Einblendung des Bildes in den Framebuffer wird ber die ioctl Kommandos VIDIOC_G_FBUF VIDIOC_S_FBUF VIDIOC_G_WIN VIDIOC_S_WIN und VIDIOC_PREVIEW implementiert Die Eigenschafen Framebuffer muss mit dem ioctl Kommando VIDIOC_S_FBUF gesetzt werden VIDIOC_S_WIN beschreibt die Gr sse und Lage des Videobildes im Framebuffer VIDIOC_PREVIEW star tet und stoppt die Einblendung des Videobildes F r die Einblendung wird das einfachste Verfahren des direkten berschreibens des Frame bufferbereiches gew hlt Overlaying oder Clipping m ssten im FPGA zus tzlich integriert werden Die Einstellung von Bildgr sse und Farbformat f r die Funktionen read und mmap erfolgt ber die ioctl Kommandos VIDIOC_G_ FMT und VIDIOC_S_FMT Die Previewfunktion bes
65. e sprochen werden Der ACEX1K bietet nicht gen gend Pufferspeicher um die Farbkan le einzeln zu puffern Abbildung 5 4 zeigt den Datenfluss und die Anordnung der Module Eine stufenlose Skalierung auf der Videoeingabeseite wurde weiterhin als optional angesehen sollte beim Entwurf aber ber cksichtigt werden Stehen nach der Implementierung noch gen gend Resourcen zur Verf gung kann die Skalie rung nachtr glich implementiert werden Diese Aussage trifft auch auf das Cropping zu Die Skalierung auf halbe Bildgr sse in der Videoausgabe wur de mit aufgenommen Sie reduziert den Datenstrom der Videoausgabe auf 65 dem Hauptspeicherbus um die H lfte Die einzelnen Pixel m ssen nur als Doppelpixel an den Encoder bergeben werden Im Weiteren wird die Funktion der einzelnen Module des Entwurfs bespro chen Die Schnittstellen der Module sind in KS02 ausf hrlich beschrieben 5 3 1 DMA Modul Das DMA Modul muss die Speicherzugriffsanfragen des Videoeingabemoduls und des Videoausgabemoduls verwalten Es muss sicherstellen dass jedes der beiden Module gen gend bertragungsresourcen erh lt Andernfalls w re Datenverlust und damit der Verlust des aktuellen Bildes die Folge Neben der Koordinierung der Zugriffsanforderungen muss das DMA Modul die DRAM Bausteine im Schreibenden und Lesenden Modus ansteu ern Da die Adressen in einer Bildzeile fortlaufend sind kann der Burst auf bis zu einer Bildschirmzeile verl ngert werden
66. e Adresse zum Lesen und zum Schreiben angegeben Diese entsprechen der 7 Bit Adresse und dem Read Write Flag Neben der 7 Bit Adressierung existiert eine Er weiterung f r 10 Bit Adressen Encoder und Decoderchip interpretieren das erste Datenbyte nach der Slaveadresse als Subadresse Mit dieser Erweiterung werden die internen Re gister des jeweiligen Chips addressiert S Slave Adresse 7Bit W Ack Subadresse 8Bit Ack Datenbyte Ack P Sr nr Datenbyte Acknowledge _ Abbildung 2 10 DC Schreiboperation bei SAA7113 und ADV7110 7111 Die Subadresse wird in einem chipinternen Register gespeichert und nach der Ubertragung eines Datenbytes inkrementiert 33 S Slave Adresse 7Bit W Ack Subadresse 8Bit Ack Sr Slave Adresse 7Bit R Ack Datenbyte Ack P Sr KC E vom Master nr Datenbyte Acknowledge Abbildung 2 11 DC Leseoperation bei SAA7113 und ADV7110 7111 2 3 5 Der Videocontroller ACEX1K Die Verbindung zwischen Speicherbus des Lartboards und den Videobau steinen sowie dem CAN Bus Controller bernimmt ein FPGA ACEX IK Alt01 der Firma Altera FPGAs Field Programmable Gate Arrays sind komplexe programmierbare Logikbausteine deren Architektur auf einzelnen Funktionsbl cken beruht die in einer regelm igen Struktur angeordnet sind Die Funktionalit t von FPGAs wird im Wesentlichen durch die Programmie rung der Verbindungsleitungen zwischen den
67. e Aufgabenstellung ver wies f r die Umsetzung der Treiber auf die Kernelsubsysteme Framebuffer und Video4Linux Die Subsysteme wurden in der aktuell stabilen Version und der in Entwicklung befindlichen Version betrachtet Beide Subsysteme waren f r die Umsetzung einer Videodigitalisierung und Videoausgabe geeignet Unter Ber cksichtigung der anvisierten Nutzergruppen und der Ergebnis se aus der Untersuchung von Hard und Software wurden die Anforderungen an die Videodigitalisierung und ausgabe ausgearbeitet Hauptanforderungen waren e 720x576 und QSIF 360x288 bei 25 Bildern s e Deinterlacing der Videobilder e Farbformet RGB24 andere Formate optional e Der Prozessor muss gen gend Leistungsreserven f r die Verarbeitung der Bilder haben Anhand der Anforderungen wurde die bertragung der Videodaten ber den Hauptspeicherbus untersucht Der erste Ansatz ging davon aus dass die Funktionalit t in den Betriebssystemtreibern integriert wird Die ben tigten bertragunsraten f r den Videostrom lagen ber den maximal m glichen 99 bertragensraten des Hauptspeicherbus Das Konzept wurde so berarbeitet dass der auf dem LartVIO integrierte Videocontroller die Ubertragung ohne Beteiligung des Prozessors erledigt Die maximale Ubertragunsrate konnte mit dieser L sung um zwei Drittel reduziert werden Da der Prozessor an der bertragung der Videodaten nicht mehr beteiligt sein sollte mussten alle den Videostrom verarbeitenden Funk
68. e en Datenfluss der abstrahierten Videomodule Der Prozessor ver arbeitet den Videostrom lt 4 444 EE eh 2 e 2044 aktive Bild und Austastzeiten eines Halbbildes Datenfluss der abstrahierten Videomodule mit Puffer zur Nut zung der horizontalen Austastphase Ein DMA Modul koordi niert die Speicherzugriffe 2 nn ann Entwurf des FGPA Interlacing und Deinterlacing Abh ngigkeit der F llzeit von FIFO Gr e und F llsignal Datenfluss Videoeingabe Die Schnittstelle Videobearbeitung Datenfluss Videoausgabe e bersicht ber das Treiberdesign Zustandsmaschine fuer den Speicherzugriff e Zustandsmaschine fuer den Zugriff auf den DMA Zwischenzust nde auf den Adress und Steuerleitungen Vorgang des Bildeinlesens 2 2 22 a Steuerleitungen nRAS und nCAS bei Datentransfer mit mem ENER a Bere ee ee ee ie are Tabellenverzeichnis 1 1 2 1 2 2 2 3 2 4 2 5 2 6 2 7 5 1 6 1 A l A 2 A 3 Anwendungsszenarien fiir das BV Board nach BH02 Anwen dungsszenarien 204 uw Cee ee Oo ee RO EGS 10 Schnittstellen des LART Boards 15 Alternative Funktionen der GPIOs am High Speed Connector 18 DRAM Konfigurationregister Int99 10 2 1 DRAM Configu ration Register MDCNFG 2 4 4 6 4 4 5 45245 4 23 DRAM Wellenform Register im Kernel 2 4 18 24 Daten bertragung des 4 2 2 Digital Component Video 8 B
69. e es auch m glich Puffer 220ms entsprechen der bertragungszeit eines Halbbildes 92 mit verschiedenen Bildeigenschaften zu erzeugen und fiillen zu lassen Die Video4Linux2 API untersttizt aber keine verschiedenen Bildpuffer In Abschnitt 5 3 4 wurde auf die Implementierung eigener Farbkonver ter und anderer Videobearbeitungsmodule im FPGA eingegangen Eigen implementierungen muss der Video4Linux2 Treiber nat rlich ebenfalls un terst tzten F r reine Farbkonverter wurde eine Struktur static struct v412_fmtdesc capfmt colfmt colorstring Pixel format see videodev h Format flags depth reserved 0 RGB 24 R G B VAL2_PIX_FMT_RGB24 0 24 0 0 1 YUV 4 2 2 Y U Y V V4L2_PIX_FMT_YUYV V4L2_FMT_CS_601YUV 16 0 O could be in one of the next releases of FPGA 2 Greyscale 8 V4L2_PIX_FMT_GREY 0 8 0 O de angelegt Die Struktur muss um das neue Farbformat erweitert werden Ein Beispieleintrag f r Graustufenbilder liegt als Kommentar vor Uber die Eintrage der Struktur werden die Priifungen und Berechnungen fiir die Hard wareeinstellungen vorgenommen Die erste Variable der Struktur colfmt muss mit der Nummer des Multiplexereingangs im FPGA entsprechen Die Farb konverter m ssen ebenfalls die Skalierung auf halbgro e Bilder unterst tzen Eine Anpassung des Treibers an eigene Farbraumkonverter sollte keine Pro bleme bereiten 6 2 3 T
70. eift auf den Treiber im non IO Modus zu Der gleichzeitige Zugriff mehrerer Ap plikationen auf den Video4Linux2 Treiber konnte durch das Programm ebenfalls berpr ft werden Die Schnittstellen wurden entsprechend der Dokumentationen gepr ft Programmierung der Treiber und der Tests lagen in der Hand einer Person Eine falsche Interpretation der Schnittstellendokumentation konnte nicht aus geschlossen werden Standardapplikationen sollten bisher durchgef hrte Tests untermauern F r den Framebuffertreiber wurde die Bibliothek f r graphi sche Oberfl chen QT Embedded der Firma Trolltech kompiliert und auf der Ramdisk des LART Board installiert Die Bibliothek enth lt eine Reihe von 96 Beispielprogrammen aus denen das Programm hello ausgew hlt wurde Das Programm 6ffnet ein Fenster und stellt einen sich bewegenden Text dar Der XServer XFree86 war zu gro fiir die 8MByte Ramdisk des LART Board Fiir die Video4Linux2 Schnittstelle wurde kein Programm gefunden das oh ne XServer oder weitere Bibliotheken funktioniert Die Funktion der Module des FPGA wurde iiber Wellenformsimulationen berpr ft Die Eingangssignale des jeweiligen Moduls werden in der Wellen formsimulation definiert Ein Simulator berechnet dann die Ausgangssignale Der in Quartus II integrierte Simulator kann die logischen Funktionen und die zeitliche Verschiebung der Signale anhand des Kompilats berechnen und anzeigen Anhang C 3 zeigt einen kleinen Teil der Wellenform
71. eil dieses Kapitels stellt das Betriebssystem und Grund lagen f r die Treiberentwicklung vor Im zweiten Teil werden das Framebuffer Subsystem und Video4Linux vorgestellt In Abschnitt 2 3 wurde als Kommu nikationslayer zu Encoder und Decoder der I C Bus vorgestellt Da bereits ersichtlich ist dass f r den I C Bus ebenfalls Treiber erstellt werden m ssen befasst sich der letzte Abschnitt mit dem I C Subsystem im Linuxkernel Entsprechend der Aufgabenstellung werden sowohl aktuelle als auch in Ent wicklung befindliche Schnittstellen untersucht 3 1 Das Betriebssystem des LART Board Auf dem LART Board startet Linux als Betriebssystem Es entspricht dem Standardlinuxkernel erweitert um einen Patch von Russel King Der Patch beinhaltet nderungen und Erweiterungen f r die ARM Architekturen die bisher noch nicht in den Kernel eingeflossen sind F r den StrongArm Pro zessor werden eine ganze Reihe von Implementierungen unterst tzt Neben dem LART Board geh ren dazu unter anderem das Itsy Board eine Beispie limplementierung von Compaq und Personal Digital Assistants PDAs von Compaq Hewlett Packard und Sharp Der Bootloader blob kopiert das Kernelimage das im Flash ROM gespei chert ist in den RAM Bereich und startet das gepackte Kernelimage Beim Bootvorgang entpackt der Kernel eine ebenfalls auf dem Flash ROM befind liche komprimierte Ramdisk Die Ramdisk enth lt das Dateisystem Dateien die w hrend des Betriebs auf das LART Boar
72. einem Signal Das FBAS Format ist das bei Kameras 29 am h ufigsten verwendete Format Die maximal vier Videoeing nge werden ber einen analogen Schalter ausgew hlt Es wird nur jeweils ein Videostrom gleichzeitig verarbeitet Unterst tzt werden die Videostandards CCIR und RSA170A und die Farb bertragungssysteme PAL NTSC und SECAM Der Decoder erkennt automatisch Videostandard und Farb bertragunssystem und schaltet in den entsprechenden Modus Die Videonormen k nnen bei abgeschaltener auto matischer Erkennung auch manuell eingestellt werden Helligkeit Kontrast S ttigung und Farbverschiebung sind ebenfalls ver nderbar Die Videodaten werden ber die Ausg nge VPO 7 0 im YCbCr 4 2 2 For mat siehe Abschnitt 2 3 1 bertragen Tabelle 2 5 zeigt die Folge der Daten am VPO Bus Mit Beginn der Zeile wird der Zeilenreferenzcode bertragen gefolgt von 720 Pixelwerten im YCbCr 4 2 2 Format Die Daten liegen mit der steigenden Flanke des Pixeltakts LCC an F r Videosynchronsignale stehen zwei Steuerleitungen RTSO und RTS1 zur Verf gung die auf verschiedene Signale eingestellt werden k nnen Der SAA7113 wird ber einen 24 576M Hz Quarzgenerator mit dem n tigen Takt versorgt Uber PLL Schaltungen wandelt der SAA7113 den Takt in die 27 Mhz Pixelfrequenz Ein fehlender Takt am Schaltkreis initiert einen Reset Alle Ausg nge werden in den hochohmigen Zustand versetzt Der Schaltkreis muss danach neu initialisiert werden Die Konfigu
73. en 81 digen Zugriff auf den Hauptspeicher Danach gelangt der Prozessor in einen Wartezustand Die Erzeugung der notwendigen Refreshzyklen fiir den DRAM Speicher bernimmt weiterhin der Prozessor Die Notwendigkeit eines Refresh stellt er ber einen internen Counter MDCONFIG siehe Int99 10 1 2 Memo ry Configuration Register fest dessen berlauf in einem Refreshflag ge speichert wird Der Refresh wird dann beim n chstm glichen Zugriff aus gef hrt Erh lt der Prozessor den Bus mit dem Lowsignal von MBREQ zur ck wird der DRAM mit dem n chsten Buszugriff aufgefrischt Der FPGA kann den Bus daher maximal die Zeit zwischen zwei Refreshzyklen beanspru chen Danach muss der Prozessor mindestens f r kurze Zeit den Buszugriff zur ckbekommen um notwendige Refreshzyklen zu generieren Das Busmasterdesign teilt sich in die Verwaltung der Busanforderungen und die Erzeugung der Steuersignale f r den Speicher Videoeingabe und Videoausgabe besitzen je einen Zwischenspeicher die ab einem vom Zwi schenspeicher bestimmten Punkt bedient werden m ssen MBREQ DMA Arbiter IDLE m newRow0 owt newRow AND DMAStop DMAStop DMAStop Release berg nge ohne Bedingung gehen zum n chsten Takt in den Folgezustand ber sofern keine andere Bedingung zutrifft Abbildung 6 1 Zustandsmaschine fuer den Speicherzugriff Die Signale f r den Hauptspeicher wurden mit einer endlichen Zustands 82 maschine erzeugt Die Zu
74. en mit minimalen nderungen brachten unterschied liche Ergebnisse Diese reichten von einem funktionierenden Resultat und einem fehlerhaften Resultat bis zu zwei fehlerhaften Resultaten mit Fehlern in vollst ndig unabh ngigen Modulen Ein Fehler das Blockieren des Farbraumkonverters YCbCr_RGB auf der Videoeingabeseite wurde n her untersucht Das Modul enth lt eine Zu standsmaschine die die Zuordnung der RGB Werte zu den 32 Bit Daten worten bernimmt Diese Zustandsmaschine geriet nach einiger Zeit in ei nem nicht definierten Zustand Da f r diesen nicht definierten Zustand keine berleitung in einen anderen Zustand existierte blockierte die Zustandsma schine in dem Zustand Der Compiler bildet Zustandsmaschinen als Regis terwerte ab Die beschriebene Zustandsmaschine hatte vier Zust nde die der Compiler in einem 4Bit Wert abbildete Das Problem des Blockierens wurde durch die Definition eines Zustandes als allgemeiner Zustand gel st Daf r wurde der Anfangszustand verwendet Die Zustandsmaschine enth lt dann n 1 definierte Zust nde und einen sonstigen Zustand der ber alle restli chen Zust nde einschlie lich nicht definierter Zust nde gilt Dem Autor ist bewusst das diese Problembehandlung keine vollst ndige L sung ist Warum die Zustandsmaschine in einen nicht definierten Zustand ger t konnte nicht vollst ndig gekl rt werden Der Autor vermutet Einfl sse von anderen nahe liegenden Verbindungsleitungen die die
75. envolumen auf ein Viertel Die Hardware sollte den An spr chen der Bildverbeitung entsprechend unterschiedliche Bildgr ssen zur Verf gung stellen k nnen Die Bildverarbeitung l st dieses Problem mit Regions of Interest ROI grenzt also den Bildbereich ein Neben der Bildgr sse stellt sich die Frage welches Farbformat f r Bildverarbeitungssoftware am geeignetsten ist Im Computerbereich dominiert das RGB Format Es nutzt die Farben Rot Gr n und Blau zur Beschreibung von Farbe und Helligkeit f r einen Bildpunkt In der Videotechnik ist das YUV Format verbreitet Es beschreibt einen Bild punkt ber die Helligkeit und zwei Farbdifferenzen Der Vorteil f r die Bild verarbeitung liegt in der Trennung von Helligkeit und Farbe Unterschiedlich ausgeleuchtete Objekte sind in den Farbkan len von den Helligkeitsschwan kungen nicht so stark betroffen wie das RGB Format F r die Bildverarbei tung werden h ufig die Farbmodelle HSI und HSV eingesetzt Der Farbton wird in dem Hue Kanal bespeichert der den Winkel im Farbkreis angibt Die S ttigung S gibt an wie stark der jeweilige Farbton ausgepr gt ist V bzw Pixel Bildpunkt 56 I entsprechen dem Helligkeitswert Die vollst ndige Trennung des Farbtons erleichtert die Segmentierung ohne gr sseren Aufwand bei der Vorverarbei tung Das Farbformat h ngt stark vom Einsatzgebiet der Bildverarbeitung ab So ist f r die Erkennung von Schrift ein Graustufenbild ausreichend Es verring
76. er Treiber muss f r Standardanwendungen einfach gehalten sein Forschung und Entwicklung an Hochschulen und Industrie ben tigen ein Produkt das Raum fiir komplexe und anspruchsvolle Entwicklungen bietet Diese Zielgruppen w nschen Erweiterbarkeit und Flexibilit t des Produktes Hard und Software sollen erweiterbar und ver nderbar sein Das Treiberde sign sollte diese Anspr che ber cksichtigen In BH02 Anwendungsszenarien werden Einsatzgebiete f r verschiedene Kombinationen der Module des RCube benannt Die Anwendungsgebiete in denen das BV Board zum Einsatz kommen soll sind BV Autonomes Bildverarbeitungs System BV CPU Intelligente Kamera Aksen CPU BV R Cube Roboterkernel f r Serviceroboter Tabelle 1 1 Anwendungsszenarien f r das BV Board nach BH02 Anwen dungsszenarien In der Aufgabenstellung enthalten ist das Haupteinsatzgebiet Bildverar beitung Bildverarbeitungen stellen hohe Anspr che an Prozessor und Da tenbus Es wird zu pr fen sein welche M glichkeiten die Hardware in Bezug auf Bildgr sse Farbformat und Performance bietet Das BV Board besitzt einen Videoausgang der Video und Grafikdaten auf den Bildschirm bringen soll Die Versuchung liegt nahe diesen Videoaus gabeport als Grafikkarte zu implementieren und die Einsatzm glichkeit auf Standardanwendungen auszudehnen In wie weit sich sich diese Ideen umset zen lassen h ngt vor allem von der Hardware ab Von Bedeutung ist auch das Zusammenspie
77. er dem Videocontroller verbirgt sich ein rekonfigurierbarer Schaltkreis Es handelt sich um einen Field Programmable Gate Arrays im weiteren kurz FPGA Videoencoder und decoder sind ebenfalls mit dem Videocontroller verbunden LART Board Video Video CPU SA1100 controller Encoder Video OUT KR o H D D 32 OE 48 En ale Video Decoder 4x Video IN Flash ROM 4 MB Abbildung 2 1 Blockschaltbild des BV Boards Durch die Verwendung eines rekonfigurierbaren Schaltkreises als Video controller kann das Hardwaredesign dem Anwendungsgebiet angepasst wer den Der Vollst ndigkeit halber soll der CAN Controller des LartVIO nicht unerw hnt bleiben der ebenfalls mit dem Videocontroller verbunden ist Er wird jedoch nicht Gegenstand in dieser Arbeit sein Wie im Bild 2 1 ersichtlich l uft die Kommunikation zwischen dem LART Board und dem LartVio vollst ndig ber den Videocontroller 13 2 2 LART Board Das LART Board ist ein StrongARM basiertes Embedded Linux Board das an der Universit t Delft entwickelt wurde Die Schaltpl ne Lar00 sind als Open Hardware frei verf gbar Boards k nnen entsprechend selbst gebaut werden Das LART Board wurde speziell f r hohe Leistung mehr als 200 MIPS bei kleinem Stromverbrauch weniger als 1 W entwickelt Das LART Board ist ein 10x7 cm gro es Mainboard mit StrongARM CPU 32 MB RAM und 4 MB Flash Speicher Abbildung 2 2 LART Board Oberseite a
78. ert sind und die Gefahr besteht das LART Board zu zerst ren Der Powerste cker ist so konzipiert dass ein Vertauschen der Spannungspotentiale durch falschen Aufstecken nicht m glich ist Werden die Spannungspotentiale an der Stromquelle vertauscht kommt es ber D4 Lar00 LART Power suply zu einem Kurzschluss Die Stromquelle sollte daher eine Strombegrenzung besitzen Der Reset Stecker f hrt neben dem Reset Signal noch eine Masseanschluss da das Reset Signal Low Aktiv ist Hier kann ein einfacher Taster angeschlos sen werden Die seriellen Schnittstellen Das LART Board verf gt ber f nf serielle Schnittstellen Int99 Peripheral Control Module 11 wovon zwei RS232 Schnittstellen Serial Portl Serial Port3 seitlich herausgef hrt wurden Die bertragungsraten lassen sich von 56 24 bps bis 230 4 Kbps einstellen Daneben k nnen ber J3 eine USB Schnittstelle max 12 Mbps ein IRDA Port max 4 Mbps sowie einen Multimedia Communication Port MCP abgegriffen werden bps Bits per second 15 Das JTAG Interface Das JTAG Interface ist eine standardisierte Schnittstelle zum Testen von Hardware Mit JTAG kompatiblen ICs ist es m glich durch seriellen Zu griff ber den JTAG Test Access Port TAP auf jeden einzelnen I O Pin des Chips sowohl schreibend als auch lesend zuzugreifen Boundary Scan Der Zugriff auf den unprogrammierten Flash ist ein Beispiel f r die Nutzung des JTAG Interfaces unerl sslich f
79. ert gegen ber anderen Farbformaten das zu bearbeitende Datenvolu men Eine Aussage zu treffen welches Farbformat f r die Bildverarbeitung ge eignet ist muss der jeweiligen Implementation berlassen werden Obwohl das RGB Format die Segmentierung erschwert ist es doch das in der Com puterindustrie verbreitete Format F r dieses Format spricht ebenfalls dass der Framebuffer mit diesem Format arbeitet Ein weiterer Unterschied besteht in der Speicherung der Farbkan le Die Farbkan le k nnen als Folge f r jeden Pixel oder in Feldern Planes abgelegt werden Bei der Speicherung in Planes werden die Farbwerte separiert Ein Bildpunkt 7 erh lt seine Information aus dem iten Wert der jeweiligen Farb kanalfelder Diese Technik vereinfacht die Segmentierung da die Farbkan le getrennt vorliegen Nachteilig wirkt sich der Speicherzugriff auf die Lese und Schreiboptimierung des Prozessors aus Da in verschiedenen Bereichen gelesen und geschrieben wird sind l ngere Burstzugriffe nicht m glich Folgende Funktionalit t wird f r die Videoeingabe zu implementieren sein Bildformate e 720x576 und QSIF 360x288 bei 25 Bildern s e Deinterlacing der Videobilder e optional Cropping Bildausschnitt Farbformate e RGB24 andere Formate optional e Es muss eine Schnittstelle entwickelt werden die die Implemen tierung zus tzlicher Farbformate in den Treibern vereinfacht e optional Speicherung in Planes Performance e Der Prozesso
80. es Ger tes no IO Ope rationen k nnen durch weitere Applikationen durchgef hrt werden sofern die nderungen die Ein Ausgabe Operationen nicht tangieren F r das Vi deograbberger t bedeutet die Erweiterung dass w hrend des Einlesen von Bildern die Parameter wie Kontrast Helligkeit aber auch der Eingabekanal ge ndert werden k nnen Die Bildeigenschaften wie Gr sse und Farbformat k nnen nicht ge ndert werden solange Ein Ausgabe Operationen laufen Der Zugriff auf die Bilder erfolgt wie bei der Video4Linux API ber read mmap oder Overlay Eine Erweiterung erfuhr das mmap Verfahren Die Ap plikation beantragt weiterhin eine Anzahl von Bildpuffer die ber die Opera tion mmap in den Applikationsadressbereich eingeblendet werden Die Puffer werden zum F llen in eine Queue gestellt Gef llte Puffer enthalten dann zus tzliche Parameter wie Zeitstempel Bildz hler usw Die einstellbaren Eigenschaften der Hardware sind nicht mehr in einer fest definierten Struktur untergebracht Die Informationen ber die Eigenschaften m ssen erst aus dem Treiber ausgelesen werden Damit werden zus tzliche Einstellungen f r die verschiedenen Ger te erm glicht Weitere Neuerungen sind Informationsstrukturen f r angeschlossene Ge r te Kamera Zoom und Performanceinformationen Die Video4Linux2 API ist im Vergleich zur Video4Linux API wesentlich umfangreicher und aufwendiger zu implementieren Auch die Schnittstelle zu den Applikationen
81. fbtest und v4l2test die im Quellcode auf der beiliegenden CD enthalten sind Das Pro gramm fbtest berpr ft neben der korrekten Funktion der Schnittstellen gleichzeitig die Funktion der Hardware Bei allen korrekten Hardwareein stellungen wird eine Farbpr fung die Funktion des Consoletreibers und die Anordnung der Bildpunkte im Speicher getestet Aufgrund vielf ltigen Ein stellungsm glichkeiten der Video4Linux2 Schnittstelle beschr nkt sich das Programm v4l2test auf die Schnittstellenpr fung Die Testprotokolle sind in gek rzter Form in Anhang C zu finden Die Funktionstest des Video4Linux2 Treibers wurden in mehrere Programme ausgegliedert die gleichzeitig der Softwaredokumentation Sch02 als Beispielapplikationen dienen vtread liest ber die read Funktion der Video4Linux Schnittstelle Bilder ein und gibt sie auf dem Framebufferger t aus vtread basiert auf dem Pro gramm vtcat vtcat ist ein Testprogramm dass von der Video4Linux2 Homepage heruntergeladen werden kann Es ist explizit zum Testen der Video4Linux2 Schnittstelle gedacht vtmmap pr ft die Streamingfunktionen Wie vtread kopiert vtmmap das eingelesene Bild in den Framebuffer vtpreview nutzt die direkte bertragung des Bildes in den Framebuffer durch die Hardware vtctrl ebenfalls ein Testprogramm von der Video4Linux Homepage wurde um einige Funktionen erweitert Es ver ndert Eingabekanal Hardware einstellungen wie Helligkeit und die Bildaufl sung vetrl gr
82. ge ffnet hat Benutzt keine Applikation den Ger tetreiber kann der Decoderchip und die Funktionalit t im FPGA abge schalten werden 5 4 3 TC Treiber Die Kommunikation mit den Encoder und Decoderchips wird ber den I C Bus abgewickelt In Abschnitt 2 3 4 wurde das Protokoll vorgestellt Das Subsystem beschrieben in Abschnitt 3 6 teilt die Treiber in DC Busadapter und Chiptreiber Das Businterface des LartVIO wird den Algo Bit Treiber 78 nutzen Dieser Layer nutzt vier Einsprungsroutinen um die Bitzust nde der Clockleitung SCL und der Datenleitung SDA lesen und schreiben zu k nnen Jeder Chip besitzt eine Anzahl von Adressen ber die er auf dem PC Bus adressiert werden kann Wird der Chiptreiber geladen registriert er sich beim i2c_core Treiber Den registrierten Busadaptern wird der Chiptreiber der Reihe nach bergeben Auf dem entsprechenden Bus wird dann versucht den Chip anzusprechen Der Chiptreiber muss daher die f r den Chip rele vanten Adressen in einer Struktur an den Bustreiber bergeben Gleichzeitig m ssen die Chips zum Zeitpunkt der Registrierung auf DC Busanfragen rea gieren Der Busadapter sollte daher den FPGA initialisieren und die Chips einschalten Die Chiptreiber hingegen sollten so allgemein wie m glich ge halten werden Unter Linux ist es blich f r jeden Chip nur einen Treiber zu verwenden Der Chiptreiber kann so auch in anderen Architekturen ein gesetzt werden Beide Treiber sollten mit den in Eu
83. gehen w rden Es wird davon ausgegangen dass NPs G NPs G NPSIGa Es wird davon ausgegangen dass die Refreshlogik des StrongARM genutzt wird 69 sind Die Anzahl der in den Hautpspeicher zu schreibenden Elemente ist danach nps c zuz glich der Zeit die fiir das Schreiben ben tigt wird Iron NPOP NPSIG 5 1 2tpx tpop die Zeit f r das Leeren des FIFO ergibt sich aus der Summe den Zeiten von Busanforderung sowie den Zeiten fiir Zeilenzyklen und Spalten zyklen NPOP tpop tupreg 1 trep tre nPop pre NBCYC oder nach Einsetzen von npop tmBREQ 7222 1 trop tre npsictupec tpop SSC I 7 5 2 2tPpXNBCYC 2tpx Der zweite FIFO wird in der Zeit tpop noch entleert Somit ist tpor Iron NPOP psig px px und t t NPSIG POP POP _ TMBREQ 4 Es E 1 trop trp nps c Few nr Iron 1 I I 2tPXNBCYC 2tpx 5 3 Abbildung 5 6 zeigt Werte f r np ro und npsrc zwischen 0 und 512 mit trp tupc trop 2 18ns Die Anzahl der Spaltenzyklen in einem Burst tgcyc wurde auf 128 gesetzt tps entspricht dem 2 37ns Die FIFO Gr e nrrro von 512 Eintr gen bei einem Signal ngra zwischen 128 und 256 Eintr gen zeigt sich als guter Kompromiss zwischen maximalen Burstzeiten und den oben definierten Beschr nkungen 5 3 4 Videoeingabe Die Videoeingabe erh lt vom SAA7113 die Videodaten ber einen 8Bit Bus Diese m ssen ei
84. gen seit der Version 2 5 20 in der Schnittstellendoku mentation enthalten die bei der Implementierung ber cksichtigt wurden Die nderungen im Framebuffersubsystem entsprachen bis zur Version 2 5 30 den in der Dokumentation bereits angek ndigten nderungen Die Video4Linux2 API ist trotz mehrfacher Ank ndigung bis jetzt nicht in den Kernel auf genommen worden Es sind lediglich einige Vorbereitungen getroffen die auf eine baldige Aufnahme in den Kernel hindeuten Innoffizielle Patches sind auf Kno02 verf gbar die unter anderem nderungen in der Registrie rung der Hardwaretreiber enth lt Aufgrund fehlender Dokumentation zu den nderungen war eine Anpassung bisher nicht m glich Bis zur Version 2 5 30 konnte kein Kernel in einer f r das LART Board lauff higen Version kompiliert werden ber die Funktion der Treiber mit dem Entwicklerkernel kann keine Aussage getroffen werden 98 Kapitel 7 Zusammenfassung und Ausblick Die Ziele des BV Board waren hoch gesteckt Bildverarbeitung auf Embed ded Ger ten ist heute noch eine Herausforderung Um keine unrealistischen Anforderungen an das BV Board zu stellen wurde zun chst die Hardware des LART Board und des LartVIO untersucht Die Untersuchungen zeigten insbesondere Resourcenengp sse beim Speicherbus Der Hauptspeicherbus wurde deshalb genauer untersucht Die Treiberarchitektur sollte unter Ber cksichtigung aktueller Entwick lungen im Betriebssystemkernel entworfen werden Di
85. hardwareseitig Beim Start des Framebuffersubsystem werden die Consoletreiber automa tisch mit eingebunden Die Implementierung des Subsystems l sst eine Funk tion ohne Consoletreiber nicht zu Dieser Entwurf ist ungl cklich gew hlt da vor allem Embedded Devices keine Verwendung f r diese Consolen haben 48 Es werden lediglich Resourcen verbraucht Problematisch ist die notwendige Implementation von Funktionsaufrufen fiir die Consoletreiber in den Hard waretreibern des Framebuffersubsystems Die Funktionsaufrufe sind nicht op tional und in den ersten Versionen des Framebuffersubsystem gab es keine generischen Funktionen im Subsystem Als Folge verwenden alle Hardware treiber fast den gleichen Code fiir diese Funktionsaufrufe Eventuelle Fehler sind dadurch in vielen verschiedenen Treibern zu korrigieren wovon einige nicht im Standardkernel bernommen wurden Nachtr glich wurden einige generische Funktionen in der Datei fbcon c geschaffen die dieses Manko be heben soll Bisher verwendet kein Treiber des Kernelbaums diese Funktionen Die Consoletreiber verwenden eine eigene Struktur display f r die Hard wareparameter Applikationen bedienen sich der Strukturen fb_fix_screeninfo und fb_var_screeninfo f r das Lesen und Setzen der Parameter die alle Para meter der Struktur display enthalten Diese Redundanzen sind Fehlerquellen und haben keinen praktischen Nutzen Die Strukturen fb_fix_screeninfo enth lt durch den Nutzer nicht ver
86. hen Funktionen ber die Standardzugriffe auf Treiber also open read write und close realisiert Die meisten erweiterten Funktionen k nnen durch die Applikation ber ioctl Kommandos aufgerufen werden Insbeson dere die Video4Linux2 API ist sehr umfangreich Die applikationsseitige Nut zung der Treiber ist in Sch02 ausf hrlich beschrieben In diesem Abschnitt werden nur die einfachen Zugriffe auf ein Bild und die bergabe an die Vi deoausgabe beschrieben Die Strukturen f r den Framebuffertreiber sind in der Inlcudedatei fb h defniniert Applikationen m ssen daher include lt linux fb h gt einf gen Die Strukturen und Kommandos der Video4Linux2 API sind in der Datei videodev h definiert include lt linux videodev h gt F r den Zugriff auf die Treiber muss der Treiber ge ffnet werden Der Video4Linux2 Treiber ist ber dev video06erreichbar int fd fd open dev fb0 O_RDWR 94 Die Strukturen fb_var_screeninfo und fb_fix_screeninfo werden ber ioct Kommandos gelesen struct fb_fix_screeninfo finfo ioctl fd FBIOGET_FSCREENINFO amp finfo bzw struct fb_var_screeninfo vinfo ioctl fd FBIOGET_VSCREENINFO amp vinfo Die Struktur fb_var_screeninfo kann ber das ioctl Kommando FBIOPUT_VSCREENINFO mit ver nderten Bildparametern an den Framebuf fertreiber bergeben werden Der Grafikspeicher wird mit der Funktion mmap in den Applikationsspei cher eingeblendet Bei Verwendung der Methoden
87. hes ist dann nicht mehr gew hrleistet Zwei Funktionen sind f r Ver nderungen der Bildeigenschaften notwen dig In der Funktion int lartviofb_check_var struct fb_var_screeninfo var struct fb_info info werden die neuen Bildeigenschaften gepr ft Die Eigenschaften werden in der Struktur fb_var_screeninfo bergeben Die Struktur fb_info ist eine interne Struktur des Framebuffertreiber die zum Zeitpunkt der Registrierung an das Framebuffersubsystem bergeben wurde Unterst tzt die Hardware die ange forderten Figenschaften nicht wird der negative Fehlerwert EINVAL Invalid Value zur ckgegeben lartviofb_check var unterscheidet sich gegen ber der Funktion lartviofb_decode_var aus der aktuellen Kernelversion in der Funktionsweise lartviofb_check_var pr ft die Struktur fb_var_screeninfo und kann diese bei Bedarf ver ndern Applikationen k nnen sich nicht dar auf verlassen dass alle Eigenschaften bernommen wurden Die Funktion 13Byte 24Bit 8 89 lartviofb_decode_var darf fb_var_screeninfo nicht ver ndern Die Eigen schaften f r die Hardware werden ber die interne Struktur lartvio_par ber geben int lartviofb_decode_var const struct fb_var_screeninfo cvar void vpar struct fb_info_gen gen Gibt die jeweilige Funktion den Wert Null zur ck wird durch das Frame buffersubsystem die Funktion lartviofb_set_par aufgerufen Aufgabe der Funktion ist die Ver nderung der Hardwareeinstellungen In der Kernelver
88. hnittstellen der Subsysteme funk 79 tionieren Daher werden die Schnittstellen zum Subsystem zu priifen sein Ins besondere beim Framebuffersubsystem ist die Schnittstelle des Subsystems nicht vollst ndig spezifiziert Zoon berscheibt in Zoo01 einen Teil der Con sole und Framebufferschnittstellen Da die Console Treiber mit dem Frame buffersubsystem verbunden sind miissen auch einige Tests mit den Console Schnittstellen durchgefiihrt werden Die Video4Linux2 API ist in 3 5 2 spe zifiziert Neben eigenen Testprogrammen stehen vorhandene Anwendungen fiir die Videoeingabe und die Videoausgabe zur Verfiigung Im Bereich der grafischen Oberfl chen sind der X Server XFree86 und die QT Bibliothek von Trolltech zwei bekannte Vertreter die das Framebufferdevice nutzen Weiterhin sind verschiedene kleinere Anwendungen verf gbar die das Framebufferger t an sprechen So ist das Kommando fbset bereits auf in der Lart Distribution enthalten fbset ver ndert die Einstellungen des Framebufferger tes Anwendungen die den Video4Linux Treiber nutzen sind reichhaltig vor handen Viele Programme werden zur Zeit auf die neue Video4Linux2 API angepasst XawT v ist ein Programm das bereits die Video4Linux2 API nutzt Es setzt jedoch einen X Server voraus Mit einer Auswahl dieser Programme sollen die Funktionen und Schnittstellen der Treiber getestet werden 80 Kapitel 6 Implentierung Nachdem die Schwerpunkte der Entwicklung im letzten Kapi
89. ie Hardwaresteuerung und stellen sie ber eine definierte Schnittstelle der Applikationsschicht zur Verf gung Dabei verhindert der Treiber gleichzeitig unbefugten und missbr uchlichen Zugriff auf die Hardware Rubini und Corbert beschreiben Ger tetreiber in RCO1 An Introduction to Device Drivers Device drivers take on a special role in the Linux kernel They are distinct black boxes that make a particular piece of hardware respond to a well defined internal programming interface they hide completely the details of how the device works Der Linuxkernel erlaubt es Ger tetreiber zur Laufzeit als Modul zu laden oder den Ger tetreiber mit dem Kernel zu kompilieren und ins Kernelimage zu integrieren Bei letztgenannter Methode wird der Treiber w hrend des Bootvorganges initialisiert Auf Ger tetreiber wird in Unix Systemen ber das Dateisystem zuge griffen Dazu werden virtuelle Dateien im Verzeichnisbaum blicherweise im Verzeichnis dev angelegt Die Unterscheidung der Ger tetreiber er folgt ber sogenannte Major Nummern Ein Teil dieser Major Nummern sind fest bestimmten Ger tetypen zugeordnet T 02 devices txt Dem Framebuf fertreiber ist die Major Nummer 29 dem Video4Linux Treiber die Major Nummer 81 zugeordnet Die Minor Nummer hat f r die jeweiligen Ger tetreiber spezifische Be deutung W hrend bei Blockger ten wie Festplatten die einzelnen Partitio nen ber die Minor Nummer angesprochen werden erh
90. iefern einen YCbCr Datenstrom der im Prozessor in das entsprechende Farbformat gewandelt und im Hauptspeicher abgelegt wird Der Prozessor konvertiert den Videostrom in das Farbformat RGB24 Die Busbelastung liegt in dieser Konstellation bei 128 75 MByte s Ein Bild der Gr sse 720x576 Bildpunkten mit 16Bit Pixelbreite ben tigt 60 RGB24 ee 9 Speicher wn oO N 2 S a e oO Ee a YCbCr 51 5MByte s Videomodul Videomodul A YCbCr A YCbCr 25 775 MByte s 25 775 MByte s Abbildung 5 1 Datenfluss der abstrahierten Videomodule Der Prozessor ver arbeitet den Videostrom 810 KByte Bild 25 Bilder s die bei einer Bildwiederholrate von 25Hz ber tragen werden erzeugen einen durchschnittlichen Datenstrom von 19 8 MByte s Die Differenz zur in Abbildung 5 1 angegebenen Transferleistung ergibt sich durch die horizontalen und vertikalen Austastzeiten Horizontal werden in je der Bildzeile ca 52 us Bilddaten 704 wirklich aktive Bildpunkte bertragen Innerhalb der 12 ps horizontalen Austastzeit bestehend aus vorderer Schwarz schulter Zeilensynchronimpuls und hinterer Schwarzschulter werden keine Bildinhalte bertragen Der Encoder empf ngt in einer Zeile 720 Bildpunkte im Abstand von 74ns 720 x 2Byte 720 x 74 x 10 9s Der durch den Prozessor in das Farbformat RGB24 konvertierte Datenstrom ist 2 gr er als der YCbCr Datenstrom Der gesamte
91. iiglich der Refreshzeiten sind bei st ndiger Generierung von Burst Of 24 Eight Zyklen 1s 10x10 3s _ Byte _ iso E x 8Zugrif fex 4 294x10 7s Zugriff L 102 76M Byte s s m glich Da Burst Of Four Zyklen nur 30 Bits der Wellenform verwen den ist ein Zyklus 195ns lang Die Datentransferleistung liegt noch bei 77 5M Byte s Neben diesen theoretischen Uberlegungen wurden einige Tests durch gefiihrt die die Datentransferleistung unter realen Bedingungen wiederspie geln sollen Das komplexe Design des Prozessors und der Overhead des Be triebssystems m ssen bei der bertragungsleistung ber cksichtigt werden Dazu wurde zwei Datenbereiche angelegt die iiber die Cacheline eingelesen und geschrieben werden Die 8 KByte Datencache sollten keinen Einfluss auf die Transferleistung haben daher wurden 150 KByte 1 2 MByte grosse Datenpuffer verwendet Die Tests sind in Anhang A 1 dokumentiert Fiir die Ubertragung wurden die Standardkopiermethode memcpy und eine optimierte Assemblerroutine verwendet Bei der Optimierung wurde da von ausgegangen dass die Daten immer in 1 KByte Bl cken gelesen werden Die ARM4v Architektur stellt Multiple Load and Store Befehle f r das F llen und Speichern von Registern zur Verf gung Bei 8 verwendeten 32 Bit Registern k nnen mit einem Befehl 32 Byte gelesen bzw geschrieben werden memcpy nutzt diese M glichkeit bereits muss jedoch auch abweichen de Gr ssen nicht durch 8 teilbare ber cksich
92. im Anlegen berechnet und in den Pufferstrukturen abgespeichert Durch dieses Verfahren wird die Interruptroutine entlastet die sonst f r jedes Bild erneut die Hardwareeigenschaften berechnen m sste Die Puffer werden durch die Applikation in eine Warteschlange zum F llen gestellt int capture_queuebuffer struct capture_device dev struct v412_buffer vidbuf und durch die Interruptroutine nach der bertragung des Bildes in eine weitere Warteschlange eingereiht die die fertigen Bilder repr sentiert In der Interruptroutine wird die Struktur des Puffers mit einem Zeitstempel und eine laufenden Bildnummer versehen Sind keine weiteren Puffer vorhanden schaltet die Interruptroutine die bertragung ab Die Methode read soll die einfache Methode f r den Zugriff auf Bilder darstellen Sie nutzt die eben beschrieben Streamingalgorithmen f r den Bildzugriff Es werden beim ersten Zugriff zwei Puffer angelegt und in die Warteschlange zum F llen gestellt Dabei wird davon ausgegangen dass ei ne Applikation wahrscheinlich mehr als ein Bild abholen wird read pr ft daher im ersten Schritt ob bereits Bilder bereitliegen Die Warteschlange wird dabei entleert und nach einem Bild gesucht dass nicht lter als 20ms 91 Leerer Puffer Q Queue gef llter ueue enar ll von der Applikation Puffer Zu f llende gef llte Bildpuffer Bildpuffer Signal an die Applikation Interrupt n chstes Bild poll select Abbildung 6 4
93. inden 6 1 3 Austastrahmen f r die Videoausgabe Ein Bild nach CCIR601 enth lt 704 aktive Bildpunkte in der Horizontalen 720 Bildpunkte werden an den Encoderchip bertragen Eine erste Implemen tierung zeigte bei verschiedenen Handels blichen TV Ger ten einen wesent lich breiteren Rahmen als acht Bildpunkte 2 gt Der sichtbare Bereich lag horizontal bei ca 640 Bildpunkten 80 Bildpunkte einer Zeile wurden aus dem Hauptspeicher bertragen und ohne effektiven Nutzen an den En coder weitergeleitet Zwischen FIFO und Encoderbus wurde eine Randerzeu gung implementiert Die Randerzeugung entspricht einem Umschalter der in selbstdefinierten aktiven Bereichen die Daten vom FIFO an den Encoderbus bertr gt und in den inaktiven Bereichen schwarze YCbCr Werte erzeugt Als angenehmer Nebeneffekt kann die Gr e des Videobildes nun zwischen 140x80 Bildpunkten und 720x576 Bildpunkten ver ndert werden wobei die Anzahl der Bildpunkte ein Vielfaches von 4 sein muss Die Einschr nkung nur Vielfache von 4 zuzulassen ergibt sich aus der Datenwortgr e und der Umwandlung der Werte von RGB nach YCbCr 86 6 1 4 Compilerprobleme Im Laufe der Implementierung der FPGA Funktionen traten mit zunemeh mender Komplexit t der Sourcen immer h ufiger nicht erkl rbare Fehler auf Zun chst wurden diese Fehler f lschlicherweise auf Programmierfehler zur ckgef hrt Das Fehlermuster war schlie lich sehr unterschiedlich Ver schiedene Kompilierung
94. ineoffset dev gt clientfmt bytesperline dev gt clientfmt width dev gt clientfmt depth 8 60 else dev gt stream_buf i dadrse dev gt stream_buf i map_dma dev gt clientfmt bytesperline lineoffset 2 dev gt clientfmt bytesperline dev gt clientfmt width dev gt clientfmt depth 8 dev gt stream_buf i drento 70 linebytes 4 dev gt clientfmt width dev gt clientfmt depth gt gt 5 amp LARTVIO_DRCNTO_ROWCNT lineoffset 4 lineoffset 4 lt lt 16 amp LARTVIO_DRCNTO_ROWOFFSET for i req gt count i lt MAX_CAPTURE_BUFFERS i dev gt stream_buf i requested 0 dev gt stream_buffers_requested req gt count 80 return 1 12 B 3 2 Die Funktion capture_queuebuffer fit capture_queuebuffer Add a stream buffer to capture queue dev device structure vidbuf stream buffer x exe x Returns 1 success 0 failed 4 static int capture_queuebuffer struct capture_device dev struct v4l2_buffer vidbuf 10 int i vidbuf gt index struct stream_buffer buf NULL if vidbuf gt type V4L2_BUF_TYPE_CAPTURE printk KERN_INFO QBUF wrong type n return 0 if i lt 0 i gt MAX_CAPTURE_BUFFERS dev gt stream_buf i requested 20 printk KERN_INFO QBUF buffer index d is out of range n i return 0 buf amp dev gt stream_buf i if buf gt vidbuf fl
95. ist aufwendiger Offensichtliche Designschw chen traten bei der Evaluierung nicht hervor 3 6 Das DC Subsystem In Abschnitt 2 3 4 wurde das I C Protokoll er rtert DC ist ein Kommunika tionsprotoll das ber einen Zweidrahtbus bertragen wird Die Taktleitung 53 SCL sorgt f r die Synchronistation von Master und Slave Die Daten werden seriell ber die Datenleitung SDA bertragen Der Master kann eine Kommu nikation mit einem beliebigen Slave initiieren Angesprochen wird der Slave ber eine 7Bit I C Adresse Das DC Subsystems unterscheidet zwischen dem DC Businterface und dem Treiberinterface Das DC Businterface stellt den Zugriff auf den PC Bus zur Verf gung In Fall des LartVio erfolgt dieser Zugriff ber den FPGA Dabei wird zus tzlich zwischen verschiedenen Zugriffsalgorithmen unterschie den Zur Veranschaulichung soll der i2c algo bit Treiber dienen Dieser Trei ber stellt die Grundfunktionalit t f r Adaptertreiber bereit die die Takt und Datenleitung SCL und SDA als Bitzugriffe erm glichen Der Adapter treiber implementiert in vier Methoden die bitweisen Schreib und Lesezu griffe auf die Leitungen Der i2c core Treiber enth lt die Funktionalit t des DC Protokolls und stellt Methoden f r den Zugriff auf die Busadapter und Clienttreiber zur Verf gung i2c dev i2c proc Userinterface i2c core Kernelinterface algo pcf algo bit er Algorithmlayer i2c elv i2c pport Adapterdriver Im78 saa 111 Clientdriver Ab
96. it bertragung deals a de ee Be me 29 Funktion einer Lookup Table LUT 34 Merkmale der m glichen Best ckungsvarianten des ACEX 1K 36 Bildver ndernde Funktionalit t von Videoein und Videoaus ADE Ag tends ce de ee A os oe ee Br ne Eee AS 65 Zuordnung der Farbkan le RGB zu den eingelesenen 32Bit WETICE sees e ha aa dara Hak ae SRE ei 85 Datentransferraten mit memepy ooo 103 Datentransferraten mit asmepy ooo 104 Datentransferraten mit angepassten Startadressen beide Auf rufe mit allen e oes posh sre bue ta ee ee De as 104 Kapitel 1 Einleitung An der FH Brandenburg wird eine intelligente Roboterplattform f r sehende autonome Systeme entwickelt die sich im privaten Bereich als Forschungs und Ausbildungsplattform an Hochschulen oder auch als Basis f r industrielle Anwendungen eignet Das RCube Projekt verbindet eigenst ndige Module deren Kombination verschiedenste Anwendungsm glichkeiten er ffnen Zu diesen Modulen geh ren CPU Board Die zentrale Steuerungseinheit kommuniziert mit den anderen Boards ber eine CAN Bus Schnittstelle Aksen Board Das Aktoren und Sensorenboard besitzt verschiedene ana loge und digitale Ein und Ausg nge Integriert ist ein 8Bit Micropro zessor der die Steuerung der Ein und Ausg nge bernimmt BV Board Die Bildverarbeitungskarte soll Videostr me aufnehmen und ver arbeiten Zus tzlich wurde eine Videoausgabe integriert die die Ergeb nisse gr
97. it dem Bustakt heruntergez hlt Mit jedem vierten berlauf wird ein internes Refreshflag gesetzt das den Prozessor veranlasst nach Beendigung des aktuellen Buszugriffes einen Re freshzyklus auszuf hren Dazu werden alle nCAS Leitungen aktiviert Nach zwei weiteren Bustakten werden die nRAS Leitungen aller DRAM B nke f r TRASR 1 Bustakte aktiv Die nCAS Leitungen werden zwei weitere Tak te sp ter deaktiviert Der n chste Buszugriff erfolgt dann fr hestens TRP 1 Bustakte sp ter Die Zeit f r einen Refreshzyklus kann mit TRefresh 2 TRASR 1 2 TRP 1 berechnet werden Entsprechend der Konfiguration des LART Boards dauert ein Refreshzyklus 154 ns Alle 15 3 us wird ein Refreshzyklus generiert F r die Generierung Refreshzyklen belegt der StrongARM den Speicherbus 10ms pro Sekunde 8Die Dokumentation hierzu ist widerspr chlich Int99 10 2 1 DRAM Configuration Re gister MDCNFG spricht von TRASR 1 Int99 10 3 3 DRAM Refresh von TRASR 1 23 Die Register MDCASO MDCAS1 und MDCAS2 enthalten die nCAS Wellenform fiir einen Burst of Eight Speicherzugriff Einen CPU Takt nach dem Anlegen der Zeilenadresse wird nRAS aktiviert Gleichzeitig beginnt die nCAS Wellenform Uber ein Schieberegister werden die Inhalte der Bitstel len der Register MDCASO bis MDCAS3 an nCAS Steuerleitungen gelegt Bis zum Abschluss des Zugriffs wird das Schieberegister mit jeden Takt um eine Bitstelle verschoben Das Konfigurationsbit CDB2
98. itzt eigene Funktionen fiir die Einstellung der Bildgr sse und das Farbformat Diese sollten auch getrennt gespeichert werden um ein einfaches Umschalten zwischen read mmap und Pre view zu erm glichen Damit bietet sich dann eine schnelle Methode verschieden Grosse Bilder parallel zu bearbeiten 77 e Die Einstellungen der Bildeigenschaften wie Helligkeit Kontrast Satti gung und Farbton sind in der Video4Linux API als sogenannte Controls bzw Bedienelemente Diese Bedienelemente k nnen von unterschiedli chen Typen wie Integer Boolean Menu oder Button sein Der Wer tebereich und die Schrittweite der Bedienelemente kann ebenfalls den Hardwareanforderungen angepasst werden Das ioctl Kommando VIDIOC_QUERYCTRL gibt die verf gbaren Bedienelemente zur ck Es sind bereits eine Anzahl von Standardbedienelementen vordefiniert Bedienelemente k nnen aber auch spezielle Hardwareeigenschaften abgebilden Die ioctl Kommandos VIDIOC_G_CTRL und VIDIOC_S_CTRL erm glichen das Auslesen und Setzten der Hardwareeigenschaften e Die Videoeingabe kann zwischen vier Videoeing ngen w hlen Das ioctl Kommando VIDIOC_ENUMINPUT listet die Eing nge und deren Leistungsmerkmale auf VIDIOC_G INPUT und VIDIOC_S INPUT erlauben das Lesen und Setzen des aktuellen Eingangs Die Schnittstelle bietet keine Powermanagementfunktion Der Einlese prozess durch den FPGA muss jedoch nur erfolgen wenn mindesten eine Applikation den Ger tetreiber
99. ive Funktion 25 RTC clock Echtzeittakt 1Hz 26 RCLK_OUT Bustakt CPU Takt 2 27 32KHZ OUT 32 kHz Oszillator Takt Tabelle 2 2 Alternative Funktionen der GPIOs am High Speed Connector Der StrongARM implementiert die ARM V4 Architektur und dessen Be fehlssatz ARMO1 RISC Prozessor typisch ist die Load Store Architektur Er besitzt einen internen 32 Bit Adressbus und einen 32 Bit breiten Daten bus Der Prozessor besitzt 37 interne Register die in sich teilweise berlappenden B nken angeordnet sind Dazu geh ren e 30 allgemeine 32 Bit Register e ein Programmcounter e das aktuelle Statusregister e f nf Sicherungstatusregister Von den 30 allgemeinen Registern sind nur jeweils 15 als r0 r14 zu einem Zeitpunkt erreichbar r13 wird als Stackpointer genutzt Im User Mode wird r14 als link register lr zur Speicherung der R cksprungadresse in Unterrou tinen benutzt Auf den Programmcounter kann ber r15 oder pc zugegriffen werden nicht alle GPIO Pins besitzen alternative Funktionen 18 2 2 3 Speicher Neben dem Prozessor befinden sich auf dem Lart Board 32 MByte RAM Ver wendet wurden zwei EDO RAM Bausteine nPD426165 der Firma NEC auf der Oberseite des Lartbords und zwei EDO RAM Bausteine MT4LC4M16F5 der Firma Micron auf der Unterseite des Lart Boards In den elektrischen Kennwerten unterscheiden sich die Chips kaum Adressierung Der StrongARM Prozessor arbeitet mit einem internen 32
100. kann der DMA Controller nicht verwendet werden Die Intel Application Note Memory to Memory Transfer using the SA 1100 DMA Int00b beschreibt eine Methode unter Nutzung der IRDA Schnitt stelle Die maximale Transferrate liegt bedingt durch die serielle Schnittstelle bei 4 MBit s SA 1100 Interrupt Controller Power 1 Management System System Bus Control Peripheral Control Module PCM Peripheral Bus Serial Channel 4 CODEC ARM is a trademark and StrongARM is a registered trademark of ARM Limited Abbildung 2 3 StrongARM Blockschaltbild aus Int99 Functional Descrip tion Ein 16 KB Instruktions und ein 8 KB Datencache reduzieren die Zu griffe auf den Speicherbus Ein Readpuffer und ein Writepuffer unterst tzen Schreib und Lesezugriffe auf den Speicherbus Der SA 1100 besitzt 28 digita le Ein Ausgabeports GPIOs Jedes der 28 Bits ist einzeln programmierbar und kann folgende Funktionalit ten bereitstellen e digitaler Eingabepin e externe Interruptleitung e digitaler Ausgabepin 17 e alternative Funktion siehe Int99 11 5 Am High Speed Connector der Verbindung zur Videoerweiterung sind die GPIOs 21 27 verfiigbar Die alternativen Funktionen dieser GPIOs sind in Tabelle 2 2 aufgelistet GPIO Signalname Alternative Funktion 21 MBGNT Busanforderung Abschnitt 2 2 3 22 MBREQ Busgew hrung Abschnitt 2 2 3 23 TREQB Testcontroller Signal 24 keine alternat
101. konfiguriert siehe auch Int99 10 2 Memory Configu ration Register Eine individuelle Konfiguration der einzelnen Speicherb nke ist nicht m glich In den Betriebssystemsourcen ist die Konfiguration in der Datei arch arm mach sal100 cpu sal100 c zu finden Einige Parameter wurden zur Vereinfachung nicht ber cksichtigt Sie beeinflussen das Ergebnis nur geringf gig Refreshart des SA 1100 6Einschr nkungen des StrongARM wurden in dieser Berechnung nicht ber cksichtig Einstellbar zwischen 56 MHz und 280 Mhz F r die Berechnungen wird die Standar deinstellung von 221MHz herangezogen 22 Name Konfiguration Bedeutung DE 0x3 Bank 0 und 1 aktiv DRAC 0x2 11 Bit f r die Adresszeile siehe Abbildung 2 4 CDB2 0x0 CAS Wellenform wird jeden CPU Takt verschoben TRP 0x04 5 Bustakte zwischen zwei Zugrif fen TRASR 0x07 8 nRAS Bustakte f r Refresh TDL 0x3 3 CPU Takte nach Deaktivie rung von nCAS werden Daten bernommen DRI 0x1A7 423 x 4 x 9 05ns 15 us zwi schen zwei Refreshzyklen Tabelle 2 3 DRAM Konfigurationregister Int99 10 2 1 DRAM Configurati on Register MDCNFG Tabelle 2 3 zeigt die Konfiguration des StrongARM Register MDCNFG Zwischen zwei DRAM Zugriffen werden 5 Bustakte eingef gt trp 45 25ns 4 85 ns nach der steigenden Flanke von nCAS werden die Daten bei einem Lesezugriff in den Prozessor bernommen TDL Der Refreshcounter DRI wird synchron m
102. l 6 beschreibt die Implementierung der entworfenen Kompo nenten und deren Zusammenspiel Ein weiterer Teil geht auf die Tests ein und zeigt die Schritte zum Nachweis der Funktionalit t auf Die Ergebnisse der Arbeit werden schlie lich in Kapitel 7 zusammenge fasst und ein Ausblick auf m gliche Erweiterungen und weiterf hrende Ent wicklungen geboten 11 Kapitel 2 Hardware Die Videodigitalisierung und ausgabe LartVIO ist eine Erweiterungskarte fiir das LART Board Nach der Vorstellung des Gesamtmodules werden hier ausgew hlte Teile der Hardware vorgestellt Vom LART Board werden der Prozessor und der Speicher n her betrachtet Danach werden die Bauelemen te des LartVio vorgestellt da diese Bauelemente in das Betriebssystem einge bunden werden sollen Die Spannungsversorgung wird hier nicht betrachtet da sie f r die Treiberentwicklung nicht von Bedeutung ist Als Abschlu wird eine Referenzimplementation der Firma Intel vorge stellt Das SA1100 Multimedia Development Board zeigt die Implementa tion einer Videodigitalisierung und enth lt eine Beispielimplementierung f r eine Videoausgabe im NTSC Format 12 2 1 Das BV Board Die Bildverarbeitungskarte LartVio ist ber einen Erweiterungstecker den High Speed Connector mit dem LART Board verbunden Auf diesem Ste cker sind die f r den Buszugriff notwendigen Signalleitungen vorhanden Al le Leitungen des Steckers sind an den Videocontroller angeschlossen Hin t
103. l von Videoein und ausgabe Entsprechend der Aufgabenstellung muss das Betriebssystem in der ak tuellen Version betrachtet und die derzeit in Entwicklung befindlichen Ver nderungen und Entwicklungen ber cksichtigt werden Von Interesse sind neben dem Framebuffertreiber und dem Video4Linux Treiber auch allgemei ne nderungen an der Treiberarchitektur Als mobiles Ger t darf die Leistungsaufnahme der Hardware nicht un ber cksichtigt bleiben Dies gilt sowohl f r den Hardware als auch f r den Softwarebereich Abschlie ende Tests sollen die Funktionalit t der Software untermauern Dieses Verfahren ist neben der Verifikation der Entwicklung blich Welche Testverfahren verwandt werden wird in der Entwurfsphase zu pr fen sein 10 1 2 Aufbau der Arbeit Die Arbeit gliedert sich in f nf Hauptkapitel und soll den Entwicklungs prozess von der Bestandsaufnahme und den allgemeinen Betrachtungen ber den Entwurf und die Implementierung sowie der Testumgebung bis zu einem abschliessenden Kapitel auf k nftige Erweiterungsm glichkeiten und Anwen dungen darstellen Wie im letzten Abschnitt angesprochen stellt eine Bildverarbeitung hohe Anspr che an die vorhandene Hardware Eine Optimierung der Performance setzt Wissen ber die vorhanden und ben tigten Resourcen voraus Des weiteren werden umfangreiche Kenntnisse der Hardware insbesondere des Prozessors und dessen Datenbus notwendig sein Die Betriebsystemumge bung und deren P
104. matrix Abbildung 2 4 Zuordnung der CPU Adressbits zu Speichermatrix Die Adresse setzt sich somit aus den Adressleitungen nCASO nCAS3 ent spricht AO und Al A2 A22 und A24 sowie A27 nRASO und nRAS1 zu sammen Damit ergibt sich ein maximaler Adressbereich von 2 addressier baren Speicherzellen oder 32 MByte addressierbarer Speicher Abbildung 2 4 verdeutlicht die Zuordnung der Adressleitungen des Prozessors zu den Zeilen und Spaltenadressen des Speichers Die verwendeten EDO RAM Bausteine k nnen im Fast Page Mode be trieben werden Bei dieser Zugriffsart wird die Zeilenadresse nur einmal ange legt Danach k nnen wahlfrei Spaltenadressen angelegt werden ohne erneut die Zeilenadresse zu bermitteln Mit der fallenden Flanke von RAS bzw CAS wird die Adresse bernommen Der Extended Data Output EDO ver einfacht den Lesezugriff Mussten die Daten bei lteren DRAM Bausteinen in der aktiven Zeit von nCAS gelesen werden stehen die Daten bei einem Lesezugriff nach der Zeit fe As bis zur n chsten fallenden Flanke von CAS an Diese Zugriffsart wird in Int99 10 1 Overview of Operation als Burstmode bezeichnet 20 Kk U ocn tupc CAS BIE S BEE Adresse OS ma AE X co X Col x Col x Col X Col x Col GF RAS Daten OP RRS EE z A Data Data Data Data Data Data use Abbildung 2 5 Fast Page Mode nach Oet97 Speichertransferleistung von DRAM und Prozessor Der externe Speicherbus des SA
105. n ein 32Bit Format gewandelt werden Bevor die Videoda ten in den FIFO gelangen k nnen Sie beliebig verarbeitet werden Daf r wurde eine Schnittstelle entworfen die f r verschiedene Funktionen genutzt werden kann Um die unterschiedlichen Vorverarbeitungsmodule ansprechen 18ns Bustakt 2 70 Abbildung 5 6 Abh ngigkeit der F llzeit von FIFO Gr e und F llsignal zu k nnen wird ein Multiplexer in die Videoeingabe integriert der ber die Softwaretreiber gesteuert werden kann Abbildung 5 7 zeigt den Datenfluss der Videoeingabe Die Schnittstelle der Videoeingabe wurde zusammen mit der Videoausga beschnittstelle so abstrahiert dass f r das DMA Modul die Anbindung beider Module einfach zu realisieren ist Die Schnittstellen unterscheiden sich nur in der Datenrichtung Videodecoderbus Der Videodecoder bergibt jeweils 8 Bit Werte Diese m ssen zu jeweils ei nem 32Bit Doppelpixel zusammengefasst und an die nachfolgenden Modu le weitergeleitet werden Neben dem Datenbus kommen vom Videodecoder noch einige Steuerleitungen Die Signale der Steuerleitungen sind intern zu synchronisiern und gegebenenfalls f r eine einheitliche interne Steuerung zu bearbeiten Zus tzlich kann ber den FPGA die Resetleitung des SAA7113 gesteu ert werden und der Taktgenerator des Videodecoder ein und ausgeschalten werden Der SAA7113 bietet keine Stromsparfunktion Diese wird durch die Abschaltung des Taktes und der Aktivierung des Rese
106. nder bare Eigenschaften wie die Framebufferadresse und Zeilenl nge Die Struk tur fb_var_screeninfo enth lt ver nderbare Eigenschaften des Framebuffer treiber Der Treiber unterscheidet zwischen sichtbaren Bildbereich und vir tuellen Bildbereich Der Grafikspeicher wird nach dem virtuellen Bildbereich aufgeteilt Die in fb_fix_screeninfo angegebene Zeilenl nge bezieht sich daher auf den virtuelle Bildbereich 3 4 2 Das Framebuffer Subsystem im Kernel 2 5 Die im letzten Abschnitt angesprochenen M ngel veranlassten James Sim mons eine bessere Trennung der einzelnen Subsysteme zu entwerfen In einer E Mail vom 23 11 2001 schreibt er auf der Framebuffer Mailingliste Sim02a Well it ended up as a total rewrite of the tty console layer In the new design the the tty console layer is composed of seperate subsystems which can exist independently outside of the tty layer Thus the tty layer is constructed from these subsystems This makes for a cleaner mor emodular design Some of things done are 1 New framebuffer api This new api allows the fbramebuffer layer to exist without a framebuffer console This makes for a 49 much simpler api and much smaller code Plus on embedded de vices like a iPAQ have a VT console doesn t make sense Seit der Version 2 5 2 befindet sich das neue Subsystem im Kernel Neben berarbeiteten generischen Funktionen wurde die Schnittstelle um Operati on fiir die Nutzung von hardwarebeschleunig
107. ne SA1101 Development Board Auf der Hauptplatine sind neben dem Prozessor unter anderem zwei Videoeing nge eine Videoausgabe und der Hauptspeicher untergebracht Auf der Erweite rungsplatine ist die zweite Videoausgabe von Interesse 38 Als Hauptspeicher verwendet Intel EDO RAMs die iiber einen SODIMM Sockel gesteckt werden Der Prozessor wird mit 220MHz getaktet Der Bus takt ist mit dem Bustakt des LART Boards vergleichbar Intel gibt die Band breite des Busses mit 120 MByte s an Im Verhaltnis zu den berechneten Ubertragsraten des LART Board miisste die Bandbreite bei ca 102 MByte s liegen Intel hat hier m glicherweise eine bessere Anbindung des Speichers erreicht TV VIDEO comp Ix Izi SvhsY A Bt829 L INPUT Svhsc Hf video Pal IS decoder IS ac k Choa cll i Hi Lo gt Abbildung 2 14 Blockschaltbild der Videodigitalisierung des SA 1100 Multi media Development Board Ausschnitt aus Int98 Figure 4 2 Die Videodecodierung bernehmen zwei Bt829 Diese Videodecoder wan deln das analoge Videosignal in YCbCr 4 2 2 Daten die ber einen 16 Bit breiten optional auch 8 Bit breiten Bus bertragen werden Die Bt829 k nnen das Videobild skalieren und beschneiden interessant f r ROI in der Bildverarbeitung Die mittlere Leistungsaufnahme ist angegeben mit 170mA bei 5 0V ca 850mW Uber einen CPLD ein programmierbarer Logikbaustein werden die Da ten in zwei 512x1
108. nehmen Da die Halbbilder einzeln 66 FPGA Rander erzeugung Skalierung N ER attente sng NYO es Jojpndosp A Skalierung optional weitere Een RGB gt YCbCr l I JJndo pPI A Videoausgabe Adressgenerator Skalierung Bild 2 Modulw hler Videoeingabe L Adressgenerator DMA SOU pun uayeyosuesiq IJU WAVZUONS Lart Bus Abbildung 5 4 Entwurf des FGPA 67 Grafikspeicher el T EVEN Halbbild e4 Ra NR e5 e6 ODD Halbbild DERB DR Abbildung 5 5 Interlacing und Deinterlacing bertragen werden ist es sinnvoll die Startadresse f r das Halbbild mit ge raden Zeilennummern und f r das Halbbild mit ungeraden Zeilennummern vorzugeben Dies erm glicht die Speicherung der Halbbildern in verschiede nen Grafikspeichern Der Linux Frambuffertreiber unterscheidet zwischen sichtbaren und vir tuellen Aufl sungen Die virtuelle Aufl sung ist mindestens so gross wie die sichtbare Aufl sung sein Die sichtbare Aufl sung kann daher einen Zeilenoff set zur n chsten Zeile haben Der Offset f r das Interlacing und Dei
109. nis sollte eine performante L sung der Bildaufnahme und wiedergabe ent stehen die k nftigen Nutzern des BV Boards Raum f r die Implementation verschiedenster Anwendungen insbesondere im Gebiet der Bildverarbeitung bietet Die Schnittstellen zur Hardware sollten sich an im Betriebssystem vor handene Schnittstellen anlehnen um Portierung vorhandener Anwendungen auf das BV Board zu erleichtern In der Aufgabestellung wird besonderer Wert auf die Nutzung in kommenden Linuxversionen gelegt Eine Betrach tung aktueller Entwicklungen f r das Betriebssystem ist daher unerl lich 1 1 Aufgaben des BV Boards F r die Entwicklung eines Produktes ist es notwendig herauszufinden was entwickelt werden soll Neben der reinen Funktionalit t muss das Produkt auf die Nutzergruppe und deren Anforderungen zugeschnitten sein Im letzten Abschnitt wurden bereits die anvisierten Nutzergruppen benannt e private Anwender e Forschungs und Ausbildungsplattform an Hochschulen e Basis f r industrielle Anwendungen Private Anwender und die Ausbildung an Hochschulen ben tigen eine leichte Bedienbarkeit des Produktes Die Einarbeitungszeit in die Bedienung des Produktes muss bei privaten Anwendern und Ausbildungsplattformen an Hochschulen kurz sein sonst wird das Produkt nicht angenommen Die Ausbildung deren Hauptaugenmerk die Wissensvermittlung ist wird das Produkt als Hilfsmittel nutzen Die Bedienung und in diesem speziellen Fall die Ansteuerung d
110. nterlacing muss durch die Softwaretreiber berechnet werden Das Ende des Grafikspei chers muss ebenfalls ber cksichtigt werden um ein berschreiben fremder Bereiche zu verhindern F r jedes Videomodul wird eine Adresssteuerung ben tigt 5 3 3 Datenpuffer Da die Speicheransteuerung durch das Busmastermodul vorgenommen wird k nnen l ngere Burstzyklen als die Burst Of Eight Zyklen des Prozessor ge neriert werden Die Datenpuffer m ssen neben der notwendige Gr sse f r die Pufferung der horizontalen Austastzeit auch die Zeit f r den Datentransfer zum Speicher ber cksichtigen Das gilt sowohl f r das eigene Videomodul als auch f r das beim Zugriff auf den Speicher konkurierende Videomodul Als Datenpuffer wurden nach dem FIFO Prinzip Puffer vorgesehen Die Daten die auf der einen Seite des Datenpuffer hineinfliessen kommen in der gleichen Reihenfolge aus dem Datenpuffer wieder heraus Im weiteren werden die Datenpuffer kurz FIFOs genannt In diesem Abschnitt wird die notwen dige Gr sse der FIFOs betrachtet F r die Betrachtung ist die Datenrichtung wieder unerheblich Es wird davon ausgegangen das die FIFOs die gleiche 68 Datenbusbreite wie der Speicherbus haben F r die weiteren Berechnungen m ssen einige Variablen definiert werden NFIFO Anzahl der Elemente im FIFO NPOP Anzahl der Elemente die bis zum Zeitpunkt nsra entfernt werden m ssen NSIG Anzahl der Elemente bei dem das Signal zum Lee ren des FIFOs gegeben wi
111. ptional eine automatische Abschaltung nach einer definierten Zeitspanne 59 Kapitel 5 Entwurf Nachdem die Entwicklungsumgebung in den letzten beiden Kapitel beleuch tet wurde wird in diesem Kapitel der Entwurf von Soft und Hardware be schrieben In den ersten Abschnitten werden einige Grund berlegungen zu den Grenzen der Hardware und das Anwendungsgebiet angestellt bevor der eigentliche Entwurf dargelegt wird Die Soft und Hardware wird in einzelne Module geteilt und deren Aufgaben definiert Im letzten Abschnitt werden notwendige Testumgebungen f r Soft und Hardware vorgestellt 5 1 Grundentwurf F r die Betrachtung wurde der Videocontroller des LartVio in zwei un abh ngige Funktionsgruppen geteilt der Videoeingabe und Videoausgabe Beide Module verbinden die jeweiligen Chips mit dem Speicherbus des Lart Board Die im Hauptspeicher des Lart Board befindlichen Grafikdaten m ssen von bzw zum Modul des Videocontrollers bertragen werden Der Videode coder liefert im aktiven Bildbereich alle 37ns ein Byte Nach 148ns steht jeweils einen Doppelpixel im YCbCr Format 32 Bit zur Verf gung Der Videoencoder erwartet im gleichen Abstand jeweils ein Doppelpixel F r die folgenden Betrachtungen ist die Datenrichtung in vielen F llen unerheblich Die Videoeingabe und die Videoausgabe werden im folgenden als zwei Vi deomodule behandelt die Daten einlesen Abbildung 5 1 zeigt den Datenfluss auf dem Speicherbus Die Videomodule l
112. r geringen Anzahl an Leitungen Die Geschwindigkeit liegt je nach Implementation zwischen 0 100 kbit s im Standard Mode 0 400 kbit s im Fast Mode und 0 3 4 Mbit s High Speed Mode ab Version 2 0 31 Fiir die Ansteuerung des Encoder und Decoderchips ist die Ubertragungs geschwindigkeit nicht relevant da keine zeitkritische Steuerung ber den DC Bus erfolgt Es wird daher nicht n her auf die Unterschiede zwischen den ver schiedenen Modi eingegangen Durch eine separate Taktleitung SCL ist die Datentransferrate dynamisch kann also zwischen 0 und Maximalgeschwin digkeit variieren Ger te mit verschiedenen Geschwindigkeiten k nnen dabei an einem Bus betrieben werden Die Spezifikation teilt die Ger te in zwei Klassen nach dem Master Slave Prinzip Master Der Master initiiert und beended den Transfer Er erzeugt die Signale der Taktleitung Slave Jedes Slave Ger t erh lt eine eindeutige Adresse Es reagiert auf die Anforderungen des Master SDA SCL l l Daten g ltig Daten nicht g ltig Abbildung 2 8 DC Bus Bit Transfer nach Phi01 Fig 4 Die Spezifikation beschreibt ebenfalls den Betrieb mit mehreren Master Ger ten Da die oben beschriebene Hardware nur einen Master das Lart Board besitzt wird auf den Betrieb mit mehreren Mastern nicht n her ein gegangen Takt und Datenleitung sind bidirektionale Open Drain Leitungen Im High Zustand der Taktleitung SCL wird der Zustand der Datenleitung SD
113. r gt xres available border half for a border top and same buttom second half comes from technical manual LartVIO yborder 2 yvideolen 1 var gt yres 2 2 par gt encaddr LARTVIO_ENCC ENCC_FULLSIZE else par gt encaddr LARTVIO_EADRSE par gt encaddr LARTVIO_EADRSO 114 20 30 40 50 60 par gt encaddr LARTVIO_ENCC amp ENCC_FULLSIZE rowoflset var gt xres_virtual var gt xres var gt bits_per_pixel 8 zvideolen var gt xres available border half for a border left and same rigth second half comes from technical manual LartVIO xborder xvideolen 1 var gt xres 2 70 xvuideolen var gt xres available border half for a border top and same buttom second half comes from technical manual LartVIO yborder yvideolen 1 var gt yres 2 J ressize var gt xres var gt yres var gt bits_per_pixel 8 if ressize gt par gt map size printk KERN_ERR lartviofb Size for framebuffer too small n 80 if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 return EINVAL else return endif rowcount var gt xres var gt bits_per_pixel 8 par gt encaddr LARTVIO_EBORDER 90 yvideolen lt lt 23 amp LARTVIO_EBORDER_ENCYL yborder lt lt 16 amp LARTVIO_EBORDER_ENCYB xvideolen lt lt 7 amp LARTVIO_EBORDER_ENCXL xborder amp LARTV
114. r muss gen gend Leistungsreserven f r die Verarbei tung der Bilder haben Bildeigenschaften 57 e Helligkeit Kontrast S ttigung sollten ber den Treiber einstellbar sein Zugriff auf Bilder e Eine einfache Methode Bilder einzulesen Sie soll den Einstieg mit wenigen Codezeilen Erfolge erm glichen e F r performanceintensive Programme werden schnelle Methoden f r den Bildzugriff ben tigt Sofern die einfache Methode dies nicht gew hrleistet sind entsprechende Algorithmen zu entwicklen e optional das direkte Einblenden des Videostroms in den Frame buffer e die Hardware muss ausserhalb des Betriebes in einen Schlafmodus geschaltet werden 4 2 Videoausgabe Die Videoausgabe soll Bild und Grafikdaten auf den Bildschirm bringen Der Framebuffertreiber stellt unter Linux eine Schnittstelle f r Standardsoftwa re zur Verf gung Zu dieser Kategorie z hlen unter anderem XFree86 und QT Embedded Der Framebuffertreiber stellt jedoch lediglich Informatio nen ber den Aufbau des Grafikspeichers zur Verf gung Die Software muss mit den vorgefundenen Einstellungen den Grafikspeicher schreiben k nnen F r das jeweilige Farbformat m ssen entsprechende Algorithmen vorhanden sein QT Embedded als Beispiel kann mit den Farbformaten RGB8 RGB16 RGB24 und RGB32 umgehen Die Speicherung in Planes beherscht QT Embedded nicht Die Information wird von QT Embedded ignoriert und das Bild weiterhin in fortlaufenden RGB Werten gespei
115. r rk Der Decoder f llt das Schieberegister in 4 Takten in dieser Zeit m ssen beide Y und Cb Cr in der Verarbeitungs pipeline sein Die Werte werden ohne Verz gerung berechnet Bei der Halbierung der Daten wird jedes 2 Doppelpixel verworfen Die Reduzierung der Daten ist verbesserungsw rdig 40 Ch data 7 ot Y1 data L5 8 Cr data 23 16 Y2 data 31 24 al7 0 Chl q 15 8 Y1 q 23 16 Cr q 31 24 Y2 50 TOGGLE_SM clk Clock CASE TOGGLE_SM IS WHEN SECOND gt q rd data_en AND enable AND FULLSIZE IF data_en OR reset THEN TOGGLE_SM FIRST END IF WHEN OTHERS FIRST gt q rd data_en AND enable 60 IF data_en AND reset THEN TOGGLE_SM SECOND END IF END CASE TOGGLE State Machine END 110 B 2 Ausz ge aus lartviofb c Framebuffertrei ber B 2 1 Die Funktion lartviofb_check_var bzw lartviofb_decode var je lartviofb_check_var Validates a var passed in var frame buffer variable screen structure info frame buffer structure that represents a single frame buffer Checks to see if the hardware supports the state requested by var passed in This function does not alter the hardware state This means the data stored in struct fb_info and struct lartvio_par do not change This includes the var inside of struct fb_info Do NOT change these This function can be called on its own if
116. ration des Videodecoders erfolgt ber einen DC Bus ber den der Registersatz des SAA7113 geschrieben und gelesen werden kann Philips gibt als Slaveadresse zwei 8 Bit Adressen 0x48 und 0x49 an Das ent spricht gem DC Spezifikation der 7 Bit Adresse 0x24 Die kleinste Bitstelle gibt die Schreib Leserichtung an Der I C Bus wird in Abschnitt 2 3 4 besprochen 2 3 3 Der Videoencoder ADV7171 Die Generierung der Videosignale fiir die Bild und Grafikausgabe tibernimmt der ADV7171 Ana01 von Analog Devices Als Videosignale k nnen FBAS CVBS S Video Y C YUV RGB ausgegeben werden Auf dem Lart VIO stehen von den vier DACs Digital to Analog Converter des ADV7171 nur DAC A als Ausgang zur Verf gung Diese Hardwarebeschr nkung be steht aufgrund der hohen Leistungsaufnahme der DACs H Somit steht als Ausgabeformat nur FBAS Farbbild Austast Signal zur Verf gung da alle anderen Formate mehr als eine bertragungsleitung ben tigen Ica 37mA pro DAC 30 Die Grafikdaten bernimmt der ADV7171 im YCbCr 4 2 2 Format ber einen 16 Bit Datenbus Im 8 Bit Modus werden nur die Datenleitungen P 7 0 fiir die Ubertragung der Bilddaten genutzt Auf dem LartVIO sind nur die Datenleitungen P 7 0 mit dem FPGA verbunden Die Videosynchronsignale k nnen extern in den ADV7171 eingespeist oder vom ADV7171 selbst erzeugt werden Liegen Videosignale als Daten strom vor wird die erste Methode ben tigt Eine direkte Anzeige der Vide o
117. rd NPSIG Anzahl der zu lesenden Elemente bei Signal nig trop Zeit f r das F llen von pur Elementen tpx Zeit fiir das Auslesen eines Pixels word NBCYC max Anzahl der Col Zylken in einem Burst tupc Zeit f r einen Spaltenzyklus siehe auch Abschnitt 2 2 3 trop Zeit fiir die Ubergabe der Zeilenadresse siehe auch Abschnitt 2 2 3 trp Zeit zwischen zwei Zeilenzyklen siehe auch Ab schnitt 2 2 3 tMBREQ Zeit zwischen Anforderung des Busses MBREQ bis zur Freigabe MGBGNT siehe Abschnitt 2 2 3 FIFO Variablen erhalten zur Unterscheidung der beiden FIFOs eine Num merierung 1 und 2 Wird der FIFO gef llt muss ab einer bestimmten Marke Nsig das Busmastermodul den Datentransfer zum Hauptspeicher beginnen um die aufgelaufenen Daten aus dem FIFO zu entfernen Da zwei FIFOs parallel arbeiten kann im ung nstigsten Fall naire und ns c gleichzeitig eintreten Der Busmaster muss diese Situation regeln und einen der beiden FIFOs bevorzugen In der Zeit des Datentransfer werden weiterhin Daten in die FIFOs geschrieben tpop ist die Zeit f r das Leeren des ersten FIFOs und tpop die Zeit f r das Leeren des zweiten FIFOs Folgende Bedingungen m ssen beim Betrieb des FIFO jederzeit erf llt sein e Es darf nicht zu einem Unter oder berlauf des FIFO kommen die Folge w re Datenverlust e Bedingt durch den zweiten FIFO muss tpop kleiner als der Abstand zwischen zwei Refresh Zyklen des DRAM sein da sonst Refresh Zyklen verloren
118. rdsoftware notwendig 4 1 Videoeingabe Bereits in der Aufgabenstellung enthalten ist das Haupteinsatzgebiet Bild verarbeitung Im Unterschied zu einfachen Multimediaanwendungen wird das 59 Bild in mehreren Stufen verarbeitet In Bildvorverarbeitung Segmentierung und Merkmalsextraktion werden die Bilder bearbeitet Der Datenstrom ent spicht einem Vielfachen der Bildgr sse zumal bei jeder Verarbeitung das Bild eingelesen wird und die Ergebnisse geschrieben werden Die Verarbei tung PAL Bild mit der Aufl sung 720x576 Bildpunkten und einer Farbtiefe von 24 Bit soll diese Zusammenh nge verdeutlichen Dieses Bild ist ca 1 3 MByte gross Wird f r die Bildvorverarbeitung und Segmentierung nur ein Filter die blicherweise mit 3x3 Matrizen arbeiten benutzt sind je Filter 3 3 x 720 576 3 732 480 Pixel einzulesen Bei einer Farbtiefe von 24 Bit ist ein Pixel 3Byte gro Es werden also mindestens 3 Byte x 3 732 480 11 197 440 Byte 10 68M Byte an Daten f r einen Filterprozess eingelesen Ausgegeben werden 768 x 576 1 3M Byte F r einen Filterprozess m ssen ca 12MByte an Daten bertragen werden Diese Berechnung ist stark vereinfacht und gilt nicht f r jeden Verarbei tungsprozess zeigt aber das hohe Datenvolumen das eine Bildverarbeitung zu bew ltigen hat Aus dieser Berechnung wird auch klar welchen Einfluss die Bildgr e auf die Berechnung hat Bei einem Bild mit der Ausl sung 360 288 veringert sich das Dat
119. read und write werden die Grafikdaten immer in den Grafikspeicher kopiert Beim Zugriff auf den eingeblendeten Grafikspeicher entf llt der zus tzliche Kopiervorgang char data data char zl mmap 0 finfo smem_len PROT_READ PROT_WRITE MAP_SHARED fd 0 Der folgende read Befehl schreibt ein Bild vom Video4Linux2 Treiber in den Grafikspeicher des Framebuffertreibers Das Bild wird dann auf der Gra fikausgabe ausgegeben read vid data vinfo yres vinfo xres vinfo bits_per_pixel 8 Wie bereits zu Beginn dieses Abschnitts erw hnt ist die Schnittstelle zu den Treibern weit umfangreicher Eine vollst ndige Auflistung aller Funk tionen w rde den Rahmen dieser Arbeit sprengen Die Schnittstellen beider Treiber werden mit direktem Bezug auf das LartVIO in Sch02 erl utert Die Vollst ndige Video4Linux2 API wird in Dir02 beschrieben Da das Fra mebufferger t direkt mit den Consoletreibern interagiert kann auch ber die Consoletreiber auf das Framebufferger t zugegriffen werden 6 4 Nachweis der Funktionalit t Entsprechend den Testanforderungen wurden die verschiedene Bereiche von Soft und Hardware mit unterschiedlichen Mitteln getestet Zu Testen waren e die Schnittstellen der Subsysteme 95 e die Module des FGPA e sowie das funktionale Zusammenspiel von Hard und Software Die Schnittstellen der Subsysteme wurden mit funktionalen Aquivalenz klassentests gepr ft Es entstanden dabei zwei Testprogramme
120. rhandener Treiber nicht zu umfangreich sind Insbesondere Ger tetreiber die neuere Hardware unterst tzen werden auf ltere Versionen portiert Bisher wurden die jeweils letzen beiden stabilen Kernel weiter gepflegt Linux beruht auf einer monolithischen Architektur Im Gegensatz zur Mi krokernelarchitektur in der die Ger tetreiber in einem gesch tzten Benut zerbereich residieren und mit einem minimalen Kern kommunizieren sind in einer monolithischen Architektur auch die Ger tetreiber in den Kern inte griert Sie arbeiten im priviligierten Modus der CPU und im Kerneladress raum Der Vorteil gegen ber einem Microkernel ist der minimierte Kommu nikationsaufwand und erweiterten M glichkeiten der Optimierung Nachteil ist die geringere Resistenz gegen ber fehlerhaften Ger tetreibern Applikationen kommunizieren mit dem Kernel ber Systemaufrufe sys tem calls Ein Systemaufruf ist der bergang eines Prozesses vom Nutzer 44 Applikation Ce Applikation User Mode User Mode KerelMode AN Kernel Mode Kernel Se Kernel Abbildung 3 1 Monolithische Ar Abbildung 3 2 Mikrokern Archi chitektur tektur zum Systemmodus Unter Linux ist es blich bekannte Systemaufrufe als Bibliotheksfunktionen zur Verf gung zu stellen 3 3 Geer tetreiber und Ger teklassen Ger tetreiber stellen eine Softwareschicht zwischen der Hardware und der Applikationsschicht dar Sie abstrahieren d
121. rogrammierung spielt f r die Optimierung ebenfalls eine gewichtige Rolle In Kapitel 2 wird des LART Board sowie die geplante Vi deoerweiterungskarte LartVIO untersucht Nach einer kurzen Vorstellung der beiden Platinen wird auf einzelne f r die Entwicklung wichtige Baugruppen eingegangen Am Ende des Kapitels wird eine Referenzimplementation einer StrongARM basierten Multimediakarte der Firma Intel vorgestellt Kapitel 3 stellt das Betriebssystem des LART Board vor und untersucht die f r den Entwurf notwendigen Subsysteme des Kernels Dabei wird die aktuelle Version des Betriebssystems mit den Entwicklungen f r sp tere Ver sionen verglichen Als Ergebnis dieses Kapitels soll eine Entscheidung m glich sein welche Subsysteme f r das Treiberdesign verwendet werden Die Sub systeme sollen mit der aktuellen Version des Betriebssystems funktionieren aber auch mit der n chsten stabilen Version des Kernel verwendbar sein Die Anforderungen an die Bildverarbeitungskarte werden in Kapitel 4 spezifiziert Das Kapitel ber cksichtigt die aus der Analyse der Hardware und des Betriebssystems gewonnen Erkentnisse Auf der Grundlage des An forderungskataloges wird in Kapitel 5 eine geeignete Architektur der Treiber f r das BV Board entworfen Es werden die Aufgaben der Hard und Soft ware spezifiziert und berlegungen ber notwendige Tests vorgenommen Ein abschliessender Abschnitt wird den Entwurf mit der Aufgabenstellung verifizieren Das Kapite
122. ropa blichen Videostandards CCIR und PAL initialisiert werden Der Chiptreiber wird ADV7170 benannt Der auf dem LartVIO verwendete ADV7171 ist eine abgespeckte Variante des ADV7170 und bis auf einige nicht vorhandene Funktionen vollst ndig kom patibel zu diesem Da der Framebuffertreiber keine Unterst tzung f r die Einstellung der Bildeigenschaften Helligkeit Kontrast usw bietet ist die Implementierung dieser Funktionen nicht notwendig Im Kernelbaum existiert bereits ein Treiber f r den SAA7111 der eine hnliche Funktionalit t bietet wie der SAA7113 Der Treiber wurde jedoch f r eine ltere Version des DC Bustreiber geschrieben bevor das DC Subsys tem in den Kernel implementiert wurde Der Aufwand f r die Anpassungen des Treiber auf das neue Subsystem schienen gegen ber einer Neuimplemen tierung ungleich gr sser Die Test f r den angepassten Treiber h tten auf die bereits vorhandenen Treiber ausgedehnt werden m ssen die diesen Treiber nutzen Es wurde daher ein neuer Treiber entwickelt der neben der Initialisierung des SAA7113 Eintstellungen f r Helligkeit Kontrast S ttigung und Farbton zul sst Der Videoeingang wird ebenfalls ber den DC Bus ausgew hlt und muss im Treiber ber cksichtigt werden 5 5 Testverfahren Ein grosser Teil der Funktionalit t wurde in den FPGA verschoben Als Test verfahren sind f r die Module berpr fungen mit Wellenform Simulationen vorgesehen Die Treiber m ssen ensprechend den Sc
123. rruptsi gnale f r die Behandlung von Ereignissen Diese werden ebenfalls durch das StrongARM Interface bereitgestellt Dazu z hlen die Videoeingabeinterrupts PIC_START und PIC_STOP die den Beginn und das Ende eines eingelesenen Bildes signalisieren Der Interrupt des CAN Controllers muss an den Pro zessor weitergereicht werden F r den Interruptbetrieb stehen die GPIOs LART_FORCE LART_SPARE und LART_1HZ zur Verf gung 5 4 Ger tetreiber Entsprechend der Aufgabenstellung wurde bei der Auswahl der Schnittstel len besonderer Wert auf die Funktion in zuk nftigen Kernelversionen gelegt Zum Entwurfszeitpunkt war die aktuelle Version des stabilen Kernels 2 4 18 Der Entwickerkernel war bei Version 2 5 20 angelangt wobei dieser auf dem Lart Board nicht funktionsf hig war Meldungen von Nachrichtenagenturen zuvolge sollen ab Oktober 2002 in den Entwicklerkernel 2 5 x keine neuen Funktionen mehr aufgenommen werden Die Schnittstellen der Subdesigns werden ab diesem Zeitpunkt nach M glichkeit nicht mehr ge ndert Bis zu einer stabilen Version des Kernel vergingen bei den Versionen 2 1 x und 2 3 x etwa ein Jahr Mit einer funktionsf higen Version des Kernels kann ab etwa Januar 2003 gerechnet werden Um den Anforderungen einer leichten Portierbarkeit auf zuk nftige Ker nelversionen gerecht zu werden wurden einige Grunds tze aufgestellt die bei der Entwicklung und Implementierung ber cksichtigt wurden e Die Kernelsourcen d rfen nicht
124. rt vio_vin c entnommen Listings besprochener Funktionen k nnen in Anhang B 3 nachgeschlagen werden Die Initialisierung des Video4Linux2 Treibers entspricht in weiten Teilen der des Framebuffertreibers Nach der Einrichtung der Speicherbank wird das 90 Vorhandensein der Hardware gepr ft Ein linearer nicht gecachter Speicher bereich der Gr e eines RGB24 Bildes mit der Aufl sung 720x576 Bildpunk te wird ebenfalls eingerichtet Der Videodecoderchip wird initialisiert um die Funktion des I C Bus zu pr fen Danach wird die Hardware deakti viert Wenn eine Applikation auf den Treiber zugreift wird die Hardware erneut initialisiert Solange bleibt die Hardware abgeschalten Beendet die letzte Applikation die Verbindung zum Treiber wird die Hardware wieder schlafen gelegt Diese Ma nahmen machen ein zus tzliches Powermanagment berfl ssig W hrend das Framebuffersubsystem den Zugriff auf den Bildspeicher bernimmt m ssen die Funktionen f r den Zugriff im Video4Linux Treiber implementiert werden Die Funktion mmap f r das Einblenden des Bild speichers in den Applikationsbereich wird im Zusammenhang mit den Stre amingfunktionen ben tigt mmap_request_buffers teilt den Bildspeicher in mehrere Puffer int mmap_request_buffers struct capture_device dev struct v412_requestbuffers req In der Implementierung werden maximal vier Puffer angelegt Die Hard wareeinstellungen repr sentiert durch die LartVIO Register werden be
125. s 720 x 74ns x 720 x 2Byte 64000ns 242 Byte zwischengespeichert werden Die Datentransferrate zwischen Prozessor und Videomodulen reduziert sich auf 720 2 ee ee tei Ee Zwischen Prozessor und Speicher wird der Speicherbus noch mit 3 42 92M Byte s 64 38M Byte s 62 belastet Die Maximalbelastung des Speicherbusses liegt bei 107 3 MByte s Soll die vertikale Austastphase ebenfalls zur Reduzierung der maximalen Datentransferrate genutzt werden wird ein Puffer der Gr sse 312 5 x 641s 288 x 6415 x 720 x 288 x 2 Byte 312 5 x 64us 32514 Byte ben tigt Die Datentransferrate eines Videostroms reduziert sich damit auf 19 77 MByte s Die Last auf dem Speicherbus betr gt noch 2 x 19 77M Byte s 39 55M Byte s f r den Datenstrom zwischen Prozessor und Videomodulen Der im Pro zessor nach RGB24 gewandelten Videostrom belastet den Speicherbus mit 3 39 55M Byte s SCH 59 33M Byte s Die Maximalbelastung des Speicherbusses reduziert sich auf 98 88 MByte s Der Videocontroller ACEX 1K besitzt in der gr ten Ausf hrung 6 KByte Ram F r die Pufferung der vertikalen Austastphase werden jedoch ca 2 32 KByte RAM ben tigt Eine vollst ndige Pufferung vertikalen Austastzeit ist nicht m glich Ausgehend von der in Abschnitt 2 2 3 ermittelten Daten transferleistung von ca 102 MByte s sind die bisherigen Ergebnisse f r die Videoeingabe und Videoausgabe nicht zufriedenstellend Die ben tigten D
126. si on 2 5 wird hier die gepr fte Struktur fb_var_screeninfo in der Struktur fb_info bergeben Die Funktion im aktuellen Kernel erh lt als bergabeparameter die in lartviofb_decode_var erzeugte interne Hardwarestruktur Die Dif ferenzen in der Funktionsweise wurden ber Hardwarestruktur lartvio_par gel st Sie enth lt die Struktur fb_var_screeninfo die in der Funktion lartviofb_decode_var gef llt wird In der Anpassung der bergabeparameter der Funktion lartviofb_set_par wird ber einen Zeiger auf die entsprechen de Struktur fb_var_screeninfo verwiesen Die Funktionen lartviofb_encode_fix und lartviofb_encode_var ge ben aktuellen Einstellungen der jeweiligen Struktur zur ck In der Kernel version 2 5 x wurde daf r generische Funktionen geschaffen Die Framebufferhardware kann ber die Funktion static int lartviofb_blank int blank_mode struct fb_info info in den Ruhezustand versetzt und wieder angeschalten werden Das Fra mebuffersubsystem sieht daf r vier verschiedene Zust nde vor wovon die Hardware nur zwei unterst tzt Alle Schlafmodi schalten die Videoausgabe hardware einschlie lich der FPGA Logik f r die Videoausgabe vollst ndig ab Beim Wiedereinschalten wird die Hardware neu initialisiert Die weiteren Funktionen werden durch den Consoletreiber aufgerufen und sind f r die Funktion des Framebuffertreiber nicht relevant 6 2 2 Video4Linux2 Alle Funktionen und Strukturen in diesem Abschnitt sind der Datei la
127. simulation des Farbkonverters RGB_YCbCr Auf eine vollst ndige Auflistung der Wellen formsimulationen wurde aufgrund der Gr e verzichtet Die Funktion vieler Module musste aus Performancegr nden in mehreren Schritten getestet wer den Das StrongARM Interface wurde nicht simuliert Es hat eine geringe Komplexit t bei einer gro en Anzahl von Ausgabesignalen Die Funktion des Modules wurde ber die Schnittstelle zum LART Board und die Funkti onstest nachgewiesen In Abschnitt 6 1 4 wurden bereits Probleme angesprochen die auf den Kompiliervorgang zur ckgef hrt wurden Die Zustandsmaschinen blockier ten zwar nicht mehr in undefinierten Zust nden die Fehler waren damit aber nicht behoben So zeigte die Bildausgabe bei einem Kompilat eine Folge wie derkehrender Streifen Die bertragung von Daten zum Hauptspeicher lief nicht Der FIFO der Videoausgabe musste also leer sein Ein leerer FIFO gibt jedoch immer das letzte im FIFO befindliche Datenwort zur ck Der FIFO aus den Altera Bibliotheken hat eine Unterlauf und Uberlaufsicherung Die Ausgabe hatte ein einfarbiges Bild liefern miissen Die Streifen deuteten auf ein st ndiges Durchlaufen des FIFO Speicher hin Das Problem konnte nicht weiter verfolgt werden da das Ergebnis nicht reproduzierbar war Nachdem das Empty Signal des FIFO zur Analyse auf einen Testpunkt gelegt wurde war der Fehler verschwunden Zu Testzwecken wurde der Farbkonverter der Videoeingabe entfernt Er ben tigt c
128. standsmaschine arbeitet synchron zum Takt Dabei wurde die Taktl nge mit L ns Lartbustakt 2 angenommen Wie bereits im Abschnitt 2 2 3 beschrieben muss beim Fastpagemode die Zeilenadresse nur einmal fiir die gesamte Zeile der Speichermatrix geschrieben werden Der Speicherzugriff reduziert sich damit auf trop speicherzugriff n typo wobei n die Gesamtzahl der Speicherzugriffe in derselben Zeile sind Der Fastpagemode des DRAM wurde in dieser Zustandsmaschine ber ck sichtigt Abbildung 6 1 zeigt die m glichen Zust nde und die bergangs bedingungen Die Zust nde newRow0 und newRow1 sichern die Erholzeit zwischen zwei RAS Zyklen Im Zustand CASL werden die Daten geschrie ben Bei EDO RAMs k nnen die Daten bis zur n chsten fallenden Flan ke von nCAS gelesen werden Die Daten werden daher erst im Zustand CASH1 bernommen Die Bedingungen f r einen Zustandswechsel sind am bergang notiert Bei berg ngen die keine Bedingung haben wird mit dem n chsten Takt in den neuen Zustand gewechselt sofern keine andere bergangsbedingung zutrifft Bedingt durch die Anordnung der Adresslei tungen Abbildung 2 4 ist ein Burstzyklus auf 256 Spalten begrenzt DEC_STOP ENC_DMA AND DEC_DMA Decoder DEC_DMA ENC STOP Abbildung 6 2 Zustandsmaschine fuer den Zugriff auf den DMA Eine weitere Zustandsmaschine verwaltet DMA Anforderungen von Video ein und Videoausgabe Die Signale ENC_STOP und ENC_DMA sowie DEC_STOP und DEC_DMA s
129. stellt werden Auf Grundlage des bttv Treibers wurde die Video4Linux API entworfen Gerd Knorr schreibt dazu auf Kno02 Late in the 2 1 x cycle Alan Cox stepped in with the idea to create a common API for that kind of hardware video4linux was born The idea is great But it turned out later that the actual implementation has a number of flaws Basically the API was desiged too much along the lines of the existing bttv driver 50 Diese API T 02 video4linux API html ist im derzeitig aktuellen Ker nel 2 4 18 implementiert Als Zeichenger t kann auf die Treiber ber read und write zugegriffen werden wobei je nach Art des Ger tes eine der bei den Operationen keinen Sinn machen kann Die Operation gibt dann als R ckgabewert den Fehler Invalid Value zur ck Mit der Operation mmap wird Applikationen der direkte Zugriff auf den Framebufferspeicher erm glicht indem der Framebuffer in den Nutzeradressraum eingeblendet wird Es kann Speicher f r mehrere Frames angefordert werden wobei die maximale An zahl der Frames von der Hardware und dem Video4Linux Treiber abh ngig ist W hrend der Verarbeitung eines Frames k nnen bereits weitere Frames angefordert werden Hier offenbart sich ein gravierender Designfehler Nach der Anforderung der Frames und Einblenden in den Applikationsadressraum d rfen die Eigenschaften des Bildes ver ndert werden Einstellung an Gr sse und Aufl sung ver ndern aber meist auch die Gr sse des ben tigten Spei
130. t 35 Feature EP1K30 EP1K50 EP1K100 Logikelemente 1728 2880 4992 EABs 6 10 12 Total RAM Bits 24 576 40 960 49 152 Tabelle 2 7 Merkmale der m glichen Bestiickungsvarianten des ACEX 1K Stromverbrauch Die Leistungsaufnahme des ACEX 1K kann mit P P nr Pro Ucosranpsy Iccacrive Voc Pro berechnet werden Die Leistungsaufnahme f r die IO Pins wird beeinflusst durch die angeschlossenen Ger te Die aktive Stromaufnahme entsteht im Umschaltzeitpunkt der Logikzellen Die aktive Stromaufnahme IccAcTIvE ist daher abh ngig von der Anzahl der Logikzellen und der H ufigkeit der Umschaltzust nde die durch den Takt beeinflusst werden Iccacr vs HA K fmax N togrc fmax die maximale Taktfrequenz N die Anzahl der verwendeten Logikelemente Loge die typische Anzahl der Logikelemente die jeden Takt schalten Nicht benutzte Logikelemente sollten daher ber den Clock Enable Ein gang gesperrt oder der Takt f r ganze Bereiche abgeschalten werden Entwicklungsumgebung F r die Programmung stellt Altera zwei Entwiclungsumgebungen MAX Plus II und Quartus II zur Verf gung Beide Entwicklungsumgebungen k nnen von Alteras Webseite heruntergeladen werden Sie unterscheiden sich von den kommerziell vertriebenen Versionen durch einen eingeschr nkten Funktions umfang Die Entwicklungsumgebungen erlauben das Design ber Schaltpl ne und Programmiersprachen wie Verilog HDL VHDL oder Altera
131. tasteter Doppelpixel wird als Y2 Cr Y1 Cb 32 Bitwert gespeichert In den nicht definierten Bereichen von 0 bis 15 und 236 241 f r Farbsi gnale bis 255 bei einer 8 Bit Speicherung k nnen zus tzliche Informationen bertragen werden F r die bertragung der Zeitinformationen dienen die Start Of Video SAV und End Of Video EAV Werte Im SA und EA Statuswort sind hori zonale und vertikale Synchronisationsinformationen sowie die Informationen ber das Halbbild ODD EVEN enthalten Austastphase Zeitreferenzcode 720 Pixel YCbCr 4 2 2 Daten Zeitreferenzcode 80 10 FF 00 00 SA CbO YO Cro Y1 Y719 FF 00 00 EA Tabelle 2 5 Daten bertragung des 4 2 2 Digital Component Video 8 Bit bertragung Von den 720 bertragenen Pixel sind nach CCIR nur 704 wirklich aktive Pixel Dadurch ergibt sich ein kleiner schwarzer Rand an der rechten und linken Seite des Videobildes 2 3 2 Der Videodecoder SAA7113 Der Videodecoder Phi99 besitzt vier Videoeing nge die als zwei Y C Eing nge vier FBAS Eing nge oder als Mischform ein Y C Eingang und zwei FBAS Eing nge geschalten werden k nnen Das Y C Format trennt das Helligkeits und Farbsignal F r dieses Format werden zwei Eing nge ben tigt Das FBAS Farbbild Austast Synchron Signal auch als CVBS oder Composite bekannt enth lt Farb und Helligkeitsinformationen und Synchronimpulse in
132. tel beschrie ben und die Schnittstellen zwischen Hard und Software definiert wurden besch ftigt sich dieses Kapitel mit der Implementierung der Treiber und des Hardwaredesigns Es werden einige vom Autor als interessant empfundene Teile der Implementierung n her beschrieben Ein sich anschlie ender Ab schnitt wird auf aufgetretene Probleme und deren L sungen eingehen Die Ergebnisse der Testumgebung stellen den Abschluss dieses Kapitels dar 6 1 FGPA F r die Implementierung des FPGA Designs nutzte Tigris Elektronik als Programmiersprache Altera HDL in Verbindung mit der Integrierten Ent wicklungsoberfl che Quartus II Webedition Herr Guido Kuhlmann entwarf ein Gundger st das an den eigenen Entwurf angepasst wurde 6 1 1 Das DMA Modul Eine Teilaufgabe des DMA Moduls liegt in der bertragung der Daten zwi schen Hauptspeicher und Videomodulen Dazu muss das DMA Modul den Prozessor vom Speicherbus trennen und die Steuersignale f r den Speicher selbst generieren F r die Abkopplung des Prozessors vom peripheren Bus stellt der SA1100 zwei Steuerleitungen zur Verf gung die als alternative Funktionen der Pins GPIO21 und GPIO22 auch am High Speed Connector der Verbindung zwischen LART Board und LartVio zur Verf gung stehen Mit MBREQ wird der periphere Bus angefordert Der StrongARM beendet seine Buszugriffe und signalisiert ber MBGNT die Freigabe des Busses Der Prozessor arbeitet mit seinem internen Cache weiter bis zu einem notw
133. ten 2D Funktionen erweitert Die Framebuffer API wird vollst ndig von dem Consoletreiber Subsystem getrennt so dass der Framebuffertreiber ohne Consoletreiber lauffahig ist Die Anderungen am Design sind noch nicht vollstiindig abgeschlossen In den Headerdateien existiert bereits ein Hinweis darauf dass die Struktur display entfernt wird Zur Zeit muss sie aber noch benutzt werden Einige Erweiterungen f r Embedded Ger te werden in Sim02b beschrieben 3 5 Video4Linux Der Name Video4Linux ist ein wenig irref hrend Video4Linux soll eine API f r Multimediager te sein Dazu geh ren neben TV und Videograbbertreiber auch Treiber f r Radiokarten Komprimierer Dekomprimierer Effekthard ware und Teletext Video4Linux ist kein Subsystem das eigene Funktiona lit t oder Protokolle implementiert Es werden lediglich die Treiber verwaltet und Applikationaufrufe an die Treiber weitergeleitet Es stellt mehr eine Spe zifkation der Schnittstellen dar Aufgrund der historischen Entwicklung der API stehen zur Zeit zwei in kompatible Versionen zur Verf gung die in den n chsten beiden Abschnitten er rtert werden Dabei konzentriert sich der Blick auf Videoeingabeger te 3 5 1 Die Video4Linux API Die erste Version der API entstand aus der Notwendigkeit den bttv Treiber einen Treiber f r TV Karten mit Booktree Chipsatz in den Kernel zu inte grieren K nfigen Applikationen sollte eine einheitliche Schnittstelle zu den Treibern bereitge
134. ter structure 117 gen fbinfogen includes all parameter structures static int lartviofb_encode_var struct fb_var_screeninfo var const void vpar struct fb_info_gen gen 10 Returns negative errno on error OT zero ON SUCCESS var struct fb_var_screeninfo amp gen gt info var return 0 B 2 6 Die Funktion lartviofb_blank J lartviofb_blank Blanks the display blank_mode the blank mode we want RW info frame buffer structure that represents a single frame buffer Blank the screen if blank_mode 0 else unblank Return 0 if blanking succeeded 0 if un blanking failed due to e g a video mode which doesn t support it Implements VESA suspend i and powerdown modes on hardware that supports disabling hsync vsync 4 blank mode 2 suspend vsync 10 7 blank_mode 3 suspend hsync blank_mode 4 powerdown a LartVIO will powered down if blank_mode 0 a Returns negative errno on error or zero on success 4 if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 20 static int lartviofb_blank int blank_mode struct fb_info info else static void lartviofb_blank int blank_mode struct fb_info info endif int arg int nblank blank_mode struct lartvio_par par struct lartvio_par info gt par disable and reset encoder 30 if blank_mode par gt adv gt driver gt command par gt adv ENABLE_OUTPUT 118 amp nblank par
135. tigen In Tabelle A 1 sind die Ergebniss f r memcpy und die optimierte Assemblerroutine aufgef hrt Die Assemblerroutine greift bei Lesezugriffen mit Burst Of Eight und bei Schreib zugriffen mit Burst Of Four auf den Speicher zu Die bertragung mit Burst Of Eight kann ber das Verh ltnis zur berechneten bertragsleistung mit Burst Of Eight n herungsweise ermittelt werden 86M Byte s x 102 76M Byte s 102 76M Byte s 77 5M Byte s BurstO f Eightrea 98M Byte s Die maximale real erreichbare bertragungsleistung liegt in der Region der berechneten Transferleistung Externe Busmaster Der SA1100 unterst tzt externe Ger te die den Speicher selbst ansprechen k nnen Der alternative Busmastermode nutzt die GPIOs 21 und 22 als Steu erleitungen Dazu m ssen die alternativen Funktionen der GPIOs aktiviert und der Testcontroller abgeschalten werden Die GPIOs 21 und 22 besizten 25 zwei alternative Funktionen die ber das Register TUCR ausgew hlt wer den GPIO 21 bernimmt die MBREQ Funktion die mit einem aktiven Si gnal eine Anfrage des externen Busmaster signalisiert Der Prozessor beendet eventuelle Buszugriffe und schaltet alle Address Daten und Steuerleitungen in den hochohmigen Zustand MBGNT GPIO 22 signalisiert die Freigabe des Busses Der externe Busmaster kann die Steuerung des Speicherbusses bernehemen Nach Beendigung seiner Aktivit ten auf dem Speicherbus de aktiviert der externe Busmaster das MBR
136. tionen ebenfalls in den Videocontroller integriert werden Die Ger tetreiber bernahmen nur noch die Initialiserung der Hardware Die Treibersubsysteme f r die Version des Betriebssystems waren zum Zeitpunkt der Diplomarbeit in einem fr hen Entwicklungsstadium Die Schnitt stellen zu den Hardwaretreibern wurden h ufig ge ndert Das Framebuf fersubsystem nderte vor allem die Schnittstellen zu den Ger tetreibern Die Funktionalit t des Treibers nderte sich nur geringf gig F r das Vi deo4Linux Subsystem ist bereits seit 1999 eine zweite stark erweiterte Versi on verf gbar die die alte Version des Video4Linux Subsystems in der n chsten stabilen Betriebssystemversion abl sen soll Da Video4Linux2 auch f r den derzeit aktuellen Kernel kompiliert werden kann wurde Video4Linux2 als Subsystem f r den Videoeingabetreiber gew hlt In der Anforderungsanalyse fiel die Auswahl der notwendigen Farbfor mate schwer Jedes Farbformat hat seine St rken und Schw chen Je nach Anwendungsfall sind unterschiedliche Anforderungen an das Farbformat zu stellen Aus diesem Grund wurde eine einfache Schnittstelle zur Implementie rung eigener Farbraumkonverter und anderer videoverarbeitenden Einheiten entworfen Bis zu vier verschiedene Farbraumkonverter k nnen vom Treiber ausgew hlt werden Denkbar sind aber auch verschiedene Videofilter die zu geschalten werden k nnen Das Design des Videocontroller ist modular aufgebaut Damit l t sich d
137. tsignals emuliert 71 Videodecoder Schnittstelle YCbCr gt RGB weitere Video weitere Video weitere Video Skalierung bearbeitung bearbeitung bearbeitung Modulw hler Datenpuffer Abbildung 5 7 Datenfluss Videoeingabe Videobearbeitung VID_PROC datal31 01 q 31 0 date_en qra Clock enable reset Abbildung 5 8 Die Schnittstel le Videobearbeitung Fiir die Manipulation des Videostroms wur de eine Schnittstelle entwickelt die von der Videodecoderschnittstelle Daten empfangen und den ver nderten Videostrom in den Da tenpuffer schieben kann Die Konvertierung des YCbCr Formates nach RGB24 wird ein Modul sein das diese Schnittstelle nutzt Die Schnittstelle definiert alle notwendigen Signale kann aber je nach Modul um zus tzliche Eigenschaften erweitert werden Die entwickelte Schnittstelle kann ebenfalls bei einer mehrstufigen Verarbeitung verwen det werden So ist es m glich eine Skalierung vor die Farbraumkonverter zu setzen In der Schnittstelle ist die m gliche Pipelinetiefe nicht definiert Diese muss f r den entsprechenden Einsatz definiert werden Damit ist es unter anderem m glich diese Schnittstelle ebenfalls f r die Videoverarbeitung auf der Videoausgabeseite zu verwenden 72 5 3 5 Videoausgabe Der Datenbus des A
138. u 24 00 au wos EN He Ga 109 B 11 YCbGr y CoCritdf Auszug aa eb dies e we 109 B 2 Ausz ge aus lartviofb c Framebuffertreiber 111 B 2 1 Die Funktion lartviofb_check_var bzw lartviofb_decode_var111 B 2 2 Die Funktion lartviofbset par 113 B 2 3 Die Funktion lartviofbinit fpga 116 B 2 4 Die Funktion lartviofb_encode fx 117 B 2 5 Die Funktion lartviofbencode_var 117 B 2 6 Die Funktion lartviofb_blank 118 B 3 Ausz ge aus lartvio_vin c Video4Linux2 Treiber 120 B 3 1 Die Funktion mmap_request_buffers 120 B 3 2 Die Funktion capture_queuebuffer e 122 B 3 3 Die Funktion mmap_unrequest_buffers 123 C Testprotokolle 124 Cl Framebuffer API Test 00a aa 124 C 2 Video4Linux2 Test 4 2 2 002 2 4 2 2 ea van awe oe EH 126 Cas Wellenformsimulation A 3 e mg fu dey EE ee ae 127 GA Langzeittests zu 0 ee NEI E pled em wd em Ba 129 D CD Inhalt 134 Abbildungsverzeichnis 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 2 9 2 10 2 11 2 12 2 13 2 14 2 15 2 16 3 1 3 2 3 3 3 4 3 9 3 6 Blockschaltbild des BV Boards 13 LART Board Oberseite aus LARak 14 StrongARM Blockschaltbild aus Int99 Functional Descrip WOU a ea Sneek ee A ek Se ee E ee eee eS 17 Zuordnung der CPU Adressbits zu Speichermatrix 20 Fast Page Mode nach Oet97 aa 21 Zeilen und
139. umentation der Hardwaretreiber f r das Framebuffersubsystem reduziert sich auf die Kommentare des Skeletontreiber skeleton c im Kernel baum Sie stellen ein Grundger st f r die Implementierung eigener Treiber mit Quelltextdokumentation dar Die Funktionen f r Hardwarebeschleuni gung k nnen durch generische Funktionen ersetzt werden da das FPGA Design keine Hardwarebeschleunigung vorsieht Ber cksichtigt werden muss weiterhin die Forderung zur Abschaltung der Videoausgabe Die Schnittstelle zum Subdesign sieht daf r die Funktion blank vor 5 4 2 Video4Linux Die Video4Linux2 API wird seit 1999 entwickelt Sie kann mit der stabilen Kernelversion 2 4 x compiliert und verwendet werden Die Video4Linux2 API soll bis zur Ver ffentlichung des stabilen Kernel 2 6 die alte Video4Linux API ersetzen und stellt bereits deren Funktionalit t ber Kompatibilit tstreiber zur Verf gung ltere Treiber die f r die Video4Linux API geschrieben wur den k nnen somit weiter verwendet werden Die Video4Linux2 API ist in 3 5 2 ausf hrlich dokumentiert Es m ssen nur die API Funktionen implementiert werden die die Hardware unterst tzt Alle anderen Funktionen kehren mit Fehlerwert zur ck F r die Umsetzung der Funktionalit t entsprechend den Anforderungen m ssen folgende Funk tionen der API realisiert werden e read soll den einfachen Zugriff auf Bilder erm glichen e mmap bietet in der Video4Linux2 API im Zusammenhang mit den ioctl Komman
140. us LARak 2 2 1 Die Schnittstellen des LART Boards Fast alle verf gbaren Signale des Prozessors wurden f r externe Erweite rungen zug nglich gemacht Daher residieren neben den standardisierten Schnittstellen vier weitere Steckverbinder auf dem LART Board Der High Speed Connector befindet sich auf der Oberseite die Verbinder J2 J4 auf der Unterseite des LART Boards ber zwei serielle Schnittstellen kann je ei ne Terminalverbindung mit dem LART Board aufgebaut werden Tabelle 2 1 gibt einen berblick ber die Schnittstellen des LART Boards Im folgenden werden diese Schnittstellen n her beschrieben 14 Connector Schnittstellen Gr e Lage Power Stromversorgung 4 polig seitlich Reset Resetschalter 2 polig seitlich RS232 2 x serielle Schnittstelle 6 polig seitlich JTAG JTAG Interface Hardwaredebug 8 polig seitlich ging J1 High Speed Adress und Datenleitungen 100 polig oben Connector PCMCIA GP21 GP27 J2 Adress und Datenbus Connector 40 polig unten J3 RS232 USB IRDA PCMCIA 40 polig unten JTAG Signale J4 GPIO LCD sowie weitere 40 polig unten PCMCIA Signale Tabelle 2 1 Schnittstellen des LART Boards Powerconnector und Reset Das LART Board kann laut LARak mit 3 5 bis 16 V betrieben werden In der LART Mailing Liste wurde vor dem Betreiben ber 7 5V gewarnt da ei nige Teile der Spannungsversorgung nicht f r so hohe Spannungen spezifizi
141. ver ndert werden e Eine Splittung in mehrere Treiberversionen f r verschiedene Kernelver sionen sollte vermieden werden da es sp ter den Aufwand erh ht die Sourcen auf dem aktuellen Stand zu halten e Als Codingstyle wird der in T 02 CodingStyle txt beschriebene Stil verwendet um die eventuelle Integration in den Kernelbaum zu erleich tern e Kommentare werden durchgehend in Englisch geschrieben Die Implementierung der Treiber kann in zwei Varianten erfolgen Der Treiber kann als Patch in den Kernelbaum eingebunden werden oder als ei genst ndige Sourcen vorliegen Ein Patch bietet Vorteile bei der Integration 74 der Sourcen in den Kernel So k nnen im Kernel vorhandene Sourcen ange passt werden und die Treiber in die Konfigurationstools des Kernel aufge nommen werden Nachteilig ist der erh hte Aufwand bei der Pflege der Pat ches da sie an jede Kernelversion angepasst werden m ssen Eigenst ndige Sourcen bieten eine h here Portabilit t zwischen den einzelnen Kernelversio nen Sie integrieren sich jedoch nicht in die Konfigurationstools Insbesondere Abh ngigkeiten zu anderen Treibern und Subsystemen k nnen nicht abge bildet werden Neben dem Framebuffertreiber und dem Video4Linux Treiber sind wei tere Ger tetreiber f r die Ansteuerung des Encoder und Decoderchips ber den I C Bus notwendig Diese Treiber abstrahieren die m glichen Einstellun gen der Chips und sind nicht mit dem Framebuffertreiber und dem
142. we 10 intent to only test a mode and not actually set it The stuff in modedb c is a example of this If the var passed in is slightly off by what the hardware can support then we alter the var PASSED in to what we can do If the hardware doesn t support mode change a EINVAL will be returned by the upper layers You don t need to implement this function then x SS SS 2 2 2 X XK Returns negative errno on error OT Zero ON SUCCESS 20 if LINUX_VERSION_CODE gt KERNEL_VERSION 2 5 6 static int lartviofb_check_var struct fb_var_screeninfo var struct fb_info info d struct lartvio_par par struct lartvio_par info gt par int line_length else static int lartviofb_decode_var const struct fb_var_screeninfo var void vpar struct fb_info_gen gen d struct lartvio_par par struct lartvio_par vpar 30 struct lartvio_par gpar struct lartvio_par gen gt info par int line_length memcpy amp par gt mvar var sizeof struct fb_var_screeninfo par gt videomemorysize gpar gt videomemorysize par gt videomemory gpar gt videomemory par gt map_dma gpar gt map_dma par gt map_size gpar gt map_size par gt encaddr gpar gt encaddr par gt adv gpar gt adv 40 111 endif if var gt xres lt 144 var gt yres lt 80 min 144180 Pixel var gt xres gt 720 var gt yres gt 576 maz PAL size var gt
143. wurden ausschlie lich Festkommaeinheiten verwendet um die Anzahl der verwendeten Logikeinheiten des FPGA so gering wie m glich zu halten 85 Als Ergebnis der Konvertierung werden Y1 Cbl Crl und Y2 fiir einen vollst ndigen YCbCr Wert ben tigt Das Ergebnis wird in zwei Stufen gebil det Stufe 1 RGB1 gt Y1 Cb Cr Stufe 2 RGB2 gt Y2 Die Multipliziereinheiten enthalten eine zweistufige Pipeline Der Timing analysator von Quartus II ermittelte eine maximale Taktfrequenz von ca 60 MHz f r den EP1k100QC208 2 Soll der FPGA mit vollem LART Bustakt arbeiten m ssen weitere Pipelinestufen eingef gt und die Signale YResul tready und q_rd angepasst werden Die nachfolgenden Additionen wurden ohne Latenz implementiert Bei h herer Taktfrequenz kann sich die Notwen digkeit ergeben hier ebenfalls eine Pipelinestufe einzuf gen Die Ergebnisse des ersten RBG Wertes werden zwischengespeichert Mit dem Ergebnis des Y Wertes f r den zweiten Pixel werden die Werte an die nachfolgende Einheit bergeben Bei eingeschalteter Skalierung wird jeder RGB Wert als YCbCr Doppelpixel ausgegeben Im Videoeingabemodul wurde ein zweiter Farbkonverter implementiert der das YCbCr Signal weiterleitet Er soll als einfaches und vom Code ber sichtliches Beispiel f r weitere Implementierungen von Videobearbeitungs modulen dienen Die Skalierung des Konverters verwirft jeden zweiten Dop pelpixel Das Listing ohne Kommentarkopf ist in Anhang B 1 1 zu f
144. ymposium 2002 http linuxconsole sourceforge net paper Dieter Stotz Computergest tzte Audio und Videotechnik Mul timediatechnik in der Anwendung Springer Verlag Berlin 1995 Linux Kernel Coding Style Kernel documentations 2002 http www purists org linux Linus Torwald et al Kernel documentations 2002 http www kernel org Peter Urbanek Mikrocomputertechnik B G Teubner Stuttgart Leipzig 1999 Markus Wannemacher Das FPGA Kochbuch International Thomson Publishing GmbH Bonn 1998 137 Zoo01 Wiebe Zoon Console programming HOWTO 2001 http ibiblio org gferg ldp Console Programming HOWTO 138
145. zur Verf gung Beispiele f r Blockger te sind die SCSI und IDE Treiber Die unterst tzten Operationen werden in der Struktur block_device_operations definiert Subsysteme stellen f r verschiedene Ger te einer Klasse eine Grundfunk tionalit t bereit und definieren eine einheitliche Schnittstelle f r den Zugriff auf die Ger te Das SCSI Subsystem unterst tzt die Treiber f r die ver schiedenen Chips tze mit einer gemeinsamen Schnittstelle und einer Verwal tungsebene F r die Applikation bzw hier die nachfolgende Treiberschicht CDROM Disk usw ist der Zugriff transparent auch wenn mehrere SCSI Treiber bedient werden H ufig werden in der Schnittstelle Kommandos und deren Argumente die an den Ger tetreiber ber den Systemaufruf ioctl bergeben werden spezifiziert 46 3 3 1 Adressr ume Multitaskingbetriebssysteme nutzen f r die Adressierung virtuelle Adressen F r den Zugriff auf I O Adressen m ssen die realen Adressen in den virtuellen Adressraum eingeblendet werden Linux unterscheidet dabei zwischen Vgl T 02 IO mapping txt Physische Adressen wie Sie auf dem Speicherbus au erhalb des Prozessors existieren Mit diesen Adressen greift die CPU auf den Speicher zu Virtuelle Adressen die ber die MMU des Prozessors in physische Adressen gewandelt werden Diese Adressen existieren nur innerhalb des Prozes sors Busadressen sind die Adressen der externen Ger te mit denen Sie auf den Bus zugreifen Fiir

Diplomarbeit - Fachhochschule Brandenburg

Contents

Download Pdf Manuals

Related Search

Related Contents