Clock Resolution

I’ve installed RTP. I’m wondering how I get a clock with higher
resolution than 1ms (CLOCK_REATIME)? I need a timer that is exactly
3.03ms (for a 330Hz loop). Is there a clock on the PC that I can attach
to?

Try the ClockPeriod() function. It seems to set the clock to whatever
values come close to the ones you specify, down to several hundred
microseconds…

struct _clockperiod cp1, cp2;

cp1.nsec = 1000000;
cp1.fract = 0;

if ( ClockPeriod( CLOCK_REALTIME, &cp1, &cp2, 0) )
{
printf(“ClockPeriod() (set version)failed: %s (need to be
root).\n”,
strerror( errno ));
exit(1);
}


Dan McShan wrote:

I’ve installed RTP. I’m wondering how I get a clock with higher
resolution than 1ms (CLOCK_REATIME)? I need a timer that is exactly
3.03ms (for a 330Hz loop). Is there a clock on the PC that I can attach
to?

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

For precise timing a timer always need to be a multiple of 999847 nsec,
that’s a hardware “limit”. Since 3.03ms isn’t a multiple
of that you can’t get it precisely and minimum
tick rate is at the moment 500us.

Unless you can get some customer hardware or timer
card to generate an interrupt at 330hz I don’t see any
way to do that.


Check out:
http://qdn.qnx.com/articles/oct2300/quantization.html
http://qdn.qnx.com/articles/oct3100/concept_of_time.html

“Dan McShan” <dan@syzygyx.com> wrote in message
news:3AAF9240.97BAA844@syzygyx.com

I’ve installed RTP. I’m wondering how I get a clock with higher
resolution than 1ms (CLOCK_REATIME)? I need a timer that is exactly
3.03ms (for a 330Hz loop). Is there a clock on the PC that I can attach
to?

ClockPeriod does a pretty good job. Over 1 second, I get a minimum
period of 3.021 ms and a max of 3.036. Since I’m going to be resynching
every 1s anyways, this is okay. When I run the clock longer, though, I
get a spurrious 6.057ms, which appears to be symptomatic of a missed
frame. Perhaps I will look into putting the code into interrupt context
and see how it goes.

I was really hoping that there was another standard clock source on the
PC. On the MV162 motorola boards I’ve worked on in the past, there were
at least 4 clocks available for system use (2 on the VME chip, and 2 on
the MCC memory chip). I’m guessing that similar clocks are on the PC
motherboard somewhere, but are not standard. I’ll do some more digging.

Thanks for the help.
Dan


“John H. Zouck” wrote:

Try the ClockPeriod() function. It seems to set the clock to whatever
values come close to the ones you specify, down to several hundred
microseconds…

struct _clockperiod cp1, cp2;

cp1.nsec = 1000000;
cp1.fract = 0;

if ( ClockPeriod( CLOCK_REALTIME, &cp1, &cp2, 0) )
{
printf(“ClockPeriod() (set version)failed: %s (need to be
root).\n”,
strerror( errno ));
exit(1);
}

Dan McShan wrote:

I’ve installed RTP. I’m wondering how I get a clock with higher
resolution than 1ms (CLOCK_REATIME)? I need a timer that is exactly
3.03ms (for a 330Hz loop). Is there a clock on the PC that I can attach
to?

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

Mario Charest wrote:

For precise timing a timer always need to be a multiple of 999847 nsec,
that’s a hardware “limit”. Since 3.03ms isn’t a multiple
of that you can’t get it precisely and minimum
tick rate is at the moment 500us.

Yes … but a clock period of 500us means also a timeslice of
4*500ms => 2ms which can overload your system by context switches
:frowning:
(in addition to the fast timer handling … )

Unless you can get some customer hardware or timer
card to generate an interrupt at 330hz I don’t see any
way to do that.

Use the Real Time Clock (RTC) … it’s bound to the IRQ8 of your PC
(the time resolution can go down to ~100us )

Armin

Dan, drop me a mail if you have problems to implement it …

