Saturday 27 July 2013

Embedded C Programming Interview Questions and answers

1. Advantages of a macro over a function?

Macro gets to see the Compilation environment.
It is expanded by the preprocessor.
For example, you can't do this without macros:
#define PRINT(EXPR) printf( #EXPR "=%d\n", EXPR)
PRINT( 5+6*7 ) // expands into printf("5+6*7=%d", 5+6*7 );
You can define your mini language with macros:
#define strequal(A,B) (!strcmp(A,B))
Macros are a necessary evils of life. The purists don't like them, but without it no real work gets done.
============================================================================
2. Difference between const char* p and char const* p

In const char* p, the character pointed by 'p' is constant, so you cant change the value of character pointed by p but you can make 'p' refer to some other location.
in char const* p, the ptr 'p' is constant not the character referenced by it, so you cant make 'p' to reference to any other location but you can change the value of the char pointed by 'p'.

============================================================================

3. Can a variable be both const and volatile?

Yes. The const modifier means that this code cannot change the value of the variable, but that does not mean that the value cannot be changed by means outside this code. If a variable is both const and
volatile, the two modifiers can appear in either order.

=============================================================================
4. How are pointer variables initialized?

Pointer variable are initialized by one of the following two ways
- Static memory allocation
- Dynamic memory allocation

============================================================================

5. When should a type cast not be used?
A type cast should not be used to override a const or volatile declaration. Overriding these type modifiers can cause the program to fail to run correctly.
A type cast should not be used to turn a pointer to one type of structure or data type into another. In the rare events in which this action is beneficial, using a union to hold the values makes the programmer's intentions clearer.

ALERT: IAS 2014 DATES ANNOUNCED by UPSC

Posted: 25 Jul 2013 06:06 AM PDT

ALERT: IAS 2014 DATES ANNOUNCED by UPSC

Today UPSC has announced dates for IAS PRE (CSAT) Exam 2014. it is tentative date but its almost 3 months later than previous exam dates.


Date of Notification: 17 May 2014

Last Date to Apply: 16 June 2014

Date of IAS PRE (CSAT) Exam: 24 AUGUST 2014

Tuesday 23 July 2013

LEDs to test the use of the parallel port



LEDs to test the use of the parallel port:-



In this section I’ll detail the construction of a piece of hardware that can be used to visualize the state of the parallel port with some simple LEDs.
WARNING: Connecting devices to the parallel port can harm your computer. Make sure that you are properly earthed and your computer is turned off when connecting the device. Any problems that arise due to undertaking these experiments is your sole responsibility.
The circuit to build is shown in figure 3 You can also read “PC & Electronics: Connecting Your PC to the Outside World” by Zoller as reference.
In order to use it, you must first ensure that all hardware is correctly connected. Next, switch off the PC and connect the device to the parallel port. The PC can then be turned on and all device drivers related to the parallel port should be removed (for example, lp, parport, parport_pc, etc.). The hotplug module of the Debian Sarge distribution is particularly annoying and should be removed. If the file /dev/parlelport does not exist, it must be created as root with the command:
# mknod /dev/parlelport c 61 0
Then it needs to be made readable and writable by anybody with:
# chmod 666 /dev/parlelport
The module can now be installed, parlelport. You can check that it is effectively reserving the input/output port addresses 0x378 with the command:
$ cat /proc/ioports
To turn on the LEDs and check that the system is working, execute the command:
$ echo -n A >/dev/parlelport
This should turn on LED zero and six, leaving all of the others off.
You can check the state of the parallel port issuing the command:
$ cat /dev/parlelport
Figure 3: Electronic diagram of the LED matrix to monitor the parallel portFigure 3: Electronic diagram of the LED matrix to monitor the parallel port
Final application: flashing lights
Finally, I’ll develop a pretty application which will make the LEDs flash in succession. To achieve this, a program in user space needs to be written with which only one bit at a time will be written to the /dev/parlelport device.
<lights.c> =
#include <stdio.h>
#include <unistd.h></p>

