On 02/26/2011 12:04 AM, Bo Berglund wrote:
> I would design a PCB with a MCU on board...
Yep. But this PCB would need to do* all *the realtime stuff, store the
results in a kind of FiFo and communicate them towards the PC via a
serial interface or USB (doing USB is easy with an appropriate PIC24).
On 02/26/2011 12:04 AM, Bo Berglund wrote:
> That is why I said that I would design a PCB with a MCU on board and
> write a program to fix the synching problem that way. A PIC processor
> with an UART and a few I/O pins to read the PPS pulse and NMEA data
> from the GPS 18x LVC is what is needed.
>
On Sun, Feb 27, 2011 at 06:06:13PM +0100, Sven Barth wrote:
>
> I don't know whether you stuff the GetTickCount API call under
> "Multimedia API", but the GetTickCount implementation for Windows uses
> just that.
>
> See this snippet from lcl/lclintf.pas:
Ah. it is in lazarus. (I had in mind i
On Sun, Feb 27, 2011 at 06:51:21PM +0200, Graeme Geldenhuys wrote:
> The current linux version of GetTickCount is
> very rudimentary.
Possibly. But IMHO it is a windows knock-off function, and is defined as it
is defined to keep code more or less running. If it drags in heaps of
requirements, its
On 27.02.2011 18:24, Graeme Geldenhuys wrote:
On 27 February 2011 19:06, Sven Barth<> wrote:
I don't know whether you stuff the GetTickCount API call under "Multimedia
API", but the GetTickCount implementation for Windows uses just that.
My apologies then. As I mentioned I don't have a c
On 27 February 2011 19:06, Sven Barth <> wrote:
>
> I don't know whether you stuff the GetTickCount API call under "Multimedia
> API", but the GetTickCount implementation for Windows uses just that.
My apologies then. As I mentioned I don't have a computer with FPC
source code in front of me.
On 27.02.2011 17:51, Graeme Geldenhuys wrote:
On 26 February 2011 20:43, Marco van de Voort wrote:
(1) this discussion is about a gettickcount implementation, but I'm not
entirely sure why this is needed so badly.
I am by no means a libc expert, though I have tried myself to find a
more fine
On 27 February 2011 18:51, Graeme Geldenhuys wrote:
> So couldn't the GetTickCount for linux use the improved function
I forgot to add...This will at least gives us improved timing under
Linux, and still allow use to use the relatively cross-platform
GetTickCount() call between the most popular p
On 26 February 2011 20:43, Marco van de Voort wrote:
>
> (1) this discussion is about a gettickcount implementation, but I'm not
> entirely sure why this is needed so badly.
I am by no means a libc expert, though I have tried myself to find a
more fine-grained timing call under Linux. Windows (an
On 26/02/2011 18:43, Marco van de Voort wrote:
(1) this discussion is about a gettickcount implementation, but I'm not
entirely sure why this is needed so badly.
When you are doing something soft real time it is a must.
Things like:
- Is my image processing algorithms under the 40ms allowed t
Al 26/02/11 19:43, En/na Marco van de Voort ha escrit:
>
> (1) this discussion is about a gettickcount implementation, but I'm not
> entirely sure why this is needed so badly.
I use it extensively to keep track of time and
I can currently live with the workaround DWord(Trunc(Now * 24 * 60 * 60 *
On Sat, Feb 26, 2011 at 07:19:52PM +0100, Luca Olivetti wrote:
> >
> > Unit libc doesn't count since it is only for certain legacy reasons, and
> > Lazarus should NOT use it.
>
> I know that, I know the reasons, and I agree.
> But those are posix functions, so they could be defined somewhere else
Al 26/02/11 17:58, En/na Marco van de Voort ha escrit:
> On Sat, Feb 26, 2011 at 12:46:07PM +0100, Luca Olivetti wrote:
BTW: in which unit are clock_gettime and related constants defined?
>
> The answer should be : in no portable unit.
>
> Unit libc doesn't count since it is only for certain
On Sat, Feb 26, 2011 at 12:46:07PM +0100, Luca Olivetti wrote:
> >> BTW: in which unit are clock_gettime and related constants defined?
The answer should be : in no portable unit.
Unit libc doesn't count since it is only for certain legacy reasons, and
Lazarus should NOT use it.
--
_
Al 24/02/11 08:22, En/na Graeme Geldenhuys ha escrit:
> Op 2011-02-23 18:56, Luca Olivetti het geskryf:
>> BTW: in which unit are clock_gettime and related constants defined?
>
> libc (FPC wrapper to the libc library)
>
> ...more specifically...
>
> packages/libc/src/timeh.inc
Two things:
1)
On Thu, 24 Feb 2011 13:17:25 +0100, Michael Schnell
wrote:
>On 02/24/2011 12:58 PM, Bo Berglund wrote:
>>
>> It seems like I am out of luck doing this with readily available
>> hardware such as PC:s, notebooks or embedded linux cards running
>> software
>IMHO, the _Hardware_ is not the problem at
Am 25.02.2011 13:11, schrieb Graeme Geldenhuys:
Op 2011-02-25 13:45, Sven Barth het geskryf:
libc (FPC wrapper to the libc library)
...more specifically...
packages/libc/src/timeh.inc
No, no, no and again no.
Don't suggest anyone to use the unit libc. It's only there for
compatibilty for
Op 2011-02-25 13:45, Sven Barth het geskryf:
>>
>> libc (FPC wrapper to the libc library)
>>
>> ...more specifically...
>>
>> packages/libc/src/timeh.inc
>
> No, no, no and again no.
>
> Don't suggest anyone to use the unit libc. It's only there for
> compatibilty for Kylix and works only on i3
Am 24.02.2011 08:22, schrieb Graeme Geldenhuys:
Op 2011-02-23 18:56, Luca Olivetti het geskryf:
BTW: in which unit are clock_gettime and related constants defined?
libc (FPC wrapper to the libc library)
...more specifically...
packages/libc/src/timeh.inc
No, no, no and again no.
Don't s
On 2/24/2011 07:17, Michael Schnell wrote:
On 02/24/2011 12:58 PM, Bo Berglund wrote:
It seems like I am out of luck doing this with readily available
hardware such as PC:s, notebooks or embedded linux cards running
software
IMHO, the _Hardware_ is not the problem at all, but the OS is.
agre
On 02/24/2011 12:58 PM, Bo Berglund wrote:
It seems like I am out of luck doing this with readily available
hardware such as PC:s, notebooks or embedded linux cards running
software
IMHO, the _Hardware_ is not the problem at all, but the OS is. You need
to use a decent realtime OS (or none) to
On Thu, 24 Feb 2011 09:44:55 +0100, Michael Schnell
wrote:
>I really don't understand why you invest so much effort in the fruitless
>try to deal with mSec accuracy in a Linux user land program.
>
Maybe, but you don't know what I am after, right?
I need to synchronize two separated units such
I really don't understand why you invest so much effort in the fruitless
try to deal with mSec accuracy in a Linux user land program.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman
Op 2011-02-23 18:56, Luca Olivetti het geskryf:
> BTW: in which unit are clock_gettime and related constants defined?
libc (FPC wrapper to the libc library)
...more specifically...
packages/libc/src/timeh.inc
I wonder if we can't use Petr's GetTickCount() implementation as default
for FPC+Li
On 24/02/2011 5:32 AM, Bo Berglund wrote:
On Wed, 23 Feb 2011 10:20:19 +0100, Sven Barth
wrote:
Yeah, but my efforts are not successful in using a USB connected GPS
sensor and trying to get accuracy from the telegrams sent by it. I
think much of the time wobble I see is caused by USB latency
On Wed, 23 Feb 2011 10:20:19 +0100, Sven Barth
wrote:
>Am 23.02.2011 10:04, schrieb Graeme Geldenhuys:
>> Op 2011-02-23 10:50, Sven Barth het geskryf:
>>>
>>> I don't know of a suitable hardware though (I haven't yet done anything
>>> related to such accurate timings).
>>
>> I have heard of users
On Wed, 23 Feb 2011 09:50:26 +0100, Sven Barth
wrote:
>Am 22.02.2011 16:02, schrieb Bo Berglund:
>> Have to look elsewhere.
>
>The only really usable solution might be to attach an external time
>source to your PC and use that time signal.
>
>I don't know of a suitable hardware though (I haven't
Al 23/02/11 13:17, En/na Petr Kristan ha escrit:
> On Sun, Feb 20, 2011 at 02:46:34PM +0100, Luca Olivetti wrote:
>> Al 20/02/11 12:42, En/na Bo Berglund ha escrit:
>>
>>> I wonder if GetTickCount will get me a better value to milliseconds
>>> than Now()?
>>
>> Not under linux:
>>
>> function GetTi
On Sun, Feb 20, 2011 at 02:46:34PM +0100, Luca Olivetti wrote:
> Al 20/02/11 12:42, En/na Bo Berglund ha escrit:
>
> > I wonder if GetTickCount will get me a better value to milliseconds
> > than Now()?
>
> Not under linux:
>
> function GetTickCount: DWord;
> begin
> Result := DWord(Trunc(Now
Am 23.02.2011 10:04, schrieb Graeme Geldenhuys:
Op 2011-02-23 10:50, Sven Barth het geskryf:
I don't know of a suitable hardware though (I haven't yet done anything
related to such accurate timings).
I have heard of users using something as simple as GPS devices. What
accuracy that gives, I a
On 22/02/2011 15:02, Bo Berglund wrote:
>
> Thanks,
> I have now tested it (on Windows) and found that although the
> QueryPerformanceCounter gives more resolution it is also drifting
> compared to real time (77 ms in 30 s) making it rather unusable...
> It would be good for a highres timer but n
Op 2011-02-23 10:50, Sven Barth het geskryf:
>
> I don't know of a suitable hardware though (I haven't yet done anything
> related to such accurate timings).
I have heard of users using something as simple as GPS devices. What
accuracy that gives, I am not sure - but I do know each GPS syncs with
Am 22.02.2011 16:02, schrieb Bo Berglund:
Have to look elsewhere.
The only really usable solution might be to attach an external time
source to your PC and use that time signal.
I don't know of a suitable hardware though (I haven't yet done anything
related to such accurate timings).
Rega
On Tue, 22 Feb 2011 14:05:33 +0100 (CET), Michael Van Canneyt
wrote:
>> After googling a bit I have come up with the following, which is a
>> variation of a delay function that I created years ago in Delphi to
>> enable me to output pulses that are timed to milliseconds.
>> The delay is now conve
On top of this you can add some "realtime Patches" to Linux to reduce
the latency (while degrading the overall performance).
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo
Op 2011-02-22 15:08, Michael Schnell het geskryf:
> is such a function would work perfectly, the OS might delay the program
> for hundreds of mSecs until the value is used.
Unless [under Linux], you run that application as root, and give it
real-time (or equivalent) priority. That should at least
On 02/22/2011 01:55 PM, Bo Berglund wrote:
That is logical, since TDateTime only is accurate to millisecond precision.
While TDateTime might provide mSec resolution, the functions that
generate such a value are _much_ less exact in a user land program. Even
is such a function would work perfe
On Tue, 22 Feb 2011, Bo Berglund wrote:
On Tue, 22 Feb 2011 08:50:33 +0100 (CET), Michael Van Canneyt
wrote:
I should have added that instead of a sawtooth like noise component
using Frac(Now()) * 24*3600 to get the second since midnight gives
random noise in the seconds values of about 3-4
On Tue, 22 Feb 2011 08:50:33 +0100 (CET), Michael Van Canneyt
wrote:
>> I should have added that instead of a sawtooth like noise component
>> using Frac(Now()) * 24*3600 to get the second since midnight gives
>> random noise in the seconds values of about 3-4 ms.
>> Another observation is that t
2011/2/22 Michael Schnell :
> On 02/22/2011 06:56 AM, Bo Berglund wrote:
>>
>> I should have added that instead of a sawtooth like noise component
>> using Frac(Now()) * 24*3600 to get the second since midnight gives
>> random noise in the seconds values of about 3-4 ms.
>
> No wonder. In a non-rea
On 02/22/2011 06:56 AM, Bo Berglund wrote:
I should have added that instead of a sawtooth like noise component
using Frac(Now()) * 24*3600 to get the second since midnight gives
random noise in the seconds values of about 3-4 ms.
No wonder. In a non-realtime OS like Windows of Linux, you can't cr
On Tue, 22 Feb 2011, Bo Berglund wrote:
On Mon, 21 Feb 2011 07:23:54 +0100, Bo Berglund
wrote:
When I run a test against a fairly accurate GPS time source I see that
there is an uncertainty of about 16 ms in the time given such that if
GetTickCount is executed at exactly 1 second intervals
On Mon, 21 Feb 2011 07:23:54 +0100, Bo Berglund
wrote:
>When I run a test against a fairly accurate GPS time source I see that
>there is an uncertainty of about 16 ms in the time given such that if
>GetTickCount is executed at exactly 1 second intervals the last two
>digits of the value is not th
On 21.02.2011 04:23, waldo kitty wrote:
On 2/20/2011 16:04, Bo Berglund wrote:
Now I have tested both the GetTickCount and Now() methods.
I have synched my tests against a GPS receiver to get an accurate
reference.
Turns out that GetTickCount has a sawtooth-like overlaid timing noise
signal whi
Al 21/02/11 07:23, En/na Bo Berglund ha escrit:
> The posted variation is apparently a Linux platform compatible version
> that returns a millisecond value the same way as the Windows version
> does, since there is no Windows GetTickCount API call in Linux.
The problem with the current implementa
Felipe,
Please stop recommending this component.
EpikTimer is not a well-written component.
It's precision is not better than Now() unless you're on i386, Windows.
For all other platforms it's useless and introduces uncalled-for dependencies.
Michael.
On Mon, 21 Feb 2011, Felipe Monteiro de C
http://wiki.lazarus.freepascal.org/EpikTimer
--
Felipe Monteiro de Carvalho
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Hello Lazarus-List,
Monday, February 21, 2011, 7:23:54 AM, you wrote:
BB> When I run a test against a fairly accurate GPS time source I see that
BB> there is an uncertainty of about 16 ms in the time given such that if
BB> GetTickCount is executed at exactly 1 second intervals the last two
BB> di
On Sun, 20 Feb 2011 22:16:25 -0500, waldo kitty
wrote:
>On 2/20/2011 08:46, Luca Olivetti wrote:
>> Al 20/02/11 12:42, En/na Bo Berglund ha escrit:
>>
>>> I wonder if GetTickCount will get me a better value to milliseconds
>>> than Now()?
>>
>> Not under linux:
>>
>> function GetTickCount: DWord;
On 2/20/2011 16:04, Bo Berglund wrote:
Now I have tested both the GetTickCount and Now() methods.
I have synched my tests against a GPS receiver to get an accurate
reference.
Turns out that GetTickCount has a sawtooth-like overlaid timing noise
signal which is about 15 ms.
But using Now() I don
On 2/20/2011 08:46, Luca Olivetti wrote:
Al 20/02/11 12:42, En/na Bo Berglund ha escrit:
I wonder if GetTickCount will get me a better value to milliseconds
than Now()?
Not under linux:
function GetTickCount: DWord;
begin
Result := DWord(Trunc(Now * 24 * 60 * 60 * 1000));
end;
i gotta a
On Sun, 20 Feb 2011 20:07:32 +0200, Graeme Geldenhuys
wrote:
>On Sun, 2011-02-20 at 12:42 +0100, Bo Berglund wrote:
>
>> In fact I am interested mainly in the time *difference* between
>> successive measured data points.
>
>You can try EpicTimer too. It's only a single unit, easy to use,
>support
On Sun, 2011-02-20 at 12:42 +0100, Bo Berglund wrote:
> In fact I am interested mainly in the time *difference* between
> successive measured data points.
You can try EpicTimer too. It's only a single unit, easy to use,
supports multiple timers, stopwatch and various display modes. It's not
very
Al 20/02/11 12:42, En/na Bo Berglund ha escrit:
> I wonder if GetTickCount will get me a better value to milliseconds
> than Now()?
Not under linux:
function GetTickCount: DWord;
begin
Result := DWord(Trunc(Now * 24 * 60 * 60 * 1000));
end;
Bye
--
Luca Olivetti
Wetron Automatización S.A
On Sun, 20 Feb 2011 11:58:59 +0200, ik wrote:
>There is a known problem of windows vs linux with timestamps.
>Windows for some reason is less accurate and change the clock every usage of
>Windows, while in Linux it's considered more accurate. I'm saying it from a
>bad experience so far.
>
>Second
There is a known problem of windows vs linux with timestamps.
Windows for some reason is less accurate and change the clock every usage of
Windows, while in Linux it's considered more accurate. I'm saying it from a
bad experience so far.
Secondly. you always have to know where the clock is set for
In my data acquisition program I also need to timestamp the retrieved
data from the instrument. I want this to be as accurate as possible
and also portable Windows->Linux->Embedded Linux
In Delphi/FPC there are two ways to get a time value that I know of:
GetTickCount gives a value that is in mil
57 matches
Mail list logo