To demonstrate the accuracy and repeatability of the bc635pci card and QRTP,
here’s output from a simple program that sets the clock rate to 3030
microseconds and does a bc635_delay() call, followed by a b c635_get_time() call
in a loop, printing the times after each delay() call (from a buffer) after all
loops have completed:

Tic. Time = 2203.372707
Tic. Time = 2203.375735 delta time = 0.003028.
Tic. Time = 2203.378763 delta time = 0.003028.
Tic. Time = 2203.381794 delta time = 0.003031.
Tic. Time = 2203.384823 delta time = 0.003029.
Tic. Time = 2203.387855 delta time = 0.003032.
Tic. Time = 2203.390883 delta time = 0.003028.
Tic. Time = 2203.393914 delta time = 0.003031.
Tic. Time = 2203.396943 delta time = 0.003029.
Tic. Time = 2203.399973 delta time = 0.003030.
Tic. Time = 2203.403011 delta time = 0.003038.
Tic. Time = 2203.406034 delta time = 0.003023.
Tic. Time = 2203.409063 delta time = 0.003029.
Tic. Time = 2203.412093 delta time = 0.003030.
Tic. Time = 2203.415123 delta time = 0.003030.
Tic. Time = 2203.418153 delta time = 0.003030.
Tic. Time = 2203.421183 delta time = 0.003030.
Tic. Time = 2203.424215 delta time = 0.003032.
Tic. Time = 2203.427243 delta time = 0.003028.
Tic. Time = 2203.430273 delta time = 0.003030.
Tic. Time = 2203.433303 delta time = 0.003030.
Tic. Time = 2203.436333 delta time = 0.003030.
Tic. Time = 2203.439363 delta time = 0.003030.
Tic. Time = 2203.442393 delta time = 0.003030.
Tic. Time = 2203.445423 delta time = 0.003030.
Tic. Time = 2203.448453 delta time = 0.003030.
Tic. Time = 2203.451483 delta time = 0.003030.
Tic. Time = 2203.454513 delta time = 0.003030.
Tic. Time = 2203.457543 delta time = 0.003030.


“John H. Zouck” wrote:

I am using a Datum, Bancomm Division BC635PCI time processor (they call it)
to create a clock (10 MHz) synchronized to an external source (1 PPS, IRIG-B,
GPS-on-board, etc.) It can be used as a source of time (to 100 ns resoultion)
or to wake threads at user-settable rates. I’ve set rates down to 50-100
microseconds successfully, and with the driver I’ve written, multiple threads
can wait for clock tics at the user-settable rates.

If you’re interested, I’ve written a QRTP resource manager for it, along with
man-page documentation, and given it to Datum for distribution. It’s free,
but I’d like any useful updates, since I did not implement all functions. The
resource manager supports card functions using devctl() calls, but there is
a library the application program can use that implements the following
calls:

extern int bc635_set_periodic_output(int fd, unsigned int
period_microseconds, int one_pps_sync);
extern int bc635_enable_int(int fd);
extern int bc635_disable_int(int fd);
extern int bc635_delay(int fd, unsigned int count);

extern int bc635_set_mode(int fd, int seconds);
extern int bc635_set_time(int fd, int seconds);

extern int bc635_get_time(int fd, double *seconds, int *lockstatus);
extern int bc635_get_model(int fd, char *model, int len);
extern int bc635_get_assembly(int fd, char *assembly, int len);
extern int bc635_get_hwfab(int fd, char *hwfab, int len);
extern int bc635_get_firmware_part(int fd, char *firmware_part, int
len);
extern int bc635_get_serial(int fd, char *serial, int len);

extern void bc635_lockstatus_str(int lockstatus, char *str);
extern int bc635_software_reset(int fd);

Mario Charest wrote:

For precise timing a timer always need to be a multiple of 999847 nsec,
that’s a hardware “limit”. Since 3.03ms isn’t a multiple
of that you can’t get it precisely and minimum
tick rate is at the moment 500us.

Unless you can get some customer hardware or timer
card to generate an interrupt at 330hz I don’t see any
way to do that.

Check out:
http://qdn.qnx.com/articles/oct2300/quantization.html
http://qdn.qnx.com/articles/oct3100/concept_of_time.html

