linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: RTC !!
@ 2001-04-12 12:33 Remko van der Vossen
  0 siblings, 0 replies; 7+ messages in thread
From: Remko van der Vossen @ 2001-04-12 12:33 UTC (permalink / raw)
  To: 'linux-kernel@vger.kernel.org'

Hi Guys,

Niraj wrote:
> The RTC interrupt  is programmable from 2 Hz to 8192 Hz, in 
> powers of 2. So the interrupts that you could get are one
> of the following:      0.122ms, .244ms, .488ms, .977ms,
> 1.953ms, 3.906ms, 7.813ms, and so on.    Is there any  
> workaround , so that i can use RTC for meeting my
> requirement of an interrupt every 1.666..ms!!  
> ( I know that i can use UTIME or #define HZ 600, but i want
> to know if i can use RTC for this purpose )

It's pretty simple actually, the finest granularity of the 
RTC interrupt is 0.122 ms, so if you want to use a 600 Hz 
timer you'd just have to see if that fits...
1.666/0.122 = 13.656 so it doesn't fit, the best you can do 
is 1000/(0.122*14) = 585.48 Hz you could implement this 
pretty simple, just make a counter, and increment this 
counter every time you receive an interrupt, afther 
incrementing the counter you simply check to see if it is 14, 
if so reset it to 0 and call the real interrupt handler... 
That's the best you can do with a granularity of 0.122 ms, as 
simple as that...
Ofcourse this timer would operate at an increasing time 
difference if you really need a 600Hz timer so it wouldn't be 
much good...
The thing you could do is use a timer operating at a 
frequency of half the allowed tolerance, ie in you case that 
would be a timer of max 0.4ms (half the frequency is twice 
the period) so we'd have to use the 0.244 timer here. Now 
every time you get this interrupt you request the actual time 
from the RTC and if this time is withing half the duration of 
your period (0.122 ms in this case) from your targetted time 
then you call the actual interrupt... You could optimize this 
just a bit by adding a counter so you don't have to call on 
the RTC at every interrupt, I think it'd be a bit to costly...

So, after this whole probably terribly confusing story I 
think I'll give a scenario...

here's how it should go:

inttime expect  diff     action
t0.000  t0.000  t 0.000  ==> interrupt call
t0.244  t1.666  t-1.422
t0.488  t1.666  t-1.178
t0.732  t1.666  t-0.934
t0.976  t1.666  t-0.690
t1.220  t1.666  t-0.446
t1.464  t1.666  t-0.202
t1.708  t1.666  t 0.042  ==> interrupt call
t1.952  t3.333  t-1.381
t2.196  t3.333  t-1.137
t2.440  t3.333  t-0.893
t2.684  t3.333  t-0.649
t2.928  t3.333  t-0.405
t3.172  t3.333  t-0.161
t3.416  t3.333  t 0.083  ==> interrupt call
t3.660  t5.000  t-1.340
t3.904  t5.000  t-1.096
t4.148  t5.000  t-0.852
t4.392  t5.000  t-0.608
t4.636  t5.000  t-0.364
t4.880  t5.000  t-0.120  ==> interrupt call
t5.124  t6.666  t-1.542

you can see that the difference at the point of interrupt 
trigger slightly increases every interrupt, at a certain 
point this difference will be more than 0.122 ms and then the 
interrupt before that one will be actually triggering the 
interrupt as that one is then closer to the targetted 
interrupt time, this way you are ensured that the maximum 
difference between interrupt trigger time and actual time is 
no more than 0.122 ms. The drawback in a straigtforward 
implementation of this is that the RTC is accessed every time 
an interrupt occurs, this can be optimized by adding a timer. 
I'll demonstrate in the following (pseudo) code:


assumptions:
  -gettime returns the current time in microseconds
  -there are bound te be errors in this code as I wrote it off
   the top of my head

typedef void (*tcb)( void );  //Timer callback function prototype

int32 ttime; //targetted time  (microseconds)
int32 tfreq; //timer freq      (microseconds)
int32 ttol;  //timer tolerance (microseconds)
int32 httf;  //half timer tick frequency (microseconds)
int32 mtick; //minimum RTC ticks to next timer event
int32 etick; //elapsed RTC ticks since last timer event
tcb   tmrcb; //Timer callback function

