Subversion Repositories shark

Rev

Rev 177 | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
174 giacomo 1
Guida all'uso del driver BTTV per S.Ha.R.K
2
Giacomo Guidi <giacomo@gandalf.sssup.it>
3
 
4
DIRECTORY DEL DRIVER: shark/drivers/bttv/
5
SIMBOLO NEL MAKEFILE PER INSERIRE LA LIBRERIA: __BTTV__
6
 
7
Il nuovo driver per Frame Grabbers e' preso al 90% dall'analogo
8
driver linux e supporta buona parte delle schede dotate di BT848
9
in commercio.
10
 
11
E' stato integrato anche un supporto al bus I2C necessario
12
per accedere ai sotto-sistemi interni al Frame Grabber,
13
come chip audio o sintonizzatori televisivi.
14
 
15
Per utilizzare questo driver si puo' passare dai comandi base
16
del driver BTTV, definiti dentro bttv-driver.c oppure usare una
17
veloce interfaccia (fg.c) che ho creato per ridurre al minimo le
18
operazioni di inizializzazione e uso della periferica.
19
 
20
-------------------------------------------------------------------------------
21
Header e funzioni per l'uso semplificato
22
-------------------------------------------------------------------------------
23
 
24
//Header delle funzioni per l'uso facilitato del Frame Grabber
25
#include <drivers/fg.h>
26
 
27
//Header per le strutture e funzioni a basso livello del BTTV
28
#include <driver/bttv.h>
29
 
30
//Istruzione di inizializzazione semplificata
182 giacomo 31
FG_init(period,wcet,width,height,color,channel);
174 giacomo 32
 
33
---
34
period: periodo del grabbing, ovvero quanti microsecondi passano
35
	fra ogni campianamento dell'immagine
36
 
37
wcet:	durata massima del task di grabbing. Definisce quanto
38
	deve durare al massimo il campionamento + l'elaborazione
39
	dell'immagine.
40
 
41
width:	larghezza finestra di campionamento
42
 
43
height: altezza finestra di campionamento
44
 
177 giacomo 45
color:  puo' essere FG_MONO o FG_RGB24
46
 
182 giacomo 47
channel: canale video, solitamente settato a 0
48
 
174 giacomo 49
Esempio:
50
---
51
 
182 giacomo 52
FG_init(50000,15000,400,300,FG_MONO,0);
174 giacomo 53
 
54
---
55
 
56
Attenzione al periodo di campionamento, e' buona regola non scendere
57
sotto i 40000 us ovvero 25 fps. Bisogna tenere presente che il frame
58
grabber usa massicciamente il bus PCI e il DMA per spostare il flusso
59
delle immagini. Va sempre settato il massimo periodo possibile che la
60
vostra applicazione richiede, evitate di sprecare risorse con grabbing
61
a 25 fps se poi non c'e' il tempo di gestire tutte le immagini raccolte.
62
 
63
Il pricipio base e' che nessuna immagine va sprecata. Per cui se il
64
processore permette di elaborare solo 1 immagine ogni 120000 us, non
65
settate il FG a 40000 us per poi usare 1 immagine su 3.
66
 
67
Per cercare di usare bene le risorse di sistema ed evitare una gestione
68
errara dei buffer del FG ho inserito una funzione virtuale
69
 
70
elaborate_frame_hook <fg.c>
71
 
72
che viene chiamata ad ogni inizio del ciclo di grabbing. Questa funzione
73
di default e' inizializzata a dummy_elaborate_frame, per cui non fa
74
niente, ma puo' essere usata dall'utente se e' richiesta una qualche
75
elaborazione dell'immagine... puo' essere una copia del buffer nella
76
memoria video per vedere il grabbing in azione o un complicato
77
algoritmo di tracking.
78
 
79
Se ad esempio creo una funzione tipo
80
 
81
frame_elaborate(void *imageptr) {
82
 
83
  //Codice di elaborazione
84
 
85
}
86
 
87
dove lavoro l'immagine presa. Posso chiamare
88
 
89
FG_sethook(frame_elaborate)
90
 
91
per fare in modo che frame_elaborate venga chiamata automaticamente
92
ad ogni immagine acquisita. Se ad esempio frame elaborate e' troppo
93
complicata puo' capitare che venga mancata la deadline del task di
94
grabbing (hard_task). A quel punto o si riducono i calcoli di questa
95
funzione o si aumenta il periodo di grabbing.
96
 
97
Se non si ottengono deadline miss significa che tutto funziona bene
98
e sicuramente la funzione elabora sempre l'ultima immagine registrata.
99
Il grabber infatti usa il sistema del Double Buffer, per cui l'immagine
100
su cui si lavora e' sempre completa ed integra.
101
 
102
Per passare parametri alla funzione frame_elaborate penso sia piu'
103
facile ricorrere a variabili globali piuttosto a passaggi di variabili
104
generiche ridefinite volta per volta. Per cui la funzione di elaborazione
105
deve essere sempre definita in questo modo:
106
 
107
void nome_funzione(void *imageptr);
108
 
177 giacomo 109
Tenete conto che con FG_RGB24 invece di 1 byte per pixel nel buffer
110
passate ad una modalita' RGB.
174 giacomo 111
 
177 giacomo 112
Dopo averlo inizializzato chiamate
174 giacomo 113
 
177 giacomo 114
FG_start_grabbing();
115
 
116
per farlo partire.
117
 
174 giacomo 118
-------------------------------------------------------------------------------
119
Consigli per il Frame Grabber in generale.
120
-------------------------------------------------------------------------------
121
 
122
Giocando con i paramentri di luminosita', contrasto e saturazione si
123
riesce a rendere l'immagine piu' semplice da elaborare (ad esempio per fare
124
il tracking di un oggetto in moto) senza ricorre a complicati algoritmi che
125
andrebbero a pesare sul processore.
126
 
127
Queste funzioni vengono chiamate da bttv_ioctl definita in bttv-driver.c
128
 
129
Prima di inizializzare il FG con la grafica provate a farlo partire in
130
modalita' testo, cosi' l'output a schermo vi permette di vedere se la
131
routine di init va a buon fine o se ci sono delle anomalie.
132
 
133
Una volta che sieti sicuri venga riconosciuta la vostra scheda e' buona
134
regola inizializzare il FG DOPO LA SCHEDA VIDEO. Questo perche' ho
135
riscontrato alcuni problemi con gli interrupt chiamati dalla VESA se il FG
136
e' gia' in funzione.
137
 
138
-------------------------------------------------------------------------------
139
Programma di esempio: BTTVDEMO
140
-------------------------------------------------------------------------------
141