[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Timer resolution et al
- Date: Wed, 10 Mar 2004 08:05:40 -0000
- From: BPSTEVENS at qinetiq.com (Stevens Brian)
- Subject: Timer resolution et al
Let me start by saying that I am not an expert on RTEMS and have stated to
use it recently having looked at it 1st about 5 years ago.
The potential accuracy of the timer chip (8254)that runs at 8MHz, so should
be able to support micro second accuracy.
However, if you change the micro seconds per tick, the interrupt handler
will be active more often and use more resources. Also you may need to
change the ticks per timeslice to make sure that your timeslice stays the
same, if you do not the system may spend too much of its time doing contexts
For my use I would prefer that the timers are separate.
I hope that this helps and if any one else has more information then they
will offer it up.
From: sashti srinivasan [mailto:svasn_rtems at yahoo.com]
Sent: 10 March 2004 05:34
To: Stevens Brian; 'rtems-users at rtems.com'
Subject: Re: Timer resolution et al
Thanks for one important information, that rtc
chip interrupts the processor ~122 microseconds. I am
able to get 10 microsecond accuracy without going to
hardware. Please correct me if I am wrong. I
configured the CONFIGURE_MICROSECONDS_PER_TICK to 10
microseconds and hoping that it is giving with 10
microseconds accuracy on pc386. Am I wrong? Please
I am also working on PC386 BSP. One thing coming
to my mind, we have a bios whose services can be made
effective use of. Is there any service in bios that
gives 1 microsecond accuracy?
Various timing tests that are distributed with
rtems did not run on PC386. Mr.Joel also wanted to
know whether anyone got them working on PC386. Have
you got them working? I am not sure, but I think the
problem is only with timer
The timing tests make use of timer functions
Timer_initialize() and Read_timer(). Probably these
functions cause the problem.
Hardware: Probably the best place to know about
hardware is rtems source code. In the above mentioned
file, the function rtdsc() is probably giving time
from hardware. It is a short function counting to
less than 5 lines. I could not understand the most
important line in this. That is:
asm volatile(".byte 0x0F, 0x31" : "=A" (result));
I referred to the gnu documentation for gcc. Only
things I found out was, "=" specifies result is a
output,"A" specifies some attributes of result. But
as per the documentation, the string preceding :
should contain a instruction mnemonic. I do not
understand the presence of assembler directive .byte
as the part of the string. Sorry for troubling the
members of the list with doubt unrelated to rtems.
Thanks if anyone can explain this to me.
--- Stevens Brian <BPSTEVENS at qinetiq.com> wrote:
> I have been following the thread on timer resolution
> etc as I have a need
> for the following:
> A timer with an accuracy of sub milliseconds
> A timer that is not dependant on the underlying
> clock tick.
> I am working with the pc386 port and have formulated
> some ideas:
> Use one of the other counters on the timer chip.
> This seems a straight forward way to do the job
> altering the existing code, and since most timer
> chips have more than 1
> counter it could probably be extended to other
> ports. However, it seems that
> the other timer outputs are not normally conected to
> the interrupt
> Use the real time clock
> In the PC the real time clock chip can provide a
> interrupt with a resolution of ~122 micro seconds
> and this line is connected
> to the interrupt controller.
> I would prefer to go with the 1st method as I think
> that this would have
> more generall application. If any one can help me
> with the hardware parts
> then I am willing to have a go at the code for the
> pc386. (this is a home
> job not a work job so it may take some time)
> Thank You
> Brian Stevens
> Cody Technology Park,
> Ively Road,
> GU14 0LX .
> Telephone (01252) 393959
> Fax (01252) 395120
> The Information contained in this E-Mail and any
> subsequent correspondence
> is private and is intended solely for the intended
> For those other than the recipient any disclosure,
> copying, distribution,
> or any action taken or omitted to be taken in
> reliance on such information
> is prohibited and may be unlawful.
> Emails and other electronic communication with
> QinetiQ may be monitored.
> Calls to QinetiQ may be recorded for quality
> regulatory and monitoring purposes.
Do you Yahoo!?
Yahoo! Search - Find what you're looking for faster
The Information contained in this E-Mail and any subsequent correspondence
is private and is intended solely for the intended recipient(s).
For those other than the recipient any disclosure, copying, distribution,
or any action taken or omitted to be taken in reliance on such information
is prohibited and may be unlawful.
Emails and other electronic communication with QinetiQ may be monitored.
Calls to QinetiQ may be recorded for quality control,
regulatory and monitoring purposes.