void rtcinthandler( void ) {
  //increase etick and check if a possible timer event should
  //be investigated
  if (++etick > mtick) {
    int32 ctime = gettime();
    //check for a timer event
    if ((ctime - ttime + httf) < (httf * 2)) {
      //We've got a winner, reinit variable and call
      //callback handler
      etick = 0;
      //We recalculate ttime to prevent increasing rounding errors
      ttime = (ctime * tfreq / 1000000 + 1) * 1000000 / tfreq;
      tmrcb();
    }
  }
}

void inittimer(tcb acallback, int32 atfreq, int32 attol) {
  int32 tempval;
  int32 prevttime; //previous targetted time
  int32 ctime = gettime(); //current time

  /*todo: disable the timer if it was already running*/
  tfreq = atfreq;
  ttol = attol;
  tmrcb = acallback;
  //this is probably a very difficult way to calculate the
  //ttf, but at the moment I can't come up with anything
  //better
  httf = 0;
  tempval = ttol / 112
  while (tempval / 2)
    httf++;
  //calculate the targetted time of the next tick..
  //the next statements may seem weird but if we require
  //the integer rounding to get the right times...
  prevttime = ctime * tfreq / 1000000 * 1000000 / tfreq;
  ttime = (ctime * tfreq / 1000000 + 1) * 1000000 / tfreq;
  //calculate the elapsed ticks since last ttime
  etick = (ctime - prevttime + httf) / (httf * 2);
  /*todo: start the actual timer*/
}

Bye,

Remko van der Vossen
CMG Eindhoven
Remko.van.der.Vossen@cmg.nl

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RTC !
@ 2001-04-21 10:49 npunmia
  0 siblings, 0 replies; 7+ messages in thread
From: npunmia @ 2001-04-21 10:49 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3487 bytes --]



Can someone help me with this !!!

With Regards,
--Niraj



Niraj Punmia
04/21/2001 03:42 PM

To:   Jesper Juhl <juhl@eisenstein.dk>
cc:

Subject:  Re: RTC !  (Document link not converted)

The version of gcc , i am using is also egcs-2.91.66 !! How come i am getting
this problem???



Jesper Juhl <juhl@eisenstein.dk> on 04/20/2001 07:34:47 PM

To:   Niraj Punmia/HSS@HSS
cc:

Subject:  Re: RTC !




npunmia@hss.hns.com wrote:

> I am using Linux 2.2.18 with KURT patch installed! I don't know which gcc/
egcs
> i am using ? How do we check it?

gcc --version

/Jesper Juhl




---------------------- Forwarded by Niraj Punmia/HSS on 04/21/2001 04:10 PM
---------------------------


Niraj Punmia
04/20/2001 05:29 PM

To:   Jesper Juhl <juhl@eisenstein.dk>
cc:

Subject:  Re: RTC !  (Document link not converted)

I am using Linux 2.2.18 with KURT patch installed! I don't know which gcc/ egcs
i am using ? How do we check it?

--Regards,
--Niraj



Jesper Juhl <juhl@eisenstein.dk> on 04/20/2001 06:08:57 PM

To:   Niraj Punmia/HSS@HSS
cc:   linux-kernel@vger.kernel.org

Subject:  Re: RTC !




npunmia@hss.hns.com wrote:

> Hi,
>
> When i compiled the following program , (taken from
> /usr/src/linux/Documentation/rtc.txt )
>
> (See attached file: rtc2.c)
>
> it gave me the following error:
>
> [root@msatuts1 timer1]#  gcc -s -Wall -Wstrict-prototypes rtc2.c -o rtc2
> In file included from rtc2.c:17:
> /usr/include/linux/mc146818rtc.h:29: parse error before `rtc_lock'
> /usr/include/linux/mc146818rtc.h:29: warning: data definition has no type or
> storage class
> rtc2.c:25: warning: return type of `main' is not `int'
> [root@msatuts1 timer1]#
>
>  Is this a bug?Can anyone tell me how to remove this parse error ?

It works fine for me using a 2.2.16 kernel and egcs-2.91.66 (see below)...


bash-2.04$ gcc -s -Wall -Wstrict-prototypes rtc2.c -o rtc2
rtc2.c:24: warning: return type of `main' is not `int'
bash-2.04$ ./rtc2

                        RTC Driver Test Example.

Counting 5 update (1/sec) interrupts from reading /dev/rtc: 1 2 3 4 5
Again, from using select(2) on /dev/rtc: 1 2 3 4 5