“Dan McShan” <> dan@syzygyx.com> > wrote in message
news:> 3AAF9240.97BAA844@syzygyx.com> …
I’ve installed RTP. I’m wondering how I get a clock with higher
resolution than 1ms (CLOCK_REATIME)? I need a timer that is exactly
3.03ms (for a 330Hz loop). Is there a clock on the PC that I can attach
to?

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

Armin Steinhoff <A-Steinhoff@web_.de> writes:

Mario Charest wrote:

For precise timing a timer always need to be a multiple of 999847 nsec,
that’s a hardware “limit”. Since 3.03ms isn’t a multiple
of that you can’t get it precisely and minimum
tick rate is at the moment 500us.

Yes … but a clock period of 500us means also a timeslice of
4*500ms => 2ms which can overload your system by context switches
:frowning:
(in addition to the fast timer handling … )

Actually, you can set the timer down to 100us. We use a 500us timer on
350MHz K6 2s – works great, with no dramatic impact on performance

Use the Real Time Clock (RTC) … it’s bound to the IRQ8 of your PC
(the time resolution can go down to ~100us )

If you are running on a Pentium or better, use the Pentium’s time stamp
counter. Besides being a lot mor accurate, it’s also very easy to
use. Only drawback - it’s dependant on your CPU’s clock speed. Here is
some sample code:

/*

  • Tsc.h - based on code by Thomas Herbig
    */
    #ifndef __TSC_H_INCLUDED
    #define __TSC_H_INCLUDED

typedef struct {
int low;
int high;
} Tsc_t;

void TscDiff(Tsc_t *start, Tsc_t *stop, Tsc_t *result);
#define TscDiff(start, stop, result) {
Tsc_t *__start = (start);
Tsc_t *__stop = (stop);
Tsc_t *__result = (result);
__result->low = __stop->low - __start->low;
if (__stop->low < __start->high)
__result->high = __stop->high - __start->high - 1;
else
__result->high = __stop->high - __start->high; }

/*

  • Read the Pentium time stamp counter and copy it to the memory
  • pointed to by tsc.
    */
    void TscRead(Tsc_t *tsc);
    #pragma aux TscRead =
    “db 0fh,31h”
    “mov [ebx],eax”
    “mov [ebx+4],edx”
    parm nomemory [ebx]
    modify exact nomemory [eax edx];

#endif


to use:

Tsc_t start, stop, result;

TscRead(&start);

TscRead(&stop);

TscDiff(start, stop, result);

result now contains the number of clock cycles between the two TscReads
(as a 64 bit integer).


Dipl.-Ing. Eric Doenges http://www.rcs.ei.tum.de
Institute for Real-Time Computer Systems (RCS) fon +49-89-289-23590
Technische Universitaet Muenchen, D-80290 Muenchen fax +49-89-289-23555

Eric Doenges wrote:

Armin Steinhoff <A-Steinhoff@web_.de> writes:

Mario Charest wrote:

For precise timing a timer always need to be a multiple of 999847 nsec,
that’s a hardware “limit”. Since 3.03ms isn’t a multiple
of that you can’t get it precisely and minimum
tick rate is at the moment 500us.

Yes … but a clock period of 500us means also a timeslice of
4*500ms => 2ms which can overload your system by context switches
:frowning:
(in addition to the fast timer handling … )

Actually, you can set the timer down to 100us. We use a 500us timer on
350MHz K6 2s – works great, with no dramatic impact on performance

It depends on the power of the CPU … the impact is also not
growing linear.

Use the Real Time Clock (RTC) … it’s bound to the IRQ8 of your PC
(the time resolution can go down to ~100us )

If you are running on a Pentium or better, use the Pentium’s time stamp
counter. Besides being a lot mor accurate, it’s also very easy to
use. Only drawback - it’s dependant on your CPU’s clock speed. Here is
some sample code:

I understood that the issue was a periodical interrupt source used
as a trigger … and not time messurement.

Armin