int main() {
  unsigned char byte,dummy;
  FILE * PARLELPORT;
                  
  /* Opening the device parlelport */
  PARLELPORT=fopen("/dev/parlelport","w");
  /* We remove the buffer from the file i/o */
  setvbuf(PARLELPORT,&dummy,_IONBF,1);

  /* Initializing the variable to one */
  byte=1;

  /* We make an infinite loop */
  while (1) {
    /* Writing to the parallel port */
    /* to turn on a LED */
    printf("Byte value is %d\n",byte);
    fwrite(&byte,1,1,PARLELPORT);
    sleep(1);

    /* Updating the byte value */
    byte<<=1;
    if (byte == 0) byte = 1;
  }

  fclose(PARLELPORT);

}
It can be compiled in the usual way:
$ gcc -o lights lights.c
and can be executed with the command:
$ lights
The lights will flash successively one after the other! The flashing LEDs and the Linux computer running this program are shown in figure 4.
Conclusion
Having followed this brief tutorial you should now be capable of writing your own complete device driver for simple hardware like a relay board (see Appendix C), or a minimal device driver for complex hardware. Learning to understand some of these simple concepts behind the Linux kernel allows you, in a quick and easy way, to get up to speed with respect to writing device drivers. And, this will bring you another step closer to becoming a true Linux kernel developer.
Figure 4: Flashing LEDs mounted on the circuit board and the computer running Linux. Two terminals are shown: one where the “parlelport” module is loaded and another one where the “lights” program is run. Tux is closely following what is going onFigure 4: Flashing LEDs mounted on the circuit board and the computer running Linux. Two terminals are shown: one where the “parlelport” module is loaded and another one where the “lights” program is run. Tux is closely following what is going on
Bibliography
A. Rubini, J. Corbert. 2001. Linux device drivers (second edition). Ed. O’Reilly. This book is available for free on the internet.
Jonathan Corbet. 2003/2004. Porting device drivers to the 2.6 kernel. This is a very valuable resource for porting drivers to the new 2.6 Linux kernel and also for learning about Linux device drivers.
B. Zoller. 1998. PC & Electronics: Connecting Your PC to the Outside World (Productivity Series). Nowadays it is probably easier to surf the web for hardware projects like this one.
M. Waite, S. Prata. 1990. C Programming. Any other good book on C programming would suffice.

The real “parlelport” driver



The real “parlelport” driver: description of the parallel port
I’ll now proceed by modifying the driver that I just created to develop one that does a real task on a real device. I’ll use the simple and ubiquitous computer parallel port and the driver will be called parlelport.
The parallel port is effectively a device that allows the input and output of digital information. More specifically it has a female D-25 connector with twenty-five pins. Internally, from the point of view of the CPU, it uses three bytes of memory. In a PC, the base address (the one from the first byte of the device) is usually 0x378. In this basic example, I’ll use just the first byte, which consists entirely of digital outputs.
The connection of the above-mentioned byte with the external connector pins is shown in figure 2.
Figure 2: The first byte of the parallel port and its pin connections with the external female D-25 connectorFigure 2: The first byte of the parallel port and its pin connections with the external female D-25 connector
The “parlelport” driver: initializing the module
The previous memory_init function needs modification—changing the RAM memory allocation for the reservation of the memory address of the parallel port (0x378). To achieve this, use the function for checking the availability of a memory region (check_region), and the function to reserve the memory region for this device (request_region). Both have as arguments the base address of the memory region and its length. The request_region function also accepts a string which defines the module.
<parlelport modified init module> =
  /* Registering port */
  port = check_region(0x378, 1);
  if (port) {
    printk("<1>parlelport: cannot reserve 0x378\n");
    result = port;
    goto fail;
  }
  request_region(0x378, 1, "parlelport");
The “parlelport” driver: removing the module
It will be very similar to the memory module but substituting the freeing of memory with the removal of the reserved memory of the parallel port. This is done by the release_region function, which has the same arguments as check_region.
<parlelport modified exit module> =
  /* Make port free! */
  if (!port) {
    release_region(0x378,1);
  }
The “parlelport” driver: reading the device
In this case, a real device reading action needs to be added to allow the transfer of this information to user space. The inb function achieves this; its arguments are the address of the parallel port and it returns the content of the port.
<parlelport inport> =
/* Reading port */
parlelport_buffer = inb(0x378);
Table 9 (the equivalent of Table 2) shows this new function.


Events
Kernel functions
Read data
inb
Write data

Device driver events and their associated functions between kernel space and the hardware device.
The “parlelport” driver: writing to the device
Again, you have to add the “writing to the device” function to be able to transfer later this data to user space. The function outb accomplishes this; it takes as arguments the content to write in the port and its address.
<parlelport outport> =
/* Writing to the port */
outb(parlelport_buffer,0x378);
Table 10 summarizes this new function.