Current RTC date/time is 20-4-2001, 12:34:01.
Alarm time now set to 12:34:06.
Waiting 5 seconds for alarm... okay. Alarm rang.

Periodic IRQ rate was 1024Hz.
Counting 20 interrupts at:
2Hz:     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
4Hz:     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
8Hz:     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
16Hz:    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
32Hz:    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
64Hz:    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

                         *** Test complete ***

Typing "cat /proc/interrupts" will show 131 more events on IRQ 8.

bash-2.04$


Regards,
Jesper Juhl
juhl@eisenstein.dk



To:   linux-kernel@vger.kernel.org
cc:

Subject:  RTC !


Hi,

When i compiled the following program , (taken from
/usr/src/linux/Documentation/rtc.txt )


(See attached file: rtc2.c)

it gave me the following error:

[root@msatuts1 timer1]#  gcc -s -Wall -Wstrict-prototypes rtc2.c -o rtc2
In file included from rtc2.c:17:
/usr/include/linux/mc146818rtc.h:29: parse error before `rtc_lock'
/usr/include/linux/mc146818rtc.h:29: warning: data definition has no type or
storage class
rtc2.c:25: warning: return type of `main' is not `int'
[root@msatuts1 timer1]#

 Is this a bug?Can anyone tell me how to remove this parse error ?

With Regards,
--Niraj





[-- Attachment #2: rtc2.c --]
[-- Type: application/octet-stream, Size: 4752 bytes --]


/*
 *	Real Time Clock Driver Test/Example Program
 *
 *	Compile with:
 *		gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest
 *
 *	Copyright (C) 1996, Paul Gortmaker.
 *
 *	Released under the GNU General Public License, version 2,
 *	included herein by reference.
 *
 */

#include <stdio.h>
#include <linux/mc146818rtc.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>

void main(void) {

int i, fd, retval, irqcount = 0;
unsigned long tmp, data;
struct rtc_time rtc_tm;

fd = open ("/dev/rtc", O_RDONLY);

if (fd ==  -1) {
	perror("/dev/rtc");
	exit(errno);
}

fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");

/* Turn on update interrupts (one per second) */
retval = ioctl(fd, RTC_UIE_ON, 0);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading /dev/rtc:");
fflush(stderr);
for (i=1; i<6; i++) {
	/* This read will block */
	retval = read(fd, &data, sizeof(unsigned long));
	if (retval == -1) {
		perror("read");
		exit(errno);
	}
	fprintf(stderr, " %d",i);
	fflush(stderr);
	irqcount++;
}

fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
fflush(stderr);
for (i=1; i<6; i++) {
	struct timeval tv = {5, 0};	/* 5 second timeout on select */
	fd_set readfds;

	FD_ZERO(&readfds);
	FD_SET(fd, &readfds);
	/* The select will wait until an RTC interrupt happens. */
	retval = select(fd+1, &readfds, NULL, NULL, &tv);
	if (retval == -1) {
		perror("select");
		exit(errno);
	}
	/* This read won't block unlike the select-less case above. */
	retval = read(fd, &data, sizeof(unsigned long));
	if (retval == -1) {
		perror("read");
		exit(errno);
	}
	fprintf(stderr, " %d",i);
	fflush(stderr);
	irqcount++;
}

/* Turn off update interrupts */
retval = ioctl(fd, RTC_UIE_OFF, 0);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

/* Read the RTC time/date */
retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
	rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900,
	rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);

/* Set the alarm to 5 sec in the future, and check for rollover */
rtc_tm.tm_sec += 5;
if (rtc_tm.tm_sec >= 60) {
	rtc_tm.tm_sec %= 60;
	rtc_tm.tm_min++;
}
if  (rtc_tm.tm_min == 60) {
	rtc_tm.tm_min = 0;
	rtc_tm.tm_hour++;
}
if  (rtc_tm.tm_hour == 24)
	rtc_tm.tm_hour = 0;

retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

/* Read the current alarm settings */
retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n",
	rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);

/* Enable alarm interrupts */
retval = ioctl(fd, RTC_AIE_ON, 0);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

fprintf(stderr, "Waiting 5 seconds for alarm...");
fflush(stderr);
/* This blocks until the alarm ring causes an interrupt */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
	perror("read");
	exit(errno);
}
irqcount++;
fprintf(stderr, " okay. Alarm rang.\n");

/* Disable alarm interrupts */
retval = ioctl(fd, RTC_AIE_OFF, 0);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

