Programming Interrupts in Raspberry Pi using a simple Kernel Character Device Driver

Introduction

Everyone, in Embedded Electronics domain today, must be familiar with a unique development board among us, called the Raspberry Pi, which is a credit-card-sized single-board computer developed in the UK by the Raspberry Pi Foundation.The Raspberry Pi has a Broadcom BCM2835 system on a chip (SoC),which includes an ARM1176JZF-S 700 MHz processor (The firmware includes a number of "Turbo" modes so that the user can attempt overclocking, up to 1 GHz, without affecting the warranty), VideoCore IV GPU and was originally shipped with 256 megabytes of RAM, later upgraded to 512 MB.It does not include a built-in hard disk or solid-state drive, but uses an SD card for booting and long-term storage. 

     "Raspberry Pi" Computer Model-B Rev1

The Setup

The Raspberry Pi,Model-B Rev 1, i am using is running on Debian flavor of Linux, called the "Wheezy"(Wonder, if it was having a running nose).To access, the signals on the Board, i have used the Expansion Pins exposed on the Board, as shown by the location on the Board of the major ICs, connectors and headers, respectively.

  Location on the PCB of connectors and major ICs

      

I am communicating with the Raspberry Pi using the serial console terminal via a USB2RS232 Adapter that one can easily get as a variety of adapters available in the Market. However, there was a problem that i had faced initially, since the UART Signals of Rx and Tx,(Pin nos. 10 and 8,exposed on the Top side Expansion Header, as shown in the fig.)of Expansion Header were of TTL 

Expansion Header Pins of Raspberry Pi

nature and hence required a conversion TTL Voltage levels to RS232.  

Upon, this end i tapped in the UART RxD and TxD to a TTL to RS232 converter circuit board, that i had assembled upon.

Now, this RS232 Output of the board could be fed via a USB2RS232 Adapter to my Laptop and i could communicate with a serial console terminal program like Putty, TeraTerm or Minicom, which i am using on my Ubuntu machine. And, Viola it worked !

Here, are below snaps of how i communicate with my Raspberry Pi, via Serial Console Terminal,or via the board shell on my Laptop.

The exposed Header signals of UART RxD, TxD,
+5V and Gnd fed to TTL to RS232 Converter Circuit which
is given to the RS232toUSB Adapter and the USB Adapter
plugged in to my Laptop.

So, this is all about the initial setup. To, begin with, the purpose of this small project is to show how a Simple Character Device Driver can be cross compiled for Raspberry Pi and inserted in the form of a Kernel Module with the installed Kernel. An Interrupt will also be requested and registered with the Kernel at the time of installing the Device Driver as a Kernel Module. Now, firstly, we would need a Kernel source, which must have the same version as that of the Kernel of my currently running Raspberry Pi.

Cross-Compiling the Linux Kernel

The Kernel version can be found by executing the command, uname -a. Now, the version of the Kernel shown as the output of the command #uname -a must match with the version of the Kernel source that we are trying to cross compile to and insert our module with. By looking into the 'Makefile' inside the Kernel Source directory, we can get that info, as shown below:

Kernel Makefile through which we can know kernel version, here for me the RPi was having a version 3.6.11, and the same can be found here.

So, we have our Kernel Source against which the module can be built against,as we will see shortly. Now, firstly, the Kernel has to be cross-compiled, since i am trying to compile it on my x86 machine, with Ubuntu installed, and the target is ARM Based, Raspberry Pi. 

• Get the tarball,fromGIT Hub, https://github.com/raspberrypi/linux/tree/rpi-3.6.y, and download it in the form of ZIP.
• Get the tools tarball.
• Extract the Toolchain and the Linux Source, #tar -xvzf rpi-3.6.y.tar.gz and #tar -xvzf master.tar.gz (tools). These tools are used as the cross compile toolchain.
• Set the environment variable CCPREFIX:                       export CCPREFIX= /home/rajiv/RPI/tools-master/arm-bcm2708-linux-gnueabi/bin/arm-bcm2708-linux-gnueabi-
• Set the environment variable KERNEL_SRC:                     export KERNEL_SRC= /home/rajiv/RPI/linux-rpi-3.6.y