I supect that I will end up using an external clock… although I am
investigating the rtc’s precision. For my prototype, I’m going to be
working on a laptop and will probably just get a PCMCIA card with
timer/counters and sync up with the 1pps from the GPS. Ultimately, the
platform will likely be a cPCI system, at which time I will use a Datum
bc635pmc. One question I have is whether or not the Datum cards provide
access to the raw GPS data. I will ultimately need this for some
navigation algorithms.

Again, thanks for all the help.

“John H. Zouck” wrote:

To demonstrate the accuracy and repeatability of the bc635pci card and QRTP,
here’s output from a simple program that sets the clock rate to 3030
microseconds and does a bc635_delay() call, followed by a b c635_get_time() call
in a loop, printing the times after each delay() call (from a buffer) after all
loops have completed:

Tic. Time = 2203.372707
Tic. Time = 2203.375735 delta time = 0.003028.
Tic. Time = 2203.378763 delta time = 0.003028.
Tic. Time = 2203.381794 delta time = 0.003031.
Tic. Time = 2203.384823 delta time = 0.003029.
Tic. Time = 2203.387855 delta time = 0.003032.
Tic. Time = 2203.390883 delta time = 0.003028.
Tic. Time = 2203.393914 delta time = 0.003031.
Tic. Time = 2203.396943 delta time = 0.003029.
Tic. Time = 2203.399973 delta time = 0.003030.
Tic. Time = 2203.403011 delta time = 0.003038.
Tic. Time = 2203.406034 delta time = 0.003023.
Tic. Time = 2203.409063 delta time = 0.003029.
Tic. Time = 2203.412093 delta time = 0.003030.
Tic. Time = 2203.415123 delta time = 0.003030.
Tic. Time = 2203.418153 delta time = 0.003030.
Tic. Time = 2203.421183 delta time = 0.003030.
Tic. Time = 2203.424215 delta time = 0.003032.
Tic. Time = 2203.427243 delta time = 0.003028.
Tic. Time = 2203.430273 delta time = 0.003030.
Tic. Time = 2203.433303 delta time = 0.003030.
Tic. Time = 2203.436333 delta time = 0.003030.
Tic. Time = 2203.439363 delta time = 0.003030.
Tic. Time = 2203.442393 delta time = 0.003030.
Tic. Time = 2203.445423 delta time = 0.003030.
Tic. Time = 2203.448453 delta time = 0.003030.
Tic. Time = 2203.451483 delta time = 0.003030.
Tic. Time = 2203.454513 delta time = 0.003030.
Tic. Time = 2203.457543 delta time = 0.003030.

“John H. Zouck” wrote:

I am using a Datum, Bancomm Division BC635PCI time processor (they call it)
to create a clock (10 MHz) synchronized to an external source (1 PPS, IRIG-B,
GPS-on-board, etc.) It can be used as a source of time (to 100 ns resoultion)
or to wake threads at user-settable rates. I’ve set rates down to 50-100
microseconds successfully, and with the driver I’ve written, multiple threads
can wait for clock tics at the user-settable rates.

If you’re interested, I’ve written a QRTP resource manager for it, along with
man-page documentation, and given it to Datum for distribution. It’s free,
but I’d like any useful updates, since I did not implement all functions. The
resource manager supports card functions using devctl() calls, but there is
a library the application program can use that implements the following
calls:

extern int bc635_set_periodic_output(int fd, unsigned int
period_microseconds, int one_pps_sync);
extern int bc635_enable_int(int fd);
extern int bc635_disable_int(int fd);
extern int bc635_delay(int fd, unsigned int count);

extern int bc635_set_mode(int fd, int seconds);
extern int bc635_set_time(int fd, int seconds);

extern int bc635_get_time(int fd, double *seconds, int *lockstatus);
extern int bc635_get_model(int fd, char *model, int len);
extern int bc635_get_assembly(int fd, char *assembly, int len);
extern int bc635_get_hwfab(int fd, char *hwfab, int len);
extern int bc635_get_firmware_part(int fd, char *firmware_part, int
len);
extern int bc635_get_serial(int fd, char *serial, int len);