/* Read periodic IRQ rate */
retval = ioctl(fd, RTC_IRQP_READ, &tmp);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}
fprintf(stderr, "\nPeriodic IRQ rate was %ldHz.\n", tmp);

fprintf(stderr, "Counting 20 interrupts at:");
fflush(stderr);

/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
for (tmp=2; tmp<=64; tmp*=2) {

	retval = ioctl(fd, RTC_IRQP_SET, tmp);
	if (retval == -1) {
		perror("ioctl");
		exit(errno);
	}

	fprintf(stderr, "\n%ldHz:\t", tmp);
	fflush(stderr);

	/* Enable periodic interrupts */
	retval = ioctl(fd, RTC_PIE_ON, 0);
	if (retval == -1) {
		perror("ioctl");
		exit(errno);
	}

	for (i=1; i<21; i++) {
		/* This blocks */
		retval = read(fd, &data, sizeof(unsigned long));
		if (retval == -1) {
			perror("read");
			exit(errno);
		}
		fprintf(stderr, " %d",i);
		fflush(stderr);
		irqcount++;
	}

	/* Disable periodic interrupts */
	retval = ioctl(fd, RTC_PIE_OFF, 0);
	if (retval == -1) {
		perror("ioctl");
		exit(errno);
	}
}

fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n");
fprintf(stderr, "\nTyping \"cat /proc/interrupts\" will show %d more events on IRQ 8.\n\n",
								 irqcount);

close(fd);

} /* end main */

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RTC !
  2001-04-20 11:18 npunmia
@ 2001-04-20 12:38 ` Jesper Juhl
  0 siblings, 0 replies; 7+ messages in thread
From: Jesper Juhl @ 2001-04-20 12:38 UTC (permalink / raw)
  To: npunmia; +Cc: linux-kernel

npunmia@hss.hns.com wrote:

> Hi,
>
> When i compiled the following program , (taken from
> /usr/src/linux/Documentation/rtc.txt )
>
> (See attached file: rtc2.c)
>
> it gave me the following error:
>
> [root@msatuts1 timer1]#  gcc -s -Wall -Wstrict-prototypes rtc2.c -o rtc2
> In file included from rtc2.c:17:
> /usr/include/linux/mc146818rtc.h:29: parse error before `rtc_lock'
> /usr/include/linux/mc146818rtc.h:29: warning: data definition has no type or
> storage class
> rtc2.c:25: warning: return type of `main' is not `int'
> [root@msatuts1 timer1]#
>
>  Is this a bug?Can anyone tell me how to remove this parse error ?

It works fine for me using a 2.2.16 kernel and egcs-2.91.66 (see below)...


bash-2.04$ gcc -s -Wall -Wstrict-prototypes rtc2.c -o rtc2
rtc2.c:24: warning: return type of `main' is not `int'
bash-2.04$ ./rtc2

                        RTC Driver Test Example.

Counting 5 update (1/sec) interrupts from reading /dev/rtc: 1 2 3 4 5
Again, from using select(2) on /dev/rtc: 1 2 3 4 5

Current RTC date/time is 20-4-2001, 12:34:01.
Alarm time now set to 12:34:06.
Waiting 5 seconds for alarm... okay. Alarm rang.

Periodic IRQ rate was 1024Hz.
Counting 20 interrupts at:
2Hz:     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
4Hz:     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
8Hz:     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
16Hz:    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
32Hz:    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
64Hz:    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

                         *** Test complete ***

Typing "cat /proc/interrupts" will show 131 more events on IRQ 8.

bash-2.04$


Regards,
Jesper Juhl
juhl@eisenstein.dk



^ permalink raw reply	[flat|nested] 7+ messages in thread

* RTC !
@ 2001-04-20 11:18 npunmia
  2001-04-20 12:38 ` Jesper Juhl
  0 siblings, 1 reply; 7+ messages in thread
From: npunmia @ 2001-04-20 11:18 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3284 bytes --]




Hi,

When i compiled the following program , (taken from
/usr/src/linux/Documentation/rtc.txt )


(See attached file: rtc2.c)

it gave me the following error:

[root@msatuts1 timer1]#  gcc -s -Wall -Wstrict-prototypes rtc2.c -o rtc2
In file included from rtc2.c:17:
/usr/include/linux/mc146818rtc.h:29: parse error before `rtc_lock'
/usr/include/linux/mc146818rtc.h:29: warning: data definition has no type or
storage class
rtc2.c:25: warning: return type of `main' is not `int'
[root@msatuts1 timer1]#

 Is this a bug?Can anyone tell me how to remove this parse error ?

