RCS file: file_operation.h,v
Working file: file_operation.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
File contains application operations mapping to driver operations
—————————-
revision 1.1 locked by: root;
date: 2014/11/19 10:03:05; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: declaration.h,v
Working file: declaration.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
File contains function declaration and variable declaration
—————————-
revision 1.1 locked by: root;
date: 2014/11/19 10:03:05; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: driver.c,v
Working file: driver.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
File contains driver init module
—————————-
revision 1.2 locked by: root;
date: 2014/11/19 10:08:27; author: root; state: Exp; lines: +1 -1
Check region at 0×378

if not free, release region
Request for region
—————————-
revision 1.1
date: 2014/11/19 10:03:05; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: devopen.c,v
Working file: devopen.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
File contains implementation of container_of
—————————-
revision 1.1 locked by: root;
date: 2014/11/19 10:03:05; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: devwrite.c,v
Working file: devwrite.c
head: 1.5
branch:
locks: strict
root: 1.5
access list:
symbolic names:
keyword substitution: kv
total revisions: 5; selected revisions: 5
description:
File conatains implementation of copy_from_user
user sent data which is copied to SCULL
—————————-
revision 1.5 locked by: root;
date: 2014/11/19 10:23:13; author: root; state: Exp; lines: +1 -1
Sent strobe that data is valid
—————————-
revision 1.4
date: 2014/11/19 10:17:14; author: root; state: Exp; lines: +1 -1
check if reader is free, by receiving Acknowlegement
—————————-
revision 1.3
date: 2014/11/19 10:15:30; author: root; state: Exp; lines: +1 -1
sent character to data register
—————————-
revision 1.2
date: 2014/11/19 10:14:13; author: root; state: Exp; lines: +1 -1
Initialy set control register 0×00
—————————-
revision 1.1
date: 2014/11/19 10:03:05; author: root; state: Exp;
Initial revision
=============================================================================
RCS file: devread.c,v
Working file: devread.c
head: 1.8
branch:
locks: strict
root: 1.8
access list:
symbolic names:
keyword substitution: kv
total revisions: 8; selected revisions: 8
description:
File read the data from register and copy to user application
—————————-
revision 1.8 locked by: root;
date: 2014/11/19 11:04:15; author: root; state: Exp; lines: +1 -1
Copy to user application
—————————-
revision 1.7
date: 2014/11/19 11:02:37; author: root; state: Exp; lines: +1 -1
Receieve character from data register
—————————-
revision 1.6
date: 2014/11/19 11:00:46; author: root; state: Exp; lines: +2 -2
Reset strobe to 0
Set 5 bit high for bidirectional in control register
—————————-
revision 1.5
date: 2014/11/19 10:59:32; author: root; state: Exp; lines: +1 -1
Check for Acknowledgement that the coming data is valid
—————————-
revision 1.4
date: 2014/11/19 10:58:01; author: root; state: Exp; lines: +1 -1
After 5 sec sent strobe, receiver is free
—————————-
revision 1.3
date: 2014/11/19 10:56:37; author: root; state: Exp; lines: +1 -1
reader sleep for 5 seconds
—————————-
revision 1.2
date: 2014/11/19 10:55:26; author: root; state: Exp; lines: +1 -1
Sent strobe that the receiver is busy in control register
—————————-
revision 1.1
date: 2014/11/19 10:53:45; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: removedriver.c,v
Working file: removedriver.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
File contains exit module
—————————-
revision 1.2 locked by: root;
date: 2014/11/19 10:25:09; author: root; state: Exp; lines: +1 -0
Release region when driver is removed
—————————-
revision 1.1
date: 2014/11/19 10:05:00; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: declaration.h,v
Working file: declaration.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
This file contains all the functions declaration
—————————-
revision 1.1 locked by: root;
date: 2014/11/12 12:08:53; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: file_operation.h,v
Working file: file_operation.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
This file contains operation mapping.
—————————-
revision 1.1 locked by: root;
date: 2014/11/12 12:08:53; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: driver.c,v
Working file: driver.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 1
description:
This file contains allocation of region in memory
Add device with major and minor
—————————-
revision 1.2 locked by: root;
date: 2014/11/12 12:11:23; author: root; state: Exp; lines: +1 -0
Check for parallel port region
if occupied, release region
then, request for region
=============================================================================