Events
Kernel functions
Read data
inb
Write data
outb
Device driver events and their associated functions between kernel space and the hardware device.
The complete “parlelport” driver
I’ll proceed by looking at the whole code of the parlelport module. You have to replace the word memory for the word parlelport throughout the code for the memory module. The final result is shown below:
<parlelport.c> =
<parlelport initial>
<parlelport init module>
<parlelport exit module>
<parlelport open>
<parlelport release>
<parlelport read>
<parlelport write>
Initial section
In the initial section of the driver a different major number is used (61). Also, the global variable memory_buffer is changed to port and two more #include lines are added: ioport.h and io.h.
<parlelport initial> =
/* Necessary includes for drivers */
#include <linux/init.h>
#include <linux/config.h>
#include <linux/module.h>
#include <linux/kernel.h> /* printk() */
#include <linux/slab.h> /* kmalloc() */
#include <linux/fs.h> /* everything... */
#include <linux/errno.h> /* error codes */
#include <linux/types.h> /* size_t */
#include <linux/proc_fs.h>
#include <linux/fcntl.h> /* O_ACCMODE */
#include <linux/ioport.h>
#include <asm/system.h> /* cli(), *_flags */
#include <asm/uaccess.h> /* copy_from/to_user */
#include <asm/io.h> /* inb, outb */

MODULE_LICENSE("Dual BSD/GPL");

/* Function declaration of parlelport.c */
int parlelport_open(struct inode *inode, struct file *filp);
int parlelport_release(struct inode *inode, struct file *filp);
ssize_t parlelport_read(struct file *filp, char *buf,
                       size_t count, loff_t *f_pos);
ssize_t parlelport_write(struct file *filp, char *buf,
                       size_t count, loff_t *f_pos);
void parlelport_exit(void);
int parlelport_init(void);

/* Structure that declares the common */
/* file access fcuntions */
struct file_operations parlelport_fops = {
  read: parlelport_read,
  write: parlelport_write,
  open: parlelport_open,
  release: parlelport_release
};

/* Driver global variables */
/* Major number */
int parlelport_major = 61;

/* Control variable for memory */
/* reservation of the parallel port*/
int port;

module_init(parlelport_init);
module_exit(parlelport_exit);
Module init
In this module-initializing-routine I’ll introduce the memory reserve of the parallel port as was described before.
<parlelport init module> =
int parlelport_init(void) {
  int result;

  /* Registering device */
  result = register_chrdev(parlelport_major, "parlelport",
      &parlelport_fops);
  if (result < 0) {
    printk(
      "<1>parlelport: cannot obtain major number %d\n",
      parlelport_major);
    return result;
  }
  
  <parlelport modified init module>

  printk("<1>Inserting parlelport module\n");
  return 0;

  fail:
    parlelport_exit();
    return result;
}
Removing the module
This routine will include the modifications previously mentioned.
<parlelport exit module> =
void parlelport_exit(void) {

  /* Make major number free! */
  unregister_chrdev(parlelport_major, "parlelport");

  <parlelport modified exit module>

  printk("<1>Removing parlelport module\n");
}
Opening the device as a file
This routine is identical to the memory driver.
<parlelport open> =
int parlelport_open(struct inode *inode, struct file *filp) {

  /* Success */
  return 0;

}
Closing the device as a file
Again, the match is perfect.
<parlelport release> =
int parlelport_release(struct inode *inode, struct file *filp) {

  /* Success */
  return 0;
}
Reading the device
The reading function is similar to the memory one with the corresponding modifications to read from the port of a device.
<parlelport read> =
ssize_t parlelport_read(struct file *filp, char *buf,
  size_t count, loff_t *f_pos) {

  /* Buffer to read the device */
  char parlelport_buffer;

  <parlelport inport>

  /* We transfer data to user space */
  copy_to_user(buf,&parlelport_buffer,1);
 
  /* We change the reading position as best suits */
  if (*f_pos == 0) {
    *f_pos+=1;
    return 1;
  } else {
    return 0;
  }
}
Writing to the device
It is analogous to the memory one except for writing to a device.
<parlelport write> =
ssize_t parlelport_write( struct file *filp, char *buf,
  size_t count, loff_t *f_pos) {

  char *tmp;

  /* Buffer writing to the device */
  char parlelport_buffer;

  tmp=buf+count-1;
  copy_from_user(&parlelport_buffer,tmp,1);

  <parlelport outport>
 
  return 1; 
}