0,0 → 1,139 |
Guida all'uso del driver BTTV per S.Ha.R.K |
Giacomo Guidi <giacomo@gandalf.sssup.it> |
|
DIRECTORY DEL DRIVER: shark/drivers/bttv/ |
SIMBOLO NEL MAKEFILE PER INSERIRE LA LIBRERIA: __BTTV__ |
|
Il nuovo driver per Frame Grabbers e' preso al 90% dall'analogo |
driver linux e supporta buona parte delle schede dotate di BT848 |
in commercio. |
|
E' stato integrato anche un supporto al bus I2C necessario |
per accedere ai sotto-sistemi interni al Frame Grabber, |
come chip audio o sintonizzatori televisivi. |
|
Per utilizzare questo driver si puo' passare dai comandi base |
del driver BTTV, definiti dentro bttv-driver.c oppure usare una |
veloce interfaccia (fg.c) che ho creato per ridurre al minimo le |
operazioni di inizializzazione e uso della periferica. |
|
------------------------------------------------------------------------------- |
Header e funzioni per l'uso semplificato |
------------------------------------------------------------------------------- |
|
//Header delle funzioni per l'uso facilitato del Frame Grabber |
#include <drivers/fg.h> |
|
//Header per le strutture e funzioni a basso livello del BTTV |
#include <driver/bttv.h> |
|
//Istruzione di inizializzazione semplificata |
FG_init(period,wcet,width,height); |
|
--- |
period: periodo del grabbing, ovvero quanti microsecondi passano |
fra ogni campianamento dell'immagine |
|
wcet: durata massima del task di grabbing. Definisce quanto |
deve durare al massimo il campionamento + l'elaborazione |
dell'immagine. |
|
width: larghezza finestra di campionamento |
|
height: altezza finestra di campionamento |
|
Esempio: |
--- |
|
FG_init(50000,15000,400,300); |
|
--- |
|
Attenzione al periodo di campionamento, e' buona regola non scendere |
sotto i 40000 us ovvero 25 fps. Bisogna tenere presente che il frame |
grabber usa massicciamente il bus PCI e il DMA per spostare il flusso |
delle immagini. Va sempre settato il massimo periodo possibile che la |
vostra applicazione richiede, evitate di sprecare risorse con grabbing |
a 25 fps se poi non c'e' il tempo di gestire tutte le immagini raccolte. |
|
Il pricipio base e' che nessuna immagine va sprecata. Per cui se il |
processore permette di elaborare solo 1 immagine ogni 120000 us, non |
settate il FG a 40000 us per poi usare 1 immagine su 3. |
|
Per cercare di usare bene le risorse di sistema ed evitare una gestione |
errara dei buffer del FG ho inserito una funzione virtuale |
|
elaborate_frame_hook <fg.c> |
|
che viene chiamata ad ogni inizio del ciclo di grabbing. Questa funzione |
di default e' inizializzata a dummy_elaborate_frame, per cui non fa |
niente, ma puo' essere usata dall'utente se e' richiesta una qualche |
elaborazione dell'immagine... puo' essere una copia del buffer nella |
memoria video per vedere il grabbing in azione o un complicato |
algoritmo di tracking. |
|
Se ad esempio creo una funzione tipo |
|
frame_elaborate(void *imageptr) { |
|
//Codice di elaborazione |
|
} |
|
dove lavoro l'immagine presa. Posso chiamare |
|
FG_sethook(frame_elaborate) |
|
per fare in modo che frame_elaborate venga chiamata automaticamente |
ad ogni immagine acquisita. Se ad esempio frame elaborate e' troppo |
complicata puo' capitare che venga mancata la deadline del task di |
grabbing (hard_task). A quel punto o si riducono i calcoli di questa |
funzione o si aumenta il periodo di grabbing. |
|
Se non si ottengono deadline miss significa che tutto funziona bene |
e sicuramente la funzione elabora sempre l'ultima immagine registrata. |
Il grabber infatti usa il sistema del Double Buffer, per cui l'immagine |
su cui si lavora e' sempre completa ed integra. |
|
Per passare parametri alla funzione frame_elaborate penso sia piu' |
facile ricorrere a variabili globali piuttosto a passaggi di variabili |
generiche ridefinite volta per volta. Per cui la funzione di elaborazione |
deve essere sempre definita in questo modo: |
|
void nome_funzione(void *imageptr); |
|
L'inizializzazione di default imposta il grabbing in modalita' GREY8 |
ovvero 8 bpp e a toni di grigio. Non ho ancora sperimentato completamente |
la modalita' a colori, per cui se volete fare dei test andate a cambiare |
"fg.c" provando a modificare i diversi tipi di palette a seconda di cosa |
permette il vostro frame grabber. Teoricamente settando la modalita' a |
colori e usando una telecamera a colori tutto dovrebbe funzionare bene. |
|
Tenete conto che invece di 1 byte per pixel nel buffer passate ad |
una modalita' RGB. |
|
------------------------------------------------------------------------------- |
Consigli per il Frame Grabber in generale. |
------------------------------------------------------------------------------- |
|
Giocando con i paramentri di luminosita', contrasto e saturazione si |
riesce a rendere l'immagine piu' semplice da elaborare (ad esempio per fare |
il tracking di un oggetto in moto) senza ricorre a complicati algoritmi che |
andrebbero a pesare sul processore. |
|
Queste funzioni vengono chiamate da bttv_ioctl definita in bttv-driver.c |
|
Prima di inizializzare il FG con la grafica provate a farlo partire in |
modalita' testo, cosi' l'output a schermo vi permette di vedere se la |
routine di init va a buon fine o se ci sono delle anomalie. |
|
Una volta che sieti sicuri venga riconosciuta la vostra scheda e' buona |
regola inizializzare il FG DOPO LA SCHEDA VIDEO. Questo perche' ho |
riscontrato alcuni problemi con gli interrupt chiamati dalla VESA se il FG |
e' gia' in funzione. |
|
------------------------------------------------------------------------------- |
Programma di esempio: BTTVDEMO |
------------------------------------------------------------------------------- |
|
|