RCS file: devopen.c,v
Working file: devopen.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
use container of
—————————-
revision 1.1 locked by: root;
date: 2014/11/12 12:08:53; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: devwrite.c,v
Working file: devwrite.c
head: 1.3
branch:
locks: strict
root: 1.3
access list:
symbolic names:
keyword substitution: kv
total revisions: 3; selected revisions: 3
description:
This file allocates memory for quantum & qset in scull
data sent from write application is stored in quantum
—————————-
revision 1.3 locked by: root;
date: 2014/11/12 12:43:56; author: root; state: Exp; lines: +1 -1
For second nibble shift the character by 4
same steps are followed for second nibble
—————————-
revision 1.2
date: 2014/11/12 12:38:50; author: root; state: Exp; lines: +1 -1
set 0×00 at control register
& character from quantum with 0x0f, for first nibble
sent first nibble
checking status of reader, if free or not
if received strobe from reader, that the reader is free now
sent the strobe that data is valid
—————————-
revision 1.1
date: 2014/11/12 12:38:06; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: devread.c,v
Working file: devread.c
head: 1.3
branch:
locks: strict
root: 1.3
access list:
symbolic names:
keyword substitution: kv
total revisions: 3; selected revisions: 3
description:
This file read the character from port, and copy to the user application
—————————-
revision 1.3 locked by: root;
date: 2014/11/12 13:12:17; author: root; state: Exp; lines: +1 -1
Shift the second nibble received by 3
Shift the received charcter by 4 to make it msb
|(or) with previous stored chracter in first nibble.
—————————-
revision 1.2
date: 2014/11/12 13:02:10; author: root; state: Exp; lines: +1 -1
First make the reader busy, then after 5 sec free the reader
sent the strobe signal that the reader is free
wait for acknowlegement the data going to be received is valid or not
when receives the strobe, from writer that the data is valid
set the control register 32 for bidirectional
receives the first nibble and & with 0×78
shift the receive nibble by 3, & with 0x0f
store the character in other variable
—————————-
revision 1.1
date: 2014/11/12 13:00:27; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: devrelease.c,v
Working file: devrelease.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
This file free the allocated memory for device
—————————-
revision 1.1 locked by: root;
date: 2014/11/12 12:08:53; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: removedriver.c,v
Working file: removedriver.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
unregister allocated region
—————————-
revision 1.2 locked by: root;
date: 2014/11/12 12:12:56; author: root; state: Exp; lines: +1 -0
File contains release region when driver is removed
—————————-
revision 1.1
date: 2014/11/12 12:08:53; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: dec.h,v
Working file: dec.h
head: 1.1
branch:
locks: strict
emblogic: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
—————————-
revision 1.1    locked by: emblogic;
date: 2014/11/11 05:30:45;  author: emblogic;  state: Exp;
Initial revision
=============================================================================

RCS file: initialization.c,v
Working file: initialization.c
head: 1.2
branch:
locks: strict
emblogic: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 1
description:
implemented the check_region(), release_region() for checking the availability of region
—————————-
revision 1.2    locked by: emblogic;
date: 2014/11/11 05:33:43;  author: emblogic;  state: Exp;  lines: +2 -2
implemented the  request_region()
=============================================================================

RCS file: fileop.h,v
Working file: fileop.h
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 0
description:
=============================================================================

RCS file: dev_open.c,v
Working file: dev_open.c
head: 1.1
branch:
locks: strict
emblogic: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
—————————-
revision 1.1    locked by: emblogic;
date: 2014/11/11 05:32:50;  author: emblogic;  state: Exp;
Initial revision
=============================================================================

RCS file: dev_write.c,v
Working file: dev_write.c
head: 1.3
branch:
locks: strict
emblogic: 1.3
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;    selected revisions: 1
description:
—————————-
revision 1.3    locked by: emblogic;
date: 2014/11/11 05:40:03;  author: emblogic;  state: Exp;  lines: +1 -0
followed the protocols : send the strobe.
to allow the reader to read the data,before send the strobe to reader,this verified  the busy status.. ============================================================================

RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.2
branch:
locks: strict
emblogic: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 1
description:
—————————-
revision 1.2    locked by: emblogic;
date: 2014/11/11 05:35:23;  author: emblogic;  state: Exp;  lines: +2 -0
implemented release_region foe releasing the region ,
=============================================================================

RCS file: dev_read.c,v
Working file: dev_read.c
head: 1.2
branch:
locks: strict
emblogic: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 1
description:
following the protocols first send the busy to writer.and wait for strobe signal from writer.
—————————-
revision 1.2    locked by: emblogic;
date: 2014/11/11 05:57:34;  author: emblogic;  state: Exp;  lines: +2 -2
after receiving the strobe from the writter received the data sucessfully.
=============================================================================

RCS file: declaration.h,v
Working file: declaration.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
—————————-
revision 1.1 locked by: root;
date: 2014/11/10 04:16:20; author: root; state: Exp;
Initial revision