With Regards,
--Niraj


---------------------- Forwarded by Niraj Punmia/HSS on 04/20/2001 04:31 PM
---------------------------


Niraj Punmia
04/12/2001 02:50 PM

To:   linux-kernel@vger.kernel.org
cc:

Subject:  RTC !!

Hi ,

The RTC interrupt  is programmable from 2 Hz to 8192 Hz, in powers of 2. So the
interrupts that you
could get are one of the following:      0.122ms, .244ms, .488ms, .977ms,
1.953ms, 3.906ms, 7.813ms, and so on.    Is there any  workaround , so that i
can use RTC
for meeting my requirement of an interrupt every 1.666..ms!!  ( I know that i
can use UTIME or #define HZ 600, but i want to know if i can use RTC for this
purpose )

With Regards,
--Niraj

---------------------- Forwarded by Niraj Punmia/HSS on 04/12/2001 02:33 PM
---------------------------


James Stevenson <mistral@stev.org> on 04/09/2001 06:42:44 PM

Please respond to mistral@stev.org

To:   Niraj Punmia/HSS@HSS
cc:

Subject:  Re: 1.6666.... ms interrupts needed!!





Hi

instead of modifing the time irq freq you could try using the
realt time clock (rtc) it will generate irqs with better timing
and you also wont hit system performance as much by modifing the timer
ever time the timer send an irq some code is run to see it schedule need
to be called the more times schedule is called a second the worse the
system performance is because of the task switching overhead.

In local.linux-kernel-list, you wrote:
>
>
>
>Hi.
>
>We are simulating air interface of GPRS on LAN. A TDMA(time division multiple
>access) frame duration is 40ms.  Each TDMA frame consists of 24 timeslots. Each
>timeslot  is  of 40/24 ms (i.e 1.66666.......ms) . To know  what current
>timeslot it is, we need a timer interrupt after every 1.6666... ms .   Since we
>are implementing this on LAN, minor jitters once in a while can be tolerated
>(say 0.2 ms more or less once a while would be OK).
>     As of now, we are modifying the HZ value in param.h to 600.  This gives us
>a CPU tick of  1.6666.... ms. (i.e 1/600sec).  I want to know if it would
affect
>the perfomance of the CPU.
>     Is there a better way to achieve the granularity of 1.666...ms .  Would
the
>UTIME patch be a better way from performance or any other point of view  than
>this method?
>
>With Regards,
>Niraj Punmia
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>


--
---------------------------------------------
Check Out: http://stev.org
E-Mail: mistral@stev.org
  1:10pm  up 13 days, 21:05,  5 users,  load average: 0.45, 0.45, 0.47






[-- Attachment #2: rtc2.c --]
[-- Type: application/octet-stream, Size: 4752 bytes --]


/*
 *	Real Time Clock Driver Test/Example Program
 *
 *	Compile with:
 *		gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest
 *
 *	Copyright (C) 1996, Paul Gortmaker.
 *
 *	Released under the GNU General Public License, version 2,
 *	included herein by reference.
 *
 */

#include <stdio.h>
#include <linux/mc146818rtc.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>

void main(void) {

int i, fd, retval, irqcount = 0;
unsigned long tmp, data;
struct rtc_time rtc_tm;

fd = open ("/dev/rtc", O_RDONLY);

if (fd ==  -1) {
	perror("/dev/rtc");
	exit(errno);
}

fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");

/* Turn on update interrupts (one per second) */
retval = ioctl(fd, RTC_UIE_ON, 0);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading /dev/rtc:");
fflush(stderr);
for (i=1; i<6; i++) {
	/* This read will block */
	retval = read(fd, &data, sizeof(unsigned long));
	if (retval == -1) {
		perror("read");
		exit(errno);
	}
	fprintf(stderr, " %d",i);
	fflush(stderr);
	irqcount++;
}

fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
fflush(stderr);
for (i=1; i<6; i++) {
	struct timeval tv = {5, 0};	/* 5 second timeout on select */
	fd_set readfds;

	FD_ZERO(&readfds);
	FD_SET(fd, &readfds);
	/* The select will wait until an RTC interrupt happens. */
	retval = select(fd+1, &readfds, NULL, NULL, &tv);
	if (retval == -1) {
		perror("select");
		exit(errno);
	}
	/* This read won't block unlike the select-less case above. */
	retval = read(fd, &data, sizeof(unsigned long));
	if (retval == -1) {
		perror("read");
		exit(errno);
	}
	fprintf(stderr, " %d",i);
	fflush(stderr);
	irqcount++;
}

/* Turn off update interrupts */
retval = ioctl(fd, RTC_UIE_OFF, 0);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

/* Read the RTC time/date */
retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
	rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900,
	rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);

/* Set the alarm to 5 sec in the future, and check for rollover */
rtc_tm.tm_sec += 5;
if (rtc_tm.tm_sec >= 60) {
	rtc_tm.tm_sec %= 60;
	rtc_tm.tm_min++;
}
if  (rtc_tm.tm_min == 60) {
	rtc_tm.tm_min = 0;
	rtc_tm.tm_hour++;
}
if  (rtc_tm.tm_hour == 24)
	rtc_tm.tm_hour = 0;

retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

/* Read the current alarm settings */
retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n",
	rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);