extern void bc635_lockstatus_str(int lockstatus, char *str);
extern int bc635_software_reset(int fd);

Mario Charest wrote:

For precise timing a timer always need to be a multiple of 999847 nsec,
that’s a hardware “limit”. Since 3.03ms isn’t a multiple
of that you can’t get it precisely and minimum
tick rate is at the moment 500us.

Unless you can get some customer hardware or timer
card to generate an interrupt at 330hz I don’t see any
way to do that.

Check out:
http://qdn.qnx.com/articles/oct2300/quantization.html
http://qdn.qnx.com/articles/oct3100/concept_of_time.html

“Dan McShan” <> dan@syzygyx.com> > wrote in message
news:> 3AAF9240.97BAA844@syzygyx.com> …
I’ve installed RTP. I’m wondering how I get a clock with higher
resolution than 1ms (CLOCK_REATIME)? I need a timer that is exactly
3.03ms (for a 330Hz loop). Is there a clock on the PC that I can attach
to?

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

John H. Zouck
The Johns Hopkins University
Applied Physics Laboratory

Dan McShan (dan@syzygyx.com) wrote:
: I supect that I will end up using an external clock… although I am
: investigating the rtc’s precision. For my prototype, I’m going to be
: working on a laptop and will probably just get a PCMCIA card with
: timer/counters and sync up with the 1pps from the GPS. Ultimately, the
: platform will likely be a cPCI system, at which time I will use a Datum
: bc635pmc. One question I have is whether or not the Datum cards provide
: access to the raw GPS data. I will ultimately need this for some
: navigation algorithms.

As a really gross hack, you could jimmy up a serial port for 3300 baud with
8 data bits, 1 stop bit and some parity (to make 10 bits) and
create a loopback connector so that you interrupt yourself at 330 Hz

Well, I did say it was a really gross hack :slight_smile:

Cheers,
-RK

: Again, thanks for all the help.