RCS file: initilization.c,v
Working file: initilization.c
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
—————————-
revision 1.2
date: 2014/11/10 04:19:20; author: root; state: Exp; lines: +2 -1
Implemented check_region(), request_region() and release_region()
—————————-
revision 1.1
date: 2014/11/10 04:16:41; author: root; state: Exp;
Initial revision

RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
—————————-
revision 1.1 locked by: root;
date: 2014/11/10 04:16:59; author: root; state: Exp;
Initial revision

RCS file: dev_open.c,v
Working file: dev_open.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
—————————-
revision 1.1 locked by: root;
date: 2014/11/10 04:17:21; author: root; state: Exp;
Initial revision

RCS file: dev_release.c,v
Working file: dev_release.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
Implemented release_region().
—————————-
revision 1.1 locked by: root;
date: 2014/11/10 04:20:45; author: root; state: Exp;
Initial revision

RCS file: dev_write.c,v
Working file: dev_write.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
Ckeck busy signal by sending the strobe. After that sent data on data lines.
—————————-
revision 1.1 locked by: root;
date: 2014/11/10 04:21:02; author: root; state: Exp;
Initial revision

RCS file: dev_read.c,v
Working file: dev_read.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
Read data from data lines.
—————————-
revision 1.1 locked by: root;
date: 2014/11/10 04:21:19; author: root; state: Exp;
Initial revision

RCS file: file_op.h,v
Working file: file_op.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
—————————-
revision 1.1 locked by: root;
date: 2014/11/10 04:21:33; author: root; state: Exp;
Initial revision

Write synopsis:
outb(ch,0×378);
while(busy_status !=0×80)
busy_status = inb(0×379);

Read synopsis:
while(strobe != 0×00)
strobe = inb(0×379);
data = inb(0×378);

1. Host signals ability to take data by making the Busy pin low.

2. Now peripheral or writer responds by placing First nibble. Writer Writes on Data line, on the other side Reader reads from Status line.

3. Before reading from Reader side Peripheral or writer signals valid nibble by Sending signal on one of the status line.

4. The Reader indicate to writer that it has received the lower nibble. And is is not ready to accept another nibble. This is done by sending signal on status line to indicate the writer.

5. Now repeate all these steps for second nibble…

RCS file: header.h,v
Working file: header.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
implemented linux/ioport.h and asm/io.h
—————————-
revision 1.1    locked by: root;
date: 2014/11/03 08:52:22;  author: root;  state: Exp;
Initial revision

RCS file: declaration.h,v
Working file: declaration.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
—————————-
revision 1.1    locked by: root;
date: 2014/11/03 08:52:22;  author: root;  state: Exp;
Initial revision

RCS file: initilization.c,v
Working file: initilization.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
Implemented check_region(), request_region() and release_region()
—————————-
revision 1.1    locked by: root;
date: 2014/11/03 08:52:22;  author: root;  state: Exp;
Initial revision

RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
Implemented release_region
—————————-
revision 1.1    locked by: root;
date: 2014/11/03 08:52:22;  author: root;  state: Exp;
Initial revision

RCS file: dev_open.c,v
Working file: dev_open.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
—————————-
revision 1.1    locked by: root;
date: 2014/11/03 08:52:22;  author: root;  state: Exp;
Initial revision

RCS file: dev_release.c,v
Working file: dev_release.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
—————————-
revision 1.1    locked by: root;
date: 2014/11/03 08:52:22;  author: root;  state: Exp;
Initial revision

RCS file: dev_write.c,v
Working file: dev_write.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
Written LSB nibble and MSB nibble. Taken character from application and calaulated LSB and MSB
—————————-
revision 1.1    locked by: root;
date: 2014/11/03 08:52:22;  author: root;  state: Exp;
Initial revision

RCS file: dev_read.c,v
Working file: dev_read.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
Read the Nibbles and arranged to calculate the original character
—————————-
revision 1.1    locked by: root;
date: 2014/11/03 08:52:22;  author: root;  state: Exp;
Initial revision

RCS file: file_op.h,v
Working file: file_op.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
Performed different file operations
—————————-
revision 1.1    locked by: root;
date: 2014/11/03 08:52:22;  author: root;  state: Exp;
Initial revision

Write synopsis:

ch2 = ch1 & 0x0f;

ch3 = ch1 & 0xf0;
ch3 = ch3 >> 4;

Read synopsis:

ch1 = ch1 << 1;
ch1 = ch1 >> 4;
ch1 = ch1 & 0x0f;

ch2 = ch2 << 1;
ch2 = ch2 & 0xf0;

Enjoy Implementing……

Following are the RCS files and code snippet of the project :