/* Enable alarm interrupts */
retval = ioctl(fd, RTC_AIE_ON, 0);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

fprintf(stderr, "Waiting 5 seconds for alarm...");
fflush(stderr);
/* This blocks until the alarm ring causes an interrupt */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
	perror("read");
	exit(errno);
}
irqcount++;
fprintf(stderr, " okay. Alarm rang.\n");

/* Disable alarm interrupts */
retval = ioctl(fd, RTC_AIE_OFF, 0);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}

/* Read periodic IRQ rate */
retval = ioctl(fd, RTC_IRQP_READ, &tmp);
if (retval == -1) {
	perror("ioctl");
	exit(errno);
}
fprintf(stderr, "\nPeriodic IRQ rate was %ldHz.\n", tmp);

fprintf(stderr, "Counting 20 interrupts at:");
fflush(stderr);

/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
for (tmp=2; tmp<=64; tmp*=2) {

	retval = ioctl(fd, RTC_IRQP_SET, tmp);
	if (retval == -1) {
		perror("ioctl");
		exit(errno);
	}

	fprintf(stderr, "\n%ldHz:\t", tmp);
	fflush(stderr);

	/* Enable periodic interrupts */
	retval = ioctl(fd, RTC_PIE_ON, 0);
	if (retval == -1) {
		perror("ioctl");
		exit(errno);
	}

	for (i=1; i<21; i++) {
		/* This blocks */
		retval = read(fd, &data, sizeof(unsigned long));
		if (retval == -1) {
			perror("read");
			exit(errno);
		}
		fprintf(stderr, " %d",i);
		fflush(stderr);
		irqcount++;
	}

	/* Disable periodic interrupts */
	retval = ioctl(fd, RTC_PIE_OFF, 0);
	if (retval == -1) {
		perror("ioctl");
		exit(errno);
	}
}

fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n");
fprintf(stderr, "\nTyping \"cat /proc/interrupts\" will show %d more events on IRQ 8.\n\n",
								 irqcount);

close(fd);

} /* end main */

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RTC !!
  2001-04-12  9:20 npunmia
