Driver
Developments Notes
1. Creation of kernel
module pikam_simul.ko
In order to be able to test new changes ( not very significant but
important ) without need of cameras I created kernel module
pikam_simul.ko.
It can be compiled and loaded :
su -
cd
$SRCDIR/ccd/ccddriver/picamdrv2K2K/pikam_simul/
./configure
make
insmod pikam_simul.ko
after that camera program can be launched and it will simulate normal
camera , except images which will be filled with constant value = 257 (
or 258 )
When testing this very simple module I noticed that it does not work on
kernels different then 2.6.6 , but it does not have anything to do with
USB.
But normal driver has also problems on other kernels then 2.6.6.
The problem was in GetDataIOCTL ( skel_ioctl ) pikam.ko kernel module
function which uses buffer of size 4096 bytes which probably exceeds
size of
the memory page in kernel causing oops error and computer hangs !!!!!
After changing buffer size to 1024 bytes kernel driver simulator
works fine on any kernel ( in fact I checked on heplx43-
2.6.5-1.358.smp and heplx42-2.6.18-1.2869.fc6 )
Now I must test it on normal camera
2. Compilation problems on kernels
!= 2.6.6
On kernels different then 2.6.6 the following compilation problems
where noticed :
- include <linux/config.h> - file config.h was removed in
later kernel versions so it is possible to coment out this lines
without problem
- same problem with file : #include <linux/devfs_fs_kernel.h>
- chyba tez define MODULE_PARAM zostal wywalony i musialem
wykomentowac jego uzycie
3. "Nuclear Problems" :-)
Looking for solution of this problem I found several interesting
links about writing linux kernel drivers :
http://www.tldp.org/LDP/lkmpg/2.6/html/lkmpg.html
http://www.nsc.res.in/~elab/das/driverguide/index.html
http://www.linuxjournal.com/article/7353
http://forum.slackware.pl/viewtopic.php?t=13436
I saw people use calls to spin_lock_irq and lock_kernel , but I don't
know what it does yet , probably it is used only in specific cases,
because in some places it was not used
5. Problems with usbtest.ko
On systems >=FC2 with kernel compiled with usbtest.ko module it is
problem, because this module does not allow to load pikam.ko correctly.
It must be turned off , the best way I found till this moment is to go
to /lib/modules/drivers/usb/ ... and move file :
mv usbtest.ko
usbtest.ko.sav
On FC2 2.6.5-1.358smp location was :
/lib/modules/2.6.5-1.358smp/kernel/drivers/usb/misc/
6. ADC range settings corrections
Zaczac od przesledzenia korespondencji e-mail zaczynajac od : 9864 Mar 27 albo lepiej tutaj : 9976
Mar 31
Korespondencja :
JA :
Z tego co widze to chyba
faktycznie jest tam jakis blad, tzn
default jest 4V , ale jak sie
ustawia na 2V to bit 7 nie jest zerowany czyli
idzie tam dokladnie to samo co
przy 4V , takze pewnie dlatego nie
ma zadnej roznicy.
Ale wyglada mi na to ze default
to wlasnie 4V . Z tym ze nie do konca
rozumiem chyba jak to powinno
byc, bo z dokumentacji
http://grb.fuw.edu.pl/pi0/work/camera_drivers.html
wynika mi ze ze dla
4V powinno byc wysyalnie
0x80
a dla
2V - 0x00
GREG :
czyli zera, natomiast Grzesiek
napisal ze dla 4V ustaiwa rejesrt na sztywno
208 wiec czegos tu chyba nie
rozumiem jak to powinno byc
80 - 2V ,ustawienie domyslne, bit 7 wyczyszczony
208 - 4V - , bit 7 ustawiony
liczby oczywiscie dziesietnie, tak jak w pliku config :-)
Na razie poszukac co jest tutaj : Device2K2K::InitGainDefaults ,
co tam sie przestawia przy zmianach paramterow ?
7. Double sideded readout
Najmlodszy bit bajtu statusu ( jakiegos nie uzywanego ) bedzie zawieral
0-normalna kamera, 1-obustronnie odczytywana kamera
Chyba chodzi o odpowiedz na komende 0xEF czyli na ta od ID , wtedy
chodzi o najmlodszy bit 8 bajtu statusu czyli :
m_szFullDeviceID[8]
jeszcze sie upewniam u Macka i Dominika.
Wlasciwie zrobione pod warnkiem ze dobry bit, dobrego bajtu sprawdzam,
trzeba jeszcze odkomentowac przy m_ReadoutType, bo chodzi
o to ze na razie dla bezpieczenstwa zostawilem ta czesc
GetDataRawIOCTL_DoubleSide zakomentowana
NOTE : kamera
jak ma wpiety kabel USB to chyba przestaje dzialac po Etherent - czy to
prawda, tak mi na to wyglada , ale moze to przypadek i
cos innego jest
nie tak ...
Nie to jednak nie to, problem polega na tym ze czasem sie nie pinguje (
watchdog jest wylaczony i nie ma resetu ) dopiero po ktoryms resecie
dziala ...
Czyli mogla miec dobry IP, tylko akurat nie trafialismy ...
8. Cooling turns off - in ethernet camera version
Srednio po 400 zdjeciach ( usually - to jest zmienne ) , wylacza sie
chlodzenie, czasem wczesniej , czasem pozniej , ale sie wylacza, dzieje
sie to w driverze ethernetowym i jest dosc dziwne.
Testy w heplx43:/opt/pi/dev/pisys/daq/ndir/results/20070618/k2a ,
natomiast w przypadku drivera USB2.0 nie ma tego problemu ! czyli cos
jest nie tak w eth !
W pliku cmd.txt widze :
22:3:16: CEthCamera::SendCmd() (number
field = 01070000):
To chyba oznacza wylaczenie chlodzenia , jeszcze to sprawdze ale raczej
na pewno tak !!! czyli z jakis powodow driver sam to zrobil !!!
Test z eth na ktorym sie wylaczylo chlodzenie :
heplx43:/opt/pi/dev/pisys/daq/ndir/results/20070618/k2a/ERROR_WZOR
W logu znalazlem :
13:47:16: CEthCamera::SendCmd()
(193.0.84.112:23100) number field = 00702800:
czy to nie robi czegos zlego - co to wlasciwie oznacza ?
Sprawdzic w kodzie lub zapytac Roberta - dac mu namiary na odpowiedni
plik
Robert mowi ze to jest ok , odpytanie o brakujace pakiety , ale to
chyba nie to, jak wylaczylem odpytywanie o brakujace pakiety to nadal
sie wylacza
W logach szukac
: "START LOGGING".
TESTY : prepdaq_single_eth.sh - - - 100.100.100.8
UWAGA : nie ma
wlaczonego watchdoga - trzeba czasem ja wylaczyc i wlaczyc i tak w
kolko az sie zaczne pingowac !
( heplx43 : cd $RESDIR/20070618/k2a/ ) :
- na USB chlodzenie sie nie wylacza ( ./doit_usb! - 1000 klatek po
USB )
- jak sie wlaczy chlodzenie i dziala tylko test2K2K to tez sie nie
wylacza ( doit_no_images! , ale trzeba tez wlaczyc test2K2K zeby sobie
byl wlaczony inaczej to zaden test )
- jak sie wylaczy ReadMissing to nadal sie wylacza ( czyli to nie
jest kwestia doczytywania pakietow )
Sa pewne wyniki, okazuje sie ze czasem w trakcie transmisji danych (
tylko i wylacznie po ethernecie ) kamera sie resetuje, po RS-232
i z kodem diagnostycznym udalo sie zauwazyc
ten reset, ale na razie nie wiadomo o co chodzi. Na pewno nie jest to
zadna mechanika ( kabel etc ) bo jakby byla, to mogloby sie to zdarzyc
w dowolnym momencie , a zdarza sie tylko
w trakcie transmisji !!!
To moze byc jakis bug w sofcie.
9. Re-connect
Wedlug Roberta jedyne miejsce gdzie robi reconnect to : Lost contact -
tak tgo jest w logach kamery
10. ReadMissing TEST
Robert mial watpliwosci czy procedura ReadMissing dziala poprawnie (
tzn czy odwraca pakiety ) , sprawdzilem to na symulatorze i na kamerze
, dodalem fukncje DeviceEth2K2K::GetDataInternal_TEST , ktora zawsze
czyta pakiety pojedycznczo, okazuje sie obrazki sa identyczne jak w
przypadku gdy caly obrazek jest wczytany w calosci.
Potem trzeba ta funkcje podmienic do testow w
DeviceEth2K2K::GetData i mozna sprawdzac
Test zrobilem w :
heplx43:/opt/pi/dev/pisys/daq/ndir/results/20070618/k2a/READ_ALL_AS_MISSING
heplx43:/opt/pi/dev/pisys/daq/ndir/results/20070618/k2a/READ_NORMAL
Zapiski :
zrobic test wedlug tego co RS napisal -
ReadMising na wszystkich
pakietach zrobic w test mode ! Zobaczyc
czy sie OK sciagaja !!!
- zrobic test RS : 12622 Jun 26 Robert
Sulej (3807) kamera
Wyglada na to ze ReadMissing jest jak najbardziej w porzadku !
11. Poprawki w driverze ( DeviceEth2K2K.cpp )
Zrobilem pewne poprawki, po nieudanej comendzie camera robi re-connect
, jesli on sie uda to wysyla komende ponownie i re-inicjalizuje
paramtery .
UWAGA : To
dziala , tyle ze Open zawsze zwraca TRUE , nawet jak kamera jest
wylaczona !!!
W tej sytuacji za oznake dobrego re-connecta uznalem ze SendCmd
zwrocilo >0
Trzeba logi
troche odchudzic i lepiej nimi sterowac.
Zrobilem tez drobne zmiany w CEthCamera.h(cpp) -> Log i LogErr na
public, date/time added in Log and LogErr
Na razie jest OK, ale temat resetowania sie kamery pewnie wroci kiedy
bedzie ich wiecej , oto zapiski, dochodzi jeszcze dorobienie jakiegos
mutex-a lub oddzielnych logow dla
CEthCamera i NudpSocket.cpp, oraz poziomow logowania
Zapiski :
- KAMERA - puscic testy na noc
/opt/pi/dev/pisys/daq/ndir/results/20070618/k2a/DARK
padla
na NudpSocket::Log - czyzby brak mutex-a ?
chyba jakas wielowatkowosc sie klania !!!
Cos sie chyba znow zrabalo !!! - resetuje sie ???
Cos sie stalo o 16:20 i zmienil sie prefix !!! :
-rw-r--r-- 1 msok STUDENTS 4038459 Jun 30 16:20
k2a_070630_00654_d.fitc
czasem sie resetuje i zmienia sie prefix !
Dodac w Open nazwe kamery przy re-connect ??? chyba wystarczy
jak to tam jest ???
Runy testu doit! ( 1000 klatek ) :
1/ nie bylo resetu
2/ byl reset, retrying sendcmd nie pomogl
3/ test na USB - 1000 klatek OK
4/ test na USB - 1000 klatek