Formål
User Space drivers kan i nogle tilfælde være ganske nyttige. Kan arbejdet laves i User Space frem for Kernel Space, så bør det gøres der. User Space giver adgang til C++, Floating point, beskyttelse af hukommelse og meget mere. Tilgengæld er vi ikke garanteret nær den samme responstid som i kernen og vi kan heller ikke umiddelbart anvende interrupts. Til debugging af hardware kan det være nyttigt at skrive direkte fra user space til hardwaren og anvendes en fornuftig arkitektur, kan "mechanism" let flyttes til kernel space efterfølgende og "policy" beholdes i hardware.
Øvelsen
a) Userspace GPIO Driver på Target
mmap benyttes. For at anvende mmap på vores bootkey, skal størrelsen for en enkelt ”page” defineres. En page er 4k(4096UL).
For at tilgå GPIO, anvendes adresserne fundet vha. databladet spruf98c.pdf.
For at tilgå Bootkey og sysLed4, defineres en mask vha. bit/hex-konvertering, fx sættes BOOTKEY_OE bit 8 til 1 og resterende bits sættes til 0 og kenverteres til hex: 0b10000000 => 0x00000080
Userspace Driver kode
Programmeret kompileres:
arm-angstrom-linux-gnueabi-gcc -o user userspaceDriver.c
arm-angstrom-linux-gnueabi-gcc -o user userspaceDriver.c
Dermed fås en executeable fil, user, som overføres til Target.
Executeable filen køreres på Target:
/.user
Terminal output på Target:
b) Test ELDD program på Kubuntu
Dermed kan vi se at det lykkedes at mappe adresserne.
b) Test ELDD program på Kubuntu
Userprogrammet er hentet vha. checkout svn og kompileret til linux vha. gcc -o
Testapplikation:
gcc -o test
user_space_rtc_driver_test.c
Der oprettes tre forskellige testprogrammer med tre
forskellige ”scheduling policy”:
SCHED_OTHER, SCHED_ FIFO,
SCHED_ RR
Ved ovenstående scheduleringstest fås følgende
resultater(testet 6 gange for hver type):


No comments:
Post a Comment