@ 2001-04-12 21:39 ` David Woodhouse
  0 siblings, 0 replies; 7+ messages in thread
From: David Woodhouse @ 2001-04-12 21:39 UTC (permalink / raw)
  To: npunmia; +Cc: linux-kernel


npunmia@hss.hns.com said:
> The RTC interrupt  is programmable from 2 Hz to 8192 Hz, in powers of
> 2. So the interrupts that you could get are one of the following:
> 0.122ms, .244ms, .488ms, .977ms, 1.953ms, 3.906ms, 7.813ms, and so on.
>    Is there any  workaround , so that i can use RTC for meeting my
> requirement of an interrupt every 1.666..ms!!  ( I know that i can use
> UTIME or #define HZ 600, but i want to know if i can use RTC for this
> purpose ) 

You could also use the RTC  for providing the system tick (You'd need to 
make HZ a power of two, obviously) and then use the 8254 for providing your 
600Hz interrupt.

--
dwmw2



^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: RTC !!
@ 2001-04-12 13:05 Remko van der Vossen
  0 siblings, 0 replies; 7+ messages in thread
From: Remko van der Vossen @ 2001-04-12 13:05 UTC (permalink / raw)
  To: 'linux-kernel@vger.kernel.org', 'npunmia@hss.hns.com'

Hi Guys,

I made some errors in my last code here's the correction

Niraj wrote:
> The RTC interrupt  is programmable from 2 Hz to 8192 Hz, in 
> powers of 2. So the interrupts that you could get are one
> of the following:      0.122ms, .244ms, .488ms, .977ms,
> 1.953ms, 3.906ms, 7.813ms, and so on.    Is there any  
> workaround , so that i can use RTC for meeting my
> requirement of an interrupt every 1.666..ms!!  
> ( I know that i can use UTIME or #define HZ 600, but i want
> to know if i can use RTC for this purpose )

It's pretty simple actually, the finest granularity of the 
RTC interrupt is 0.122 ms, so if you want to use a 600 Hz 
timer you'd just have to see if that fits...
1.666/0.122 = 13.656 so it doesn't fit, the best you can do 
is 1000/(0.122*14) = 585.48 Hz you could implement this 
pretty simple, just make a counter, and increment this 
counter every time you receive an interrupt, afther 
incrementing the counter you simply check to see if it is 14, 
if so reset it to 0 and call the real interrupt handler... 
That's the best you can do with a granularity of 0.122 ms, as 
simple as that...
Ofcourse this timer would operate at an increasing time 
difference if you really need a 600Hz timer so it wouldn't be 
much good...
The thing you could do is use a timer operating at a 
frequency of half the allowed tolerance, ie in you case that 
would be a timer of max 0.4ms (half the frequency is twice 
the period) so we'd have to use the 0.244 timer here. Now 
every time you get this interrupt you request the actual time 
from the RTC and if this time is withing half the duration of 
your period (0.122 ms in this case) from your targetted time 
then you call the actual interrupt... You could optimize this 
just a bit by adding a counter so you don't have to call on 
the RTC at every interrupt, I think it'd be a bit to costly...

So, after this whole probably terribly confusing story I 
think I'll give a scenario...

here's how it should go:

inttime expect  diff     action
t0.000  t0.000  t 0.000  ==> interrupt call
t0.244  t1.666  t-1.422
t0.488  t1.666  t-1.178
t0.732  t1.666  t-0.934
t0.976  t1.666  t-0.690
t1.220  t1.666  t-0.446
t1.464  t1.666  t-0.202
t1.708  t1.666  t 0.042  ==> interrupt call
t1.952  t3.333  t-1.381
t2.196  t3.333  t-1.137
t2.440  t3.333  t-0.893
t2.684  t3.333  t-0.649
t2.928  t3.333  t-0.405
t3.172  t3.333  t-0.161
t3.416  t3.333  t 0.083  ==> interrupt call
t3.660  t5.000  t-1.340
t3.904  t5.000  t-1.096
t4.148  t5.000  t-0.852
t4.392  t5.000  t-0.608
t4.636  t5.000  t-0.364
t4.880  t5.000  t-0.120  ==> interrupt call
t5.124  t6.666  t-1.542

you can see that the difference at the point of interrupt 
trigger slightly increases every interrupt, at a certain 
point this difference will be more than 0.122 ms and then the 
interrupt before that one will be actually triggering the 
interrupt as that one is then closer to the targetted 
interrupt time, this way you are ensured that the maximum 
difference between interrupt trigger time and actual time is 
no more than 0.122 ms. The drawback in a straigtforward 
implementation of this is that the RTC is accessed every time 
an interrupt occurs, this can be optimized by adding a timer. 
I'll demonstrate in the following (pseudo) code:


assumptions:
  -gettime returns the current time in microseconds
  -there are bound te be errors in this code as I wrote it off
   the top of my head

typedef void (*tcb)( void );  //Timer callback function prototype

int32 ttime; //targetted time  (microseconds)
int32 tfreq; //timer freq      (microseconds)
int32 ttol;  //timer tolerance (microseconds)
int32 httf;  //half timer tick frequency (microseconds)
int32 mtick; //minimum RTC ticks to next timer event
int32 etick; //elapsed RTC ticks since last timer event
tcb   tmrcb; //Timer callback function

void rtcinthandler( void ) {
  //increase etick and check if a possible timer event should
  //be investigated
  if (++etick >= mtick) {
    int32 ctime = gettime();
    //check for a timer event
    if ((ctime - ttime + httf) < (httf * 2)) {
      //We've got a winner, reinit variable and call
      //callback handler
      etick = 0;
      //We recalculate ttime to prevent increasing rounding errors
      ttime = (ctime * tfreq / 1000000 + 1) * 1000000 / tfreq;
      tmrcb();
    }
  }
}

void inittimer(tcb acallback, int32 atfreq, int32 attol) {
  int32 tempval;
  int32 prevttime; //previous targetted time
  int32 ctime = gettime(); //current time

  /*todo: disable the timer if it was already running*/
  tfreq = atfreq;
  ttol = attol;
  tmrcb = acallback;
  //this is probably a very difficult way to calculate the
  //httf, but at the moment I can't come up with anything
  //better
  httf = 0;
  tempval = ttol / 112;
  while (tempval / 2)
    httf++;
  httf *= 112;
  //calculate the targetted time of the next tick..
  //the next statements may seem weird but if we require
  //the integer rounding to get the right times...
  prevttime = ctime * tfreq / 1000000 * 1000000 / tfreq;
  ttime = (ctime * tfreq / 1000000 + 1) * 1000000 / tfreq;
  //calculate the elapsed ticks since last ttime
  etick = (ctime - prevttime + httf) / (httf * 2);
  //calculate the minimum ticks between timer events
  mtick = 1000000 / (tfreq * httf * 2) - 1;
  /*todo: start the actual timer*/
}

Bye,

Remko van der Vossen
CMG Eindhoven
Remko.van.der.Vossen@cmg.nl

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RTC !!
@ 2001-04-12  9:20 npunmia
  2001-04-12 21:39 ` David Woodhouse
  0 siblings, 1 reply; 7+ messages in thread