GIT Hub from which Rpi Kernel versions can be downloaded from.

Exporting the Kernel and Cross Compile Toolchain variable

After this, now we begin the Kernel cross-compilation.

• First, clean the source:                                 #make ARCH=arm CROSS_COMPILE=${CCPREFIX} distclean
• Then set the correct config file for the Board, there are lots of config file that one can find inside '/arch/arm/configs/' folder.                             #make ARCH=arm CROSS_COMPILE=${CCPREFIX} RPI_defconfig
• Otherwise, place the following config file that i have attached in the form of .txt here(https://drive.google.com/file/d/0B6Cu_2GN5atpMzUxOXJCSmlzOEk/edit?usp=sharing), copy and place it inside '/arch/arm/configs' directory of the Linux Kernel Source.
• After, this start the compilation                        
• #make ARCH=arm CROSS_COMPILE=${CCPREFIX} 
• #make ARCH=arm CROSS_COMPILE=${CCPREFIX} modules_install
• #make ARCH=arm CROSS_COMPILE=${CCPREFIX} install
• Finally, the kernel image will be built in the following path, 'arch/arm/boot/' as 'zimage', rename it as 'kernel.img'.



Finally, built Linux Kernel Image, cross-compiled for ARM

After, this we begin writing the Character Device Driver, which can be built as a module to the above cross compiled RPI Kernel. One, of the first things is to assign a MAJOR and MINOR number to our Character Device Driver. One of the basic features of the Linux kernel is that it abstracts the handling of devices. All hardware devices look like regular files in Linux. 
Char devices are accessed through names in the filesystem. Those names are called special files or device files or simply nodes of the filesystem tree; they are conventionally located in the /dev directory. Special files for char drivers are identified by a "c" in the first column of the output of ls -l. Block devices appear in /dev as well, but they are identified by a "b.

If you issue the ls -l command, you'll see two numbers (separated by a comma) in the device file entries before the date of the last modification, where the file length normally appears. These numbers are the major and minor device number for the particular device. The following listing shows a few devices as they appear on a typical system. Their major numbers are 1, 4, 7, and 10, while the minors are 1, 3, 5, 64, 65, and 129.

 crw-rw-rw-    1 root     root       1,   3 Apr 11  2013 null
 crw-------    1 root     root      10,   1 Apr 11  2013 psaux
 crw-------    1 root     root       4,   1 Oct 28 03:04 tty1
 crw-rw-rw-    1 root     tty        4,  64 Apr 11  2013 ttys0
 crw-rw----    1 root     uucp       4,  65 Apr 11  2013 ttyS1
 crw--w----    1 vcsa     tty        7,   1 Apr 11  2013 vcs1
 crw--w----    1 vcsa     tty        7, 129 Apr 11  2013 vcsa1
 crw-rw-rw-    1 root     root       1,   5 Apr 11  2013 zero

A typical /proc/devices file looks like the following:
#cat /proc/devices
Character devices:
 1 mem
 2 pty
 3 ttyp
 4 ttyS
 6 lp
 7 vcs
 10 misc
 13 input
 14 sound
 21 sg
180 usb

Block devices:
 2 fd
 8 sd
 11 sr
 65 sd
 66 sd

We will use the following numbers as MAJOR and MINOR number for my character device driver:
#define MY_MAJOR 89
#define MY_MINOR 0

Next, we define the module author and module description for the same:

MODULE_LICENSE("GPL");
MODULE_AUTHOR("RBiswasx");
MODULE_DESCRIPTION("A Simple Character Device Driver module");

Next, we need to define the fops, file_operations structure. It defines what operations (e.g. 'open','read','write' in our example) are available for that kernel driver. The file_operations structure is defined in 'linux/fs.h', and holds pointers to functions defined by the driver that perform various operations on the device. Each, field of the structure corresponds to the address of some function defined by the driver to handle a requested operation.
struct file_operations my_fops = {
        read    :       my_read,
        write   :       my_write,
        open    :       my_open,
        release :       my_close,
owner   :       THIS_MODULE
        };
A pointer to a struct file_operations is commonly named 'fops'. Here, i have named it as 'my_fops'.

Followed,by the declaration of the function prototypes:
static int my_open(struct inode *, struct file *);
static ssize_t my_read(struct file *, char *, size_t, loff_t *);
static ssize_t my_write(struct file *, const char *, size_t, loff_t *);
static int my_close(struct inode *, struct file *);

As, discussed earlier, char devices are accessed through device files, usually located in '/dev'. The MAJOR number tells you which driver handles which device file. The MINOR number is used only by the driver itself to distinguish which device it's operating on, just in case the driver handles more than one device.

Initializing the Module: init_module()

Adding a driver to your system means registering it with the kernel. You can do this by using 'register_chrdev' function, defined in 'linux/fs.h'.

int register_chrdev (unsigned int major, const char* name, struct file_operations* fops);

In my code, i have used the following way to register my character device driver, using 'register_chrdev_region',it is something you should do to avoid conflict with other device drivers which may have played by the rules and been allocated the numbers you're trying to use.

        dev_t devno;
        devno = MKDEV(MY_MAJOR, MY_MINOR);
        register_chrdev_region(devno, 1, "mydevice");
        cdev_init(&my_cdev, &my_fops);

The variable 'my_cdev' is of type 'struct cdev'. 'struct cdev' is one of the elements of the inode structure. As you probably may know already, an inode structure is used by the kernel internally to represent files. The 'struct cdev' is the kernel's internal structure that represents char devices. So this field is a pointer to that structure while the inode refers to the char device file. Therefore if the kernel has to invoke the device it has to register a structure of this type.Hence, globally i declared it as:
        struct cdev my_cdev;

'init_module' of my character device driver

After, registering the character device driver using the above kernel functions,in the 'init_module()', i am trying to map the GPIO Base Address of Raspberry Pi using 'ioremap' function call. The purpose of doing this is, since GPIO Registers are Memory-Mapped in ARM Platform,and not I/O Mapped like in x86,hence to read, or use the GPIO Pins(as INPUT or OUTPUT) exposed on the Expansion Header of Raspberry Pi Board, we have to map these physical addresses using 'ioremap'. This 'GPIO_BASE', address i have defined in the header file 'RPI.h'.

#define BCM2708_PERI_BASE       0x20000000
#define GPIO_BASE              (BCM2708_PERI_BASE + 0x200000) // GPIO controller 

These addresses,i have found from the BroadCom BCM2835, the SOC present in Raspberry Pi, manual. BCM2835-ARM-Peripherals.pdf

In page no. 6 of the following manual, it says,

"Physical addresses range from 0x20000000 to 0x20FFFFFF for peripherals. The bus addresses for peripherals are set up to map onto the peripheral bus address range starting at 0x7E000000. Thus a peripheral advertised here at bus address 0x7Ennnnnn is available at physical address 0x20nnnnnn."

Physical Address range in BCM2835 Manual

So the BCM2708_PERI_BASE macro contains the physical address value at which the peripheral registers start. This is the address we will need to use in our program. The virtual address value is 0x7E000000, and it is these virtual addresses that will be found in the datasheet.

Now, in the same manual at page 90,the virtual address for GPIO Base is 0x7E200000. This means that the offset to the physical address will be 0x200000 which explains the GPIO_BASE.

GPIO Virtual Base Address of 0x7E200000 mapped to Physical Address 0x200000

Next,we define a struct of the type bcm2835_peripheral, which will contain the information about the location of the registers in our header file 'RPI.h'.

// IO Access
struct bcm2835_peripheral {
    unsigned long addr_p;
    int mem_fd;
    void *map;
    volatile unsigned int *addr;
};

struct bcm2835_peripheral gpio = {GPIO_BASE};

This struct variable, gpio is being used in 'init_module()'
gpio.map     = ioremap(GPIO_BASE, 4096);
gpio.addr    = (volatile unsigned int *)gpio.map;

Now,we will be able to use the memory-mapped 'gpio.addr' register to configure the GPIO Pins as Input or Output. For this i have used few macros in 'RPI.h' header file as follows:

// GPIO setup macros. Always use INP_GPIO(x) before using OUT_GPIO(x)

#define INP_GPIO(g) *(gpio.addr + ((g)/10)) &= ~(7<<(((g)%10)*3))

#define OUT_GPIO(g) *(gpio.addr + ((g)/10)) |=  (1<<(((g)%10)*3))

#define SET_GPIO_ALT(g,a) *(gpio.addr + (((g)/10))) |= (((a)<=3?(a) + 4:(a)==4?3:2)<<(((g)%10)*3)) 

#define GPIO_SET *(gpio.addr + 7) // sets bits which are 1 ignores bits which are 0

#define GPIO_CLR *(gpio.addr + 10)// clears bits which are 1 ignores bits which are 0 

#define GPIO_READ(g) *(gpio.addr + 13) &= (1<<(g))

On referring to BCM2835 Manual,page 90,we see that there are 5 register banks of 32-bit each, with each register bank mapped mapped to 10 GPIO Pins.

The 5 register banks of GPIO, with each bank mapped to 10 GPIO Pins

Hence, that accounts for using '*(gpio.addr + ((g)/10))' in the macros, since 'g/10'=1, accounts for a jump of 4-byte, to account for the 32-bit alignment of the registers. 
Now, consider the macro:

#define INP_GPIO(g) *(gpio.addr + ((g)/10)) &= ~(7<<(((g)%10)*3))

GPIO Function Select Register, Register Bank 0

There are three GPFSEL bits per pin (000: input, 001: output). The location of these three bits inside the GPFSEL register is given by ((g)%10)*3 (three times the remainder, remember the modulo % operator).
So to set pin "g" as an input, we need to set these bits to "000". This is done with a AND-operation between the GPSEL register and a string of which everything except those bits are 1. This string is created by bit shifting 7, which is binary 111, over ((g)%10)*3 places, and taking the inverse of that.

Hence, that was the explanation about how we are going to set any GPIO as INPUT/OUTPUT and READ/WRITE to it. In the 'init_module()', i have used Pin 4 and 24 as OUTPUT.

INP_GPIO(4); // Green LED

OUT_GPIO(4);

printk("*****GPIO 4 as GREEN Light ******************\n");

INP_GPIO(24);

   OUT_GPIO(24);

Next, in the 'init_module()',we do the most interesting part which is to request an interrupt from the Kernel and associate it with any GPIO Pin. This is done in the following function call:

r_int_config();

In,the following function,'r_int_config()'we are firstly requesting GPIO which if successful will allow us to use the GPIO Pin, if it is available and not being currently used for some other purpose. 


   if (gpio_request(GPIO_ANY_GPIO, GPIO_ANY_GPIO_DESC)) {
      printk("GPIO request failure: %s\n", GPIO_ANY_GPIO_DESC);
      return;
   }

where,GPIO_ANY_GPIO is defined as 17th GPIO Pin exposed on Expansion Header of Raspberry Pi, and GPIO_ANY_GPIO_DESC is defined as "MyInterrupt".

Next,we map this GPIO to any Interrupt using 'gpio_to_irq' function which will map this GPIO Pin to an interrupt number,as decided by the Kernel, based on the availability of the interrupt.

   if ( (irq_any_gpio = gpio_to_irq(GPIO_ANY_GPIO)) < 0 ) {

      printk("GPIO to IRQ mapping failure %s\n",   

      GPIO_ANY_GPIO_DESC);

      return;

   }

So,now we have an irq number, which is associated with the GPIO. The definition of this function, 'gpio_to_irq' can be found inside 'linux-rpi-3.6.y/arch/arm/mach-bcm2708/include/mach', since BCM2708 is the family to which the SOC of Raspberry Pi, BCM2835 belongs to:

'gpio_to_irq' function defined inside 'gpio.h' file

The function 'gpio_to_irq',returns 'GPIO_IRQ_START+gpio', now for BCM2708 platform,the value of 'GPIO_IRQ_START' is defined in 'irqs.h' file as:

#define GPIO_IRQ_START   (HARD_IRQS + FIQ_IRQS)

The following snapshot illustrates the relationship more appropriately:

After doing 'grep' command, we can figure out the value of 'GPIO_IRQ_START'

After,we map this GPIO to any Interrupt using 'gpio_to_irq' function,we request for an irq,using 'request_irq' function, as shown below:

   if (request_irq(irq_any_gpio,

                   (irq_handler_t ) r_irq_handler,

                   IRQF_TRIGGER_HIGH,

                   GPIO_ANY_GPIO_DESC,

                   GPIO_ANY_GPIO_DEVICE_DESC)) {

      printk("Irq Request failure\n");

      return;

   }

Here,'irq_any_gpio'is the interrupt number,'r_irq_handler'is the interrupt handler function pointer,'IRQF_TRIGGER_HIGH'is the kind of Interrupt Signal we are assigning this interrupt to,which in this case is a HIGH Level signal,as the Interrupt Signal from the Interrupt source.'GPIO_ANY_GPIO_DESC' is the interrupt name which i have given as "MyInterrupt", and 'GPIO_ANY_GPIO_DEVICE_DESC'is the device with which the Interrupt is associated with, which in this case is associated with my character device driver,"mydevice".

So, this was all about initializing the character device driver, in 'init_module'.

#insmod Hello.ko
#mknod /dev/mydevice c 89 0

Removing the Module: cleanup_module()

Next,we look into the 'cleanup_module'.Not much is done here,except unmapping the GPIO_BASE address space that we had mapped using 'ioremap' in 'init_module'.

if (gpio.addr){

        /* release the mapping */

        iounmap(gpio.addr);

}

Also,we unregister the character device driver,with major and minor numbers,MY_MAJOR and MY_MINOR.

dev_t devno;
devno = MKDEV(MY_MAJOR, MY_MINOR);

unregister_chrdev_region(devno, 1);

cdev_del(&my_cdev);

And,finally we release the interrupt also

r_int_release();

In the function, 'r_int_release()'we free the irq

   free_irq(irq_any_gpio, GPIO_ANY_GPIO_DEVICE_DESC);

   gpio_free(GPIO_ANY_GPIO);

Opening,Writing,Reading and Closing the Module: my_open(),my_write(),my_read() and my_close().

Next,we see the fops functions one by one,to begin with 'my_open(struct inode *inod, struct file *fil)'.Here, nothing much is done,except reading the Major and Minor Number of the character driver.Further,code can be added to increase the count of the Module,if more than one user space program is trying to access it.

int major;
                int minor;
                major = imajor(inod);
                minor = iminor(inod);

                printk("\n*****Some body is opening me at major %d  minor %d*****\n",major, minor);

Next,we see the fops function, 'my_write(struct file *filp, const char *buff, size_t len, loff_t *off)'.Here,we try and read a String from the user space,using 'copy_from_user'.

memset(msg, 0, 100);

count =copy_from_user(msg, buff, len);

The 'buff' is the character pointer to the string from the user space and 'len' is the string length,and this string is copied to the kernel space array,'msg'.


Next,we see the fops function, 'my_read(struct file *filp, char *buff, size_t len, loff_t *off)'.Here,we put the string that we had copied in 'msg' buffer,back to the user space using 'copy_to_user'.

                major = MAJOR(filp->f_dentry->d_inode->i_rdev);

count = copy_to_user(buff, msg, len);

                printk("*****Some body is reading me at major %d*****\n",major);

Next,we see the fops function, 'my_close(struct inode *inod, struct file *fil)'.Here, nothing much is done,except reading the Major and Minor Number of the character driver.Further,code can be added to decrease the count of the Module,if more than one user space program is trying to access it.

                int major;

                major = MAJOR(fil->f_dentry->d_inode->i_rdev);

                printk("*****Some body is closing me at major %d*****\n",major);

Inside the Interrupt Handler: r_irq_handler()

Now,lets look in the interrupt handler routine,'irqreturn_t r_irq_handler(int irq, void *dev_id, struct pt_regs *regs)'.Firstly,we limit the interrupt signal,which if say,was a kind of sudden spike or impulse in the signal,then the signal should be ignored and not be considered an interrupt.

   unsigned int interrupt_time = millis();

   if (interrupt_time - last_interrupt_time < 1000) 

   {

     printk(KERN_NOTICE "Ignored Interrupt!!!!! [%d]%s \n", irq, (char *) dev_id);

     return IRQ_HANDLED;

   }

   last_interrupt_time = interrupt_time;

After,this we save the status of the local interrupts(remember them in flag'flags').

   unsigned long flags;

   local_irq_save(flags);

After,this we check the status of the GPIO Pin 23,which we have set as INPUT,which gets a Timer signal from my interrupt source,after every 13 seconds,based on which GPIO Pin 4 will be SET or CLEARed.

   if (((val=GPIO_READ(23)) & 0xffffffff))

   printk(KERN_NOTICE "Interrupt [%d] for device %s was triggered !.\n", irq, (char *) dev_id);

   val =0;

   if (((val=GPIO_READ(23)) & 0xffffffff))

          GPIO_SET = 1 << 4;

   else

          GPIO_CLR = 1 << 4;

This GPIO Pin 4 is controlling the Green LED on the Bread Board.

Timer Signal coming from Interrupt source,left to GPIO Pin 23,based on which GPIO Pin 4 is SET in the Interrupt Handler.

Finally,in the interrupt handler,we restore the local interrupts and return.

   // restore hard interrupts
   local_irq_restore(flags);
   return IRQ_HANDLED;

Deferring work in the Interrupt Handler, using TASKLETS: r_irq_handler()

Interrupt Handlers run asynchronously and thus interrupt other potentially important code,including other interrupt handlers.Therefore,to avoid stalling the interrupted code for too long,interrupt handlers need to run as quickly as possible.

Since, Interrupt Handlers do not run in process context,therefore they cannot block.Due,to these requirements,we need a way to defer the more critical part of Interrupt Handler using a mechanism called Bottom Half Processing.

Top Half runs in Interrupt Context,while Bottom Half runs in Kernel Context

Tasklets are a bottom-half mechanism built on top of softirqs.As, already mentioned,they have nothing to do with tasks. Tasklets are similar in nature and work in a similar manner to softirqs; however,they have a simpler interface and relaxed locking rules.

Softirqs are required only for very high-frequency and highly threaded use.Because Tasklets are implemented on top of Softirqs, they are Softirqs. Unlike,Softirqs,two of the same Tasklets can never run concurrently on a Multi-Processor core system,although two different Tasklets can run at the same time on two different Processors,say one on ARM and another on X86 core. This is one major difference between Tasklets and SoftIRQs.

To implement TASKLETS,we will use the Kernel function,DECLARE_TASKLET which creates a TASKLET statically,we shall name our tasklet as 'mytasklet':

DECLARE_TASKLET(mytasklet, my_tasklet_handler, 0); 

where, 'my_tasklet_handler' is the function pointer to the Tasklet Handler.The function prototype of Tasklet Handler is declared in the beginning.

static int my_open(struct inode *, struct file *);
static ssize_t my_read(struct file *, char *, size_t, loff_t *);
static ssize_t my_write(struct file *, const char *, size_t, loff_t *);
static int my_close(struct inode *, struct file *);

static void my_tasklet_handler(unsigned long );

Now,in the Interrupt Handler,we just have to schedule the TASKLET to be run by the Kernel at some predefined time,using tasklet_schedule(&mytasklet). 
Here,is the Interrupt Handler code:

static irqreturn_t r_irq_handler(int irq, void *dev_id, struct pt_regs *regs) 
{  
   unsigned int interrupt_time = millis();
   if (interrupt_time - last_interrupt_time < 1000) 
        return IRQ_HANDLED;
   last_interrupt_time = interrupt_time;
   local_irq_save(flags);
   tasklet_schedule(&mytasklet);
   local_irq_restore(flags);

   return IRQ_HANDLED;
}

Inside the Tasklet Handler we do the main processing as was done earlier inside the Interrupt Handler.One most important thing to remember here is that,before we begin to do anything inside the Tasklet Handler,we first disable the Tasklet,using tasklet_disable(&mytasklet),which will ensure that while the Tasklet is in RUN State,it doesnt gets scheduled again.And,after the processing we enable the Tasklet before we return from the Tasklet Handler,using tasklet_enable(&mytasklet).Here,is how we do it:

DECLARE_TASKLET(mytasklet, my_tasklet_handler, 0);

static void my_tasklet_handler(unsigned long flag)
{
   tasklet_disable(&mytasklet);   
   if (((val=GPIO_READ(23)) & 0xffffffff))
   printk(KERN_NOTICE "Interrupt for device was triggered !.\n");
   val =0;
   if (((val=GPIO_READ(23)) & 0xffffffff))
          GPIO_SET = 1 << 4;
   else
          GPIO_CLR = 1 << 4;
   tasklet_enable(&mytasklet);   

}

I have uploaded the Module Code covering new implementation using TASKLETS in the Resources section of the Blog.One can download the same and verify it.

The Makefile: Makefile

The Makefile for the module is pretty simple,but important without which you won't be able to generate the '.ko',kernel object for the Module.

#make 

The Makefile looks as follows:

obj-m := Hello.o

all:

@$(MAKE) ARCH=arm CROSS_COMPILE=${CCPREFIX} -C /home/rajiv/RPI/linux-rpi-3.6.y M=$(PWD) modules

clean:

make ARCH=arm CROSS_COMPILE=${CCPREFIX} -C /home/rajiv/RPI/linux-rpi-3.6.y M=$(PWD) clean

In the User Space Program: Test.c

The User Space program to use this Character Device Driver is a simple Program which takes as an Input a User String and using 'write' system call passes this string to the Kernel Space.Using 'read' system call this string is read back again from the Kernel Space. 

User Space Program to access the Driver.

The,User Space Program is compiled on the Raspberry Pi,using 'gcc'.

#gcc -o Test Test.c

To,execute it:

./Test String_name

Resources: 

The entire Device Driver Project can be accessed and downloaded from here:

'Hello.c' Module Program,Bottom Half implementation in Interrupt Handler using TASKLETS:
https://drive.google.com/file/d/0B6Cu_2GN5atpcnNUTTVaVDNWVXM/edit?usp=sharing

'Hello.c' Module Program:
https://drive.google.com/file/d/0B6Cu_2GN5atpSWdEcU9nRE4wTzg/edit?usp=sharing

MakeFile:
https://drive.google.com/file/d/0B6Cu_2GN5atpZUdBcDVCaHlQV1U/edit?usp=sharing

Header File,'RPI.h':
https://drive.google.com/file/d/0B6Cu_2GN5atpakRkSXZZNFZJVzg/edit?usp=sharing

NOTE: I am editing this Section here... 

The Entire Kernel Sources that i had used is shared publicly and uploaded in the Google Drive. Below is the Link:

https://drive.google.com/file/d/0B2QVXoZzx8J2U2F0MGNjbUh4dmc/view?usp=sharing

Also the Cross-Compile Toolchain for building the Kernel Sources, that I had used can be downloaded from the below link:

https://github.com/raspberrypi/tools/archive/master.tar.gz


Furthermore,i have made and posted the Video of my Project on U-Tube,the link to which is as follows:

http://www.youtube.com/watch?v=TvDHnrfgr08