: “John H. Zouck” wrote:
: >
: > To demonstrate the accuracy and repeatability of the bc635pci card and QRTP,
: > here’s output from a simple program that sets the clock rate to 3030
: > microseconds and does a bc635_delay() call, followed by a b c635_get_time() call
: > in a loop, printing the times after each delay() call (from a buffer) after all
: > loops have completed:
: >
: > Tic. Time = 2203.372707
: > Tic. Time = 2203.375735 delta time = 0.003028.
: > Tic. Time = 2203.378763 delta time = 0.003028.
: > Tic. Time = 2203.381794 delta time = 0.003031.
: > Tic. Time = 2203.384823 delta time = 0.003029.
: > Tic. Time = 2203.387855 delta time = 0.003032.
: > Tic. Time = 2203.390883 delta time = 0.003028.
: > Tic. Time = 2203.393914 delta time = 0.003031.
: > Tic. Time = 2203.396943 delta time = 0.003029.
: > Tic. Time = 2203.399973 delta time = 0.003030.
: > Tic. Time = 2203.403011 delta time = 0.003038.
: > Tic. Time = 2203.406034 delta time = 0.003023.
: > Tic. Time = 2203.409063 delta time = 0.003029.
: > Tic. Time = 2203.412093 delta time = 0.003030.
: > Tic. Time = 2203.415123 delta time = 0.003030.
: > Tic. Time = 2203.418153 delta time = 0.003030.
: > Tic. Time = 2203.421183 delta time = 0.003030.
: > Tic. Time = 2203.424215 delta time = 0.003032.
: > Tic. Time = 2203.427243 delta time = 0.003028.
: > Tic. Time = 2203.430273 delta time = 0.003030.
: > Tic. Time = 2203.433303 delta time = 0.003030.
: > Tic. Time = 2203.436333 delta time = 0.003030.
: > Tic. Time = 2203.439363 delta time = 0.003030.
: > Tic. Time = 2203.442393 delta time = 0.003030.
: > Tic. Time = 2203.445423 delta time = 0.003030.
: > Tic. Time = 2203.448453 delta time = 0.003030.
: > Tic. Time = 2203.451483 delta time = 0.003030.
: > Tic. Time = 2203.454513 delta time = 0.003030.
: > Tic. Time = 2203.457543 delta time = 0.003030.
: >
: > “John H. Zouck” wrote:
: >
: > > I am using a Datum, Bancomm Division BC635PCI time processor (they call it)
: > > to create a clock (10 MHz) synchronized to an external source (1 PPS, IRIG-B,
: > > GPS-on-board, etc.) It can be used as a source of time (to 100 ns resoultion)
: > > or to wake threads at user-settable rates. I’ve set rates down to 50-100
: > > microseconds successfully, and with the driver I’ve written, multiple threads
: > > can wait for clock tics at the user-settable rates.
: > >
: > > If you’re interested, I’ve written a QRTP resource manager for it, along with
: > > man-page documentation, and given it to Datum for distribution. It’s free,
: > > but I’d like any useful updates, since I did not implement all functions. The
: > > resource manager supports card functions using devctl() calls, but there is
: > > a library the application program can use that implements the following
: > > calls:
: > >
: > > extern int bc635_set_periodic_output(int fd, unsigned int
: > > period_microseconds, int one_pps_sync);
: > > extern int bc635_enable_int(int fd);
: > > extern int bc635_disable_int(int fd);
: > > extern int bc635_delay(int fd, unsigned int count);
: > >
: > > extern int bc635_set_mode(int fd, int seconds);
: > > extern int bc635_set_time(int fd, int seconds);
: > >
: > > extern int bc635_get_time(int fd, double *seconds, int *lockstatus);
: > > extern int bc635_get_model(int fd, char *model, int len);
: > > extern int bc635_get_assembly(int fd, char *assembly, int len);
: > > extern int bc635_get_hwfab(int fd, char *hwfab, int len);
: > > extern int bc635_get_firmware_part(int fd, char *firmware_part, int
: > > len);
: > > extern int bc635_get_serial(int fd, char *serial, int len);
: > >
: > > extern void bc635_lockstatus_str(int lockstatus, char *str);
: > > extern int bc635_software_reset(int fd);
: > >
: > > Mario Charest wrote:
: > >
: > > > For precise timing a timer always need to be a multiple of 999847 nsec,
: > > > that’s a hardware “limit”. Since 3.03ms isn’t a multiple
: > > > of that you can’t get it precisely and minimum
: > > > tick rate is at the moment 500us.
: > > >
: > > > Unless you can get some customer hardware or timer
: > > > card to generate an interrupt at 330hz I don’t see any
: > > > way to do that.
: > > >
: > > > Check out:
: > > > http://qdn.qnx.com/articles/oct2300/quantization.html
: > > > http://qdn.qnx.com/articles/oct3100/concept_of_time.html
: > > >
: > > > “Dan McShan” <dan@syzygyx.com> wrote in message
: > > > news:3AAF9240.97BAA844@syzygyx.com
: > > > > I’ve installed RTP. I’m wondering how I get a clock with higher
: > > > > resolution than 1ms (CLOCK_REATIME)? I need a timer that is exactly
: > > > > 3.03ms (for a 330Hz loop). Is there a clock on the PC that I can attach
: > > > > to?
: > >
: > > –
: > > ============================
: > > John H. Zouck
: > > The Johns Hopkins University
: > > Applied Physics Laboratory
: > > ============================
: >
: > –
: > ============================
: > John H. Zouck
: > The Johns Hopkins University
: > Applied Physics Laboratory
: > ============================

Robert Krten, PARSE Software Devices; email my initials at parse dot com
Consulting, Systems Architecture / Design, Drivers, Training, QNX 4 & Neutrino
Check out our new QNX 4 and Neutrino (QRTP) books at http://www.parse.com/
Wanted PDP-8/9/10/11/12 Systems/documentation/spare parts! Will trade books!

“Robert Krten” <nospam@parse.com> wrote in message
news:Eyqs6.51195$p66.15940173@news3.rdc1.on.home.com