1. intialization module :
RCS file: ./initialization.c,v
Working file: initialization.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
IEEE Std. 1284-1994
Standard Signalling method for a Bi-directional parallel peripheral Interface for personal computer.
IC : 74LS244
Mode : Nibble Mode
Module Info : initialization
This module is responsible for :
- creating scull for the device.
- allocating required address for the driver to work.
- add driver to kernel tree.
—————————-
revision 1.2 locked by: root;
date: 2014/11/03 06:38:42; author: root; state: Exp; lines: +0 -8
Successfully allocated memory to the device scull.
requested and acquired the required address space i.e. 0×0378 – 0x037a
0×0378 for data lines.
0×0379 for status lines.
0x037a for control lines.
—————————-
Code Snippet :
tatic int __init initialization_function(void){
/* the name of the driver which you want your driver to be visible */
const char *name = “character_device_latest”;
int ret, i;
printk(KERN_ALERT”%s : Begin”, __func__);

/* checking and acquiring region for parallel port*/
ret = check_region(START, RANGE);
if(ret >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2. write module :
RCS file: ./dev_write.c,v
Working file: dev_write.c
head: 1.3
branch:
locks: strict
root: 1.3
access list:
symbolic names:
keyword substitution: kv
total revisions: 3; selected revisions: 3
description:
Module : the module implements the protocol for sending a byte of data in two nibbles.
The module implements the protocol in the following manner :
1. reset the data and control lines.
2. write data to data lines.
3. check the busy status of the device by polling.
4. if device is free send strobe signal.
5. wait for acknowledgement corresponding the first nibble.
6. repeat steps 2-6 for sending the second nibble.
—————————-
revision 1.3 locked by: root;
date: 2014/11/03 07:15:13; author: root; state: Exp; lines: +0 -7
the writer performs the following operations successfully following the protocol for nibble mode.
1. read data to be sent from user application.
2. write first nibble to data lines.
3. get acknowledgement for first nibble and then send the second nibble
4. wait for acknowledgement of second nibble.
—————————-
Code Snippet :
int protocol(const char __user* buffer){
unsigned char temp;
volatile unsigned char busy;
volatile unsigned char ack;
struct nibble n;

/* remove garbage content from the control and data lines */
outb(0×0000, CTRL_REG);
outb(0×0000, DATA_REG);

/* prepare the first nibble to be sent */
temp = buffer[0];
printk(KERN_INFO”data to be sent to the reader = %d\n”, temp);
n.val = temp;
printk(KERN_INFO”nibble 1 to be sent to the reader = %d\n”, n.val);
outb(n.val, DATA_REG);
/* check the busy status of the device */
do{
busy = inb(STATUS_REG);
busy = busy & 0×0080;
}while(busy!=0×0080);
printk(“Device free\n”);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
3. read module :
RCS file: ./dev_read.c,v
Working file: dev_read.c
head: 1.3
branch:
locks: strict
root: 1.3
access list:
symbolic names:
keyword substitution: kv
total revisions: 3; selected revisions: 3
description:
this module implements the protocol for receiving the data on the reader side.
protocol implemented for Nibble mode.
—————————-
revision 1.3 locked by: root;
date: 2014/11/03 07:12:53; author: root; state: Exp; lines: +1 -0
the reader correctly reads a byte of data as sent by the writer.
—————————-
revision 1.2
date: 2014/11/03 07:09:30; author: root; state: Exp; lines: +14 -14
corrected the error in reading the value from the status register.
——————————
Code Snippet :
ssize_t dev_read(struct file *filep, char __user *ubuff, size_t size, loff_t *loff)
{
volatile unsigned char strobe;
unsigned char data;
unsigned char temp;
printk(KERN_INFO”BEGIN %s\n”, __func__);

/* reset the data and control lines and update the busy status to free. */
outb(0×0000, CTRL_REG);
outb(0×0001, CTRL_REG);
outb(0×0000, DATA_REG);

/* wait on strobe value = 1, first nibble */
do{
strobe = inb(STATUS_REG);
strobe = strobe & 0×0080;
}while(strobe!=0×0080);
printk(KERN_INFO”Got strobe signal from the writer = %d\n”, strobe);

outb(0×0000, CTRL_REG); // make device appear busy to reader

// read the first nibble
temp = inb(STATUS_REG);
printk(KERN_INFO” inb, temp = %d\n”, temp);
temp = temp & 0×0078;
temp = temp >>3;
printk(KERN_INFO”temp after masking= %d\n”, temp);
printk(KERN_INFO”Data received (nibble – 1)= %d\n”, temp);

RCS file: ./initialization.c,v
Working file: initialization.c
head: 1.4
branch:
locks: strict
root: 1.4
access list:
symbolic names:
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
Initialization file for Centronics port driver based on IEEE-1284 standard.
—————————-
revision 1.4 locked by: root;
date: 2014/11/01 04:44:07; author: root; state: Exp; lines: +0 -4
Successfully implemented the following operations :
1. Acquire the address 0×0378 – 0x037a for the device.
2. Create the device scull.
3. Initialise the cdev structure..
4. Add the device to the kernel tree.
—————————-
revision 1.3
date: 2014/10/31 15:19:12; author: root; state: Exp; lines: +0 -40
Successfully created the scull for the device.
—————————-
revision 1.2
date: 2014/10/31 15:16:36; author: root; state: Exp; lines: +1 -0
Released the region acquired by the default parallel port driver.
Acquired the same space for own driver.
Entry successfully created in /proc/ioports.
—————————-
revision 1.1
date: 2014/10/31 15:16:07; author: root; state: Exp;
Initial revision
=============================================================================

2. cleanup module for device :

RCS file: ./cleanup.c,v
Working file: cleanup.c
head: 1.4
branch:
locks: strict
root: 1.4
access list:
symbolic names:
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
Cleanup module for deriver
—————————-
revision 1.4 locked by: root;
date: 2014/11/01 04:59:28; author: root; state: Exp; lines: +0 -1
The module successfully performs the following functions :
1. Unregister the driver.
2. Release the address space acquired i.e. 0×378 – 0x37a
—————————-
revision 1.3
date: 2014/11/01 04:57:56; author: root; state: Exp; lines: +0 -1
Able to release the acquired range successfully.
The driver releases the 0×0378-0x037a address space on rmmod.
Entry removed from the /proc/ioports file.
—————————-
revision 1.2
date: 2014/11/01 04:56:34; author: root; state: Exp; lines: +0 -2
Successfully unregistered the driver on rmmod.
—————————-
revision 1.1
date: 2014/11/01 04:56:15; author: root; state: Exp;
Initial revision
=============================================================================

3. write module :

RCS file: ./dev_write.c,v
Working file: dev_write.c
head: 1.5
branch:
locks: strict
root: 1.5
access list:
symbolic names:
keyword substitution: kv
total revisions: 5; selected revisions: 5
description:
dev_write.c : runs when user space application writes the node.
module implements the protocol under Compatability mode.
—————————-
revision 1.5 locked by: root;
date: 2014/10/31 16:56:12; author: root; state: Exp; lines: +0 -1
The writer is able to perform the following :
1. Take the data from the user application.
2. Write the data to the port.
3. Check busy status of the device at the other end of the cable.
4. Send strobe.
—————————-
revision 1.4
date: 2014/10/31 16:53:29; author: root; state: Exp; lines: +1 -0
Implemented the protocol in 3 steps.
wddl : write data to data lines.
cbs : check busy status of the device, keep pollng until the device is found free.
sss : once the device is found free send the strobe signal to indicate that the data on data lines is valid content.
—————————-
revision 1.3
date: 2014/10/31 15:33:36; author: root; state: Exp; lines: +0 -59
Able to send a single byte of data.
Protocol successfully implemented.
Acknowledgement from device has not been used.
Some problem with the hardware.
—————————-
revision 1.2
date: 2014/10/31 15:32:12; author: root; state: Exp; lines: +2 -0
able to send the data successfully without any protocol.
—————————-
revision 1.1
date: 2014/10/31 15:31:39; author: root; state: Exp;
Initial revision
=============================================================================

4. read module :

RCS file: ./dev_read.c,v
Working file: dev_read.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
dev_read : module runs when an application tries to read from the node.
Implements compatability mode for data transfer between two systems.
—————————-
revision 1.2 locked by: root;
date: 2014/10/31 16:44:09; author: root; state: Exp; lines: +1 -0
Successfully implemented the protocol.
The device sends the busy status.
Waits for strobe.
Once strobe arrives, reads data.
Sends the data to the user application by copy_to_user.
—————————-
revision 1.1
date: 2014/10/31 16:42:58; author: root; state: Exp;
Initial revision
=============================================================================

using coomand ==lspci on the terminal will give ou list of all chipset for audio card , usb ,serial, parallel ,vga …….etc

PORT NAME     Interrupt #     Starting I/O   Ending I/O LPT1           IRQ 7          0×378           0x37f LPT2           IRQ 5           0×278           0x27f

• In this exercise we use LPT1 with IRQ 7 and the following three bytes:
  1. 0×378 : data port
  2. 0×379 : status port
  3. 0x37A : control port
• The parallel port standard states that setting bit C4 of the control port (0x37A) enables interrupt reporting.

The pins of the 25 pin female D type parallel port connector are shown in the following picture

• In this picture all green pins (numbered 18 – 25) are grounded at 0 Volt.
• When having interrupts enabled (i.e., bit C4 has been set), an interrupt will be generated by the parallel port when the voltage on input line S6 (pin 10) is raised from 0 Volt to +5 Volt. By default the input line is kept high to +5 Volt when nothing is connected. Observe that when pin 10 is shortly shorted to one of the pins 19-25, i.e., to ground, an interrupt on IRQ line 7 will be generated by the parallel port. The interrupt is generated at exactly the moment that you undo the shortage, since at that exact moment the line is raised from 0 to +5 Volt.

I had firstly make a sculldev allocate memory to it so that i can map the file_operations through the
cdev_init and cdev_add operations and then map the parallel port address to the user address,then map the write operation to the driver and i had made a application for sending the data byte from the application through the node to the driver and received by the scull_write function in the map space then get the data from the application to the __user *buffer and then copy_from_user to get the data from application and then save it in the unsigned char buffer and then outb the data to the parallel port and continuously sending the data from the application and sending the data continuously to the port and the binary representation of the characters are shown on the led’s.

Memory-Mapped I/O:- Memory-mapped I/O (not to be confused with memory-mapped file I/O) uses the same address bus to address both memory and I/O devices – the memory and registers of the I/O devices are mapped to (associated with) address values. So when an address is accessed by the CPU, it may refer to a portion of physical RAM, but it can also refer to memory of the I/O device. Thus, the CPU instructions used to access the memory can also be used for accessing devices. Each I/O device monitors the CPU’s address bus and responds to any CPU access of an address assigned to that device, connecting the data bus to the desired device’s hardware register. To accommodate the I/O devices, areas of the addresses used by the CPU must be reserved for I/O and must not be available for normal physical memory. The reservation might be temporary—the Commodore 64 could bank switch between its I/O devices and regular memory—or permanent.

Port-Mapped I/O:- Port-mapped I/O often uses a special class of CPU instructions specifically for performing I/O. This is found on Intel microprocessors, with the IN and OUT instructions. These instructions can read and write one to four bytes (outb, outw, outl) to an I/O device. I/O devices have a separate address space from general memory, either accomplished by an extra “I/O” pin on the CPU’s physical interface, or an entire bus dedicated to I/O. Because the address space for I/O is isolated from that for main memory, this is sometimes referred to as isolated I/O.

A parallel port is a type of interface found on computers (personal and otherwise) for connecting peripherals. In computing, a parallel port is a parallel communication physical interface. It is also known as a printer port or Centronics port. It was a de facto industry standard for many years, and was finally standardized as IEEE 1284 in the late 1990s, which defined a bi-directional version of the port. Today, the parallel port interface is seeing decreasing use because of the rise of Universal Serial Bus (USB) and FireWire (IEEE 1394) devices, along with network printing using Ethernet.

The parallel port interface was originally known as the Parallel Printer Adapter on IBM PC-compatible computers. It was primarily designed to operate a line printer that used IBM’s 8-bit extended ASCII character set to print text, but could also be used to adapt other peripherals. Graphical printers, along with a host of other devices, have been designed to communicate with the system.

IBM released the IBM Personal Computer in 1981 and included a variant of the Centronics interface— only IBM logo printers (rebranded from Epson) could be used with the IBM PC.IBM standardized the parallel cable with a DB25F connector on the PC side and the Centronics connector on the printer side. Vendors soon released printers compatible with both standard Centronics and the IBM implementation.

The original IBM parallel printer adapter for the IBM PC was designed to support 8-bit data bidirectionally in 1981. This feature was removed in later revisions of the hardware, so that the data lines could only be used to output data. Years later in 1987, IBM reintroduced the bidirectional interface with its IBM PS/2 series, where it could be enabled or disabled for compatibility with applications hardwired not to expect a printer port to be bidirectional. HP introduced their version of bidirectional, known as Bitronics, on the LaserJet 4 in 1992. The Bitronics and Centronics interfaces were superseded by the IEEE 1284 standard in 1994.

A wide variety of devices were eventually designed to operate on a parallel port. Most devices were uni-directional (one-way) devices, only meant to respond to information sent from the PC. However, some devices such as Zip drives were able to operate in bi-directional mode. Printers also eventually took up the bi-directional system, allowing various status report information to be sent.

Interfaces

Most PC-compatible systems in the 1980s and 1990s had one to three ports, with communication interfaces defined like this:

• Logical parallel port 1: I/O port 0x3BC, IRQ 7 (usually in monochrome graphics adapters)

• Logical parallel port 2: I/O port 0×378, IRQ 7 (dedicated IO cards or using a controller built into the mainboard)

• Logical parallel port 3: I/O port 0×278, IRQ 5 (dedicated IO cards or using a controller built into the mainboard)

If no printer port is present at 0x3BC, the second port in the row (0×378) becomes logical parallel port 1 and 0×278 becomes logical parallel port 2 for the BIOS. Sometimes, printer ports are jumpered to share an interrupt despite having their own IO addresses (i.e. only one can be used interrupt-driven at a time). In some cases, the BIOS supports a fourth printer port as well, but the base address for it differs significantly between vendors. Since the reserved entry for a fourth logical printer port in the BIOS Data Area (BDA) is shared with other uses on PS/2 machines and with S3 compatible graphics cards, it typically requires special drivers in most environments. Under DR-DOS 7.02 the BIOS port assignments can be changed and overridden using the LPT1, LPT2, LPT3 (and optionally LPT4) CONFIG.SYS directives.

Access

DOS-based system will make the logical parallel ports detected by the BIOS available under device names such as LPT1, LPT2 or LPT3 (corresponding with logical parallel port 1, 2, and 3, respectively). These names derive from terms like Line Print Terminal, Local Print Terminal, or Line PrinTer. A similar naming convention was used on ITS, DEC systems, as well as in CP/M and 86-DOS (LST).

In DOS, the parallel printers could be accessed directly on the command line. For example, the command “TYPE C:\AUTOEXEC.BAT > LPT1” would redirect the contents of the AUTOEXEC.BAT file to the printer port. A PRN device was also available as an alias for LPT1. Some operating systems (like Multiuser DOS) allow to change this fixed assignment by different means. Some DOS versions use resident driver extensions provided by MODE, or the mapping can be changed internally via a CONFIG.SYS PRN=n directive (as under DR-DOS 7.02 and higher). DR-DOS 7.02 also provides optional built-in support for LPT4 if the underlying BIOS supports it.

PRN, along with CON, AUX and a few others are invalid file and directory names in DOS and Windows, even Windows XP. There is even an MS-DOS device in path name vulnerability in Windows 95 and 98, which causes the computer to crash if the user types “C:\CON\CON”, “C:\PRN\PRN” or “C:\AUX\AUX” in the Windows Explorer address bar. A patch to fix this bug has been released by Microsoft, but newly installed Windows 95 and 98 operating systems will still have the bug.

A special “PRINT” command also existed to achieve the same effect. Microsoft Windows still refers to the ports in this manner in many cases, though this is often fairly hidden.In the Linux operating system the first LPT port is available via the filesystem as /dev/lp0.

Program interface

In versions of Windows that did not use the Windows NT kernel (as well as DOS and some other operating systems), programs could access the parallel port with simple outportb() and inportb() subroutine commands. In operating systems such as Windows NT and Unix (NetBSD, FreeBSD, Solaris, 386BSD, etc.), the microprocessor is operated in a different security ring, and access to the parallel port is inhibited, unless using the required driver. This improves security and arbitration of device contention. On Linux, inb() and outb() can be used when a process is run as root and an ioperm() command is used to allow access to its base address; alternatively, ppdev allows shared access and can be used from userspace if the appropriate permissions are set.

The cross-platform library for parallel port access, libieee1284, also is available on many Linux distributions and provides an abstract interface to the parallel ports of the system. Access is handled in an open-claim-release-close sequence, which allows for concurrent access in userspace.

Current use

For consumers, the USB interface — and sometimes Ethernet — has replaced the parallel printer port, for connections both to printers and to other devices.

Many manufacturers of personal computers and laptops consider parallel to be a legacy port and no longer include the parallel interface. Smaller machines have less room for large parallel port connectors. The guidelines for Microsoft’s Windows Logo Program “strongly discourages” systems builders from including parallel ports.USB-to-parallel adapters are available that can make parallel-only printers work with USB-only systems. There are PCI (and PCI-express) cards that provide parallel ports. There are also some print servers that provide interface to parallel port through network. USB-to-EPP chips can also allow other non-printer device to continue to work on modern computers without a parallel port.

For electronics hobbyists the parallel port is still often the easiest way to connect to an external circuit board. It is faster than the other common legacy port (serial port) and requires no serial-to-parallel converter, and requires far less interface logic and software than a USB target interface. However, Microsoft operating systems later than Windows 95/98 prevent user programs from directly writing to or reading from the PrinterPort. Current CNC Milling Machines also often make use of the parallel port to directly control the machine’s motors and attachments.

A parallel interface for connecting an external device. Parallel port is basically used to transfer data parallely . 8 bits of data is transmitted at a time in parallel port.On PCs, the parallel port uses a 25-pin connector (type DB-25) and is used to connect printers, computers and other devices that need relatively high bandwidth. It is often called a Centronics interface after the company that designed the original standard for parallel communication between a computer and printer. (The modern parallel interface is based on a design by Epson.) A newer type of parallel port, which supports the same connectors as the Centronics interface, is the EPP (Enhanced Parallel Port) or ECP (Extended Capabilities Port). Both of these parallel ports support bi-directional communication and transfer rates ten times as fast as the Centronics port.

There are 5 modes of transferring data using parallel port :-

1- compatibility mode or centronic  mode
2- nibble mode
3-byte mode

4-ECP mode
5- EPP mode

compatibility mode :- The Centronics interface is a standard input/output (I/O) interface designed in the 1970s for connecting printers and other devices. It was developed by the Centronics printer company which is now defunct. The Centronics interface, also known as a Parallel Port, became the standard means of connecting printers to personal computers for decades.

The technology that the Centronics interface developed into included a number of incarnations of the Parallel interface including the ECP (Entended Capabilities Parallel) and EPP (Enhanced Parallel Port) versions. The technology required a 25 way connector of which up to 17 wires were used in the specification and bi-directional communications became possible in the enhanced versions like ECP and EPP.

Today, the Centronics interface has been largely replaced by the universal serial bus (USB). For the most part, many manufactures have entirely omitted the parallel interface. However, a USB-to-parallel port adapter is available for PCs without a parallel port. These can be used for parallel printers and other peripheral devices that have a parallel interface.

Nibble mode :-The Nibble mode is the most common way to get reverse channel data from a printer or peripheral. This mode is usually combined with the Compatibility mode or a proprietary forward channel mode to create a complete bi-directional channel.
All of the standard parallel ports provide 5 lines from the peripheral to the PC to be used for external status indications. Using these lines, a peripheral can send a byte of data (8-bits) by sending 2 nibbles (4-bits) of information to the PC in two data transfer cycles. Unfortunately, since the nACK line is generally used to provide a peripheral interrupt, the bits used to transfer a nibble are not conveniently packed into the byte defined by the Status register. For this reason, the software must read the status byte and then manipulate the bits in order to get a correct byte.

1. Host signals ability to take data by asserting HostBusy low
2. Peripheral responds by placing first nibble on status lines
3. Peripheral signals valid nibble by asserting PtrClk low
4. Host sets HostBusy high to indicate that it has received the nibble and is not yet ready for another nibble.
5. Peripheral sets PtrClk high to acknowledge host
6. States 1 through 5 repeat for the second nibble.

Parallel port is the mostly used for interfacing line printers. It was introduced by IBM in early 1980′s. Earlier there was no standard defined for parallel port interfacing. Every company has their own standards for interfacing parallel port. Then came the IEEE 1284 standard (Standard Signaling Method for bi-directional parallel peripheral interface for personal computers).

There are three base addresses defined for parallel port which can be used for interfacing parallel port. Those addresses are

0×378-0x37A

0×278-0x27A

0x3BC-0x3BF

A parallel port is a 25 pin connector having 8 data pins, 5 status pins and 4 control pins and rest of the pins are connected to ground.

2 – 9 = 8 Data Pins

10,11,12,13,15 = Status Pins

1, 14, 16,17 = Control Pins

18 – 25 = Ground Pins

This port will allow the input of up to 9 bits or the output of 12 bits at any one given time.

There are 5 data transfer mode in parallel communication:

1. Compatibility Mode: Data can be transferred only in one direction using data register.

2. Nibble mode: Data can be transferred in both direction in half-duplex manner (only four bit at a time).

3. Byte Mode: 8bit data can be transferred in both direction in half-duplex manner.

4. EPP Mode.

5. ECP Mode.

Compatibility, Nibble & Byte modes use just the standard hardware available on the original Parallel Port cards while EPP & ECP modes require additional hardware which can run at faster speeds, while still being compatible with the Standard Parallel Port.

Compatibility Mode:

This mode defines the protocol used by most PCs to transfer data to a printer. It is commonly called the Centronics mode and is the method utilized with the standard parallel port. In this mode, data is placed on the port’s data lines, the printer status is checked for that it is not Busy, and then a data Strobe is generated by the software to send the data to the printer

Compatibility Mode steps:

1. Write the data to the data register

2. Program reads the status register to check that the printer is not BUSY

3. If not BUSY, then Write to the Control Register to assert the STROBE line

4. Write to the Control register to de-assert the STROBE line

To transfer one byte of data it requires four operation and at least as many additional instructions. The data transfer rate in this protocol is 150K bytes per second. This mode is for the forward channel only. This mode was included as a way to provide backward compatibility with the huge base of installed printers and peripherals. The other modes are used to provide the reverse channel and high performance communication links. Many of the integrated 1284 I/O controllers have implemented a mode that uses a FIFO buffer to transfer data with the Compatibility mode protocol. This mode is referred to as Fast Centronics or Parallel Port FIFO Mode. When this mode is enabled, data written to the FIFO port will be transferred to the printer using hardware generated strobes for the handshaking.