Subversion Repositories shark

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
-------------------------------------------------------------------------------