Dan McShan (> dan@syzygyx.com> ) wrote:
: I supect that I will end up using an external clock… although I am
: investigating the rtc’s precision. For my prototype, I’m going to be
: working on a laptop and will probably just get a PCMCIA card with
: timer/counters and sync up with the 1pps from the GPS. Ultimately, the
: platform will likely be a cPCI system, at which time I will use a Datum
: bc635pmc. One question I have is whether or not the Datum cards provide
: access to the raw GPS data. I will ultimately need this for some
: navigation algorithms.

As a really gross hack, you could jimmy up a serial port for 3300 baud
with
8 data bits, 1 stop bit and some parity (to make 10 bits) and
create a loopback connector so that you interrupt yourself at 330 Hz

Do PC hardware allow non standard baud rate?

Well, I did say it was a really gross hack > :slight_smile:

Cheers,
-RK

: Again, thanks for all the help.

: “John H. Zouck” wrote:
:
: > To demonstrate the accuracy and repeatability of the bc635pci card and
QRTP,
: > here’s output from a simple program that sets the clock rate to 3030
: > microseconds and does a bc635_delay() call, followed by a b
c635_get_time() call
: > in a loop, printing the times after each delay() call (from a buffer)
after all
: > loops have completed:
:
: > Tic. Time = 2203.372707
: > Tic. Time = 2203.375735 delta time = 0.003028.
: > Tic. Time = 2203.378763 delta time = 0.003028.
: > Tic. Time = 2203.381794 delta time = 0.003031.
: > Tic. Time = 2203.384823 delta time = 0.003029.
: > Tic. Time = 2203.387855 delta time = 0.003032.
: > Tic. Time = 2203.390883 delta time = 0.003028.
: > Tic. Time = 2203.393914 delta time = 0.003031.
: > Tic. Time = 2203.396943 delta time = 0.003029.
: > Tic. Time = 2203.399973 delta time = 0.003030.
: > Tic. Time = 2203.403011 delta time = 0.003038.
: > Tic. Time = 2203.406034 delta time = 0.003023.
: > Tic. Time = 2203.409063 delta time = 0.003029.
: > Tic. Time = 2203.412093 delta time = 0.003030.
: > Tic. Time = 2203.415123 delta time = 0.003030.
: > Tic. Time = 2203.418153 delta time = 0.003030.
: > Tic. Time = 2203.421183 delta time = 0.003030.
: > Tic. Time = 2203.424215 delta time = 0.003032.
: > Tic. Time = 2203.427243 delta time = 0.003028.
: > Tic. Time = 2203.430273 delta time = 0.003030.
: > Tic. Time = 2203.433303 delta time = 0.003030.
: > Tic. Time = 2203.436333 delta time = 0.003030.
: > Tic. Time = 2203.439363 delta time = 0.003030.
: > Tic. Time = 2203.442393 delta time = 0.003030.
: > Tic. Time = 2203.445423 delta time = 0.003030.
: > Tic. Time = 2203.448453 delta time = 0.003030.
: > Tic. Time = 2203.451483 delta time = 0.003030.
: > Tic. Time = 2203.454513 delta time = 0.003030.
: > Tic. Time = 2203.457543 delta time = 0.003030.
:
: > “John H. Zouck” wrote:
:
: > > I am using a Datum, Bancomm Division BC635PCI time processor (they
call it)
: > > to create a clock (10 MHz) synchronized to an external source (1
PPS, IRIG-B,
: > > GPS-on-board, etc.) It can be used as a source of time (to 100 ns
resoultion)
: > > or to wake threads at user-settable rates. I’ve set rates down to
50-100
: > > microseconds successfully, and with the driver I’ve written,
multiple threads
: > > can wait for clock tics at the user-settable rates.
:
: > > If you’re interested, I’ve written a QRTP resource manager for it,
along with
: > > man-page documentation, and given it to Datum for distribution. It’s
free,
: > > but I’d like any useful updates, since I did not implement all
functions. The
: > > resource manager supports card functions using devctl() calls, but
there is
: > > a library the application program can use that implements the
following
: > > calls:
:
: > > extern int bc635_set_periodic_output(int fd, unsigned int
: > > period_microseconds, int one_pps_sync);
: > > extern int bc635_enable_int(int fd);
: > > extern int bc635_disable_int(int fd);
: > > extern int bc635_delay(int fd, unsigned int count);
:
: > > extern int bc635_set_mode(int fd, int seconds);
: > > extern int bc635_set_time(int fd, int seconds);
:
: > > extern int bc635_get_time(int fd, double *seconds, int
*lockstatus);
: > > extern int bc635_get_model(int fd, char *model, int len);
: > > extern int bc635_get_assembly(int fd, char *assembly, int len);
: > > extern int bc635_get_hwfab(int fd, char *hwfab, int len);
: > > extern int bc635_get_firmware_part(int fd, char *firmware_part,
int
: > > len);
: > > extern int bc635_get_serial(int fd, char *serial, int len);
:
: > > extern void bc635_lockstatus_str(int lockstatus, char *str);
: > > extern int bc635_software_reset(int fd);
:
: > > Mario Charest wrote:
:
: > > > For precise timing a timer always need to be a multiple of 999847
nsec,
: > > > that’s a hardware “limit”. Since 3.03ms isn’t a multiple
: > > > of that you can’t get it precisely and minimum
: > > > tick rate is at the moment 500us.
:
: > > > Unless you can get some customer hardware or timer
: > > > card to generate an interrupt at 330hz I don’t see any
: > > > way to do that.
:
: > > > Check out:
: > > > > http://qdn.qnx.com/articles/oct2300/quantization.html
: > > > > http://qdn.qnx.com/articles/oct3100/concept_of_time.html
:
: > > > “Dan McShan” <> dan@syzygyx.com> > wrote in message
: > > > news:> 3AAF9240.97BAA844@syzygyx.com> …
: > > > > I’ve installed RTP. I’m wondering how I get a clock with higher
: > > > > resolution than 1ms (CLOCK_REATIME)? I need a timer that is
exactly
: > > > > 3.03ms (for a 330Hz loop). Is there a clock on the PC that I
can attach
: > > > > to?
:
: > > –
: > > ============================
: > > John H. Zouck
: > > The Johns Hopkins University
: > > Applied Physics Laboratory
: > > ============================
:
: > –
: > ============================
: > John H. Zouck
: > The Johns Hopkins University
: > Applied Physics Laboratory
: > ============================