From: npunmia @ 2001-04-12  9:20 UTC (permalink / raw)
  To: linux-kernel



Hi ,

The RTC interrupt  is programmable from 2 Hz to 8192 Hz, in powers of 2. So the
interrupts that you
could get are one of the following:      0.122ms, .244ms, .488ms, .977ms,
1.953ms, 3.906ms, 7.813ms, and so on.    Is there any  workaround , so that i
can use RTC
for meeting my requirement of an interrupt every 1.666..ms!!  ( I know that i
can use UTIME or #define HZ 600, but i want to know if i can use RTC for this
purpose )

With Regards,
--Niraj

---------------------- Forwarded by Niraj Punmia/HSS on 04/12/2001 02:33 PM
---------------------------


James Stevenson <mistral@stev.org> on 04/09/2001 06:42:44 PM

Please respond to mistral@stev.org

To:   Niraj Punmia/HSS@HSS
cc:

Subject:  Re: 1.6666.... ms interrupts needed!!





Hi

instead of modifing the time irq freq you could try using the
realt time clock (rtc) it will generate irqs with better timing
and you also wont hit system performance as much by modifing the timer
ever time the timer send an irq some code is run to see it schedule need
to be called the more times schedule is called a second the worse the
system performance is because of the task switching overhead.

In local.linux-kernel-list, you wrote:
>
>
>
>Hi.
>
>We are simulating air interface of GPRS on LAN. A TDMA(time division multiple
>access) frame duration is 40ms.  Each TDMA frame consists of 24 timeslots. Each
>timeslot  is  of 40/24 ms (i.e 1.66666.......ms) . To know  what current
>timeslot it is, we need a timer interrupt after every 1.6666... ms .   Since we
>are implementing this on LAN, minor jitters once in a while can be tolerated
>(say 0.2 ms more or less once a while would be OK).
>     As of now, we are modifying the HZ value in param.h to 600.  This gives us
>a CPU tick of  1.6666.... ms. (i.e 1/600sec).  I want to know if it would
affect
>the perfomance of the CPU.
>     Is there a better way to achieve the granularity of 1.666...ms .  Would
the
>UTIME patch be a better way from performance or any other point of view  than
>this method?
>
>With Regards,
>Niraj Punmia
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>


--
---------------------------------------------
Check Out: http://stev.org
E-Mail: mistral@stev.org
  1:10pm  up 13 days, 21:05,  5 users,  load average: 0.45, 0.45, 0.47





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2001-04-21 10:52 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-04-12 12:33 RTC !! Remko van der Vossen
  -- strict thread matches above, loose matches on Subject: below --
2001-04-21 10:49 RTC ! npunmia
2001-04-20 11:18 npunmia
2001-04-20 12:38 ` Jesper Juhl
2001-04-12 13:05 RTC !! Remko van der Vossen
2001-04-12  9:20 npunmia
2001-04-12 21:39 ` David Woodhouse

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).