Robert Krten, PARSE Software Devices; email my initials at parse dot com
Consulting, Systems Architecture / Design, Drivers, Training, QNX 4 &
Neutrino
Check out our new QNX 4 and Neutrino (QRTP) books at > http://www.parse.com/
Wanted PDP-8/9/10/11/12 Systems/documentation/spare parts! Will trade
books!

“Mario Charest” <mcharest@void_zinformatic.com> wrote in message
news:HWss6.3930$Yo2.79291@weber.videotron.net

“Robert Krten” <> nospam@parse.com> > wrote in message
news:Eyqs6.51195$> p66.15940173@news3.rdc1.on.home.com> …
Dan McShan (> dan@syzygyx.com> ) wrote:
: I supect that I will end up using an external clock… although I am
: investigating the rtc’s precision. For my prototype, I’m going to be
: working on a laptop and will probably just get a PCMCIA card with
: timer/counters and sync up with the 1pps from the GPS. Ultimately,
the
: platform will likely be a cPCI system, at which time I will use a
Datum
: bc635pmc. One question I have is whether or not the Datum cards
provide
: access to the raw GPS data. I will ultimately need this for some
: navigation algorithms.

As a really gross hack, you could jimmy up a serial port for 3300 baud
with
8 data bits, 1 stop bit and some parity (to make 10 bits) and
create a loopback connector so that you interrupt yourself at 330 Hz


Do PC hardware allow non standard baud rate?

Yes, you can stick whatever baud rate divisor you want into the UART. I’ve
made good use of this in the past when communicating with a microcontroller
that couldn’t easily provide a standard baud rate. And the lower the baud
rate, the better the frequency resolution. Given that the highest baud rate
you can get out a standard PC UART is 115200, the resolution at 3300 baud is
going to be about 2%, which by the sound of it might not be good enough for
this application.


Bert Menkveld