Prev: Ball of String
Next: How to have access to all tcl procs and vars in a given interpreter
From: Jens Haines on 6 May 2010 10:52
Hello,

I have stumbled upon a strange behavior of the 'clock microseconds'
command. I was trying to do a delay in microseconds (more precise then
the after command). The code is:

proc uDelay {usec} {
# Busy waiting
set end [expr {[clock microseconds] + $usec}]
while {$end > [clock microseconds]} {
# Wait
}
}

It works perfectly on my machine (WinXP SP3 Version 2002 Intel Pentium
4). But on another PC (WinXP SP3 Version 2002 Intel Core 2 Duo) it is
having problems, because the clock microseconds command returns the
value in a millisecond resolution. This means the last three numbers are
always the same (in most cases 000). So the delay is waiting for at
least 1 millisecond.

On both machines the same version of Tcl (8.5.7) is installed.

Does anyone know what this problem is causing? I'm beginning to think
that the CPU is providing a different resolution of the system clock on
both machines. Is there another way to implement some kind of
microsecond delay (must not be that accurate)?

By the way, 'clock clicks -microseconds' is causing the same problem.

Thank you all in advance.

Greetings
Jens Haines
From: Alexandre Ferrieux on 6 May 2010 13:26
On May 6, 4:52 pm, Jens Haines <bubblegumtr...(a)arcor.de> wrote:
> Hello,
>
> I have stumbled upon a strange behavior of the 'clock microseconds'
> command. I was trying to do a delay in microseconds (more precise then
> the after command). The code is:
>
> proc uDelay {usec} {
>         # Busy waiting
>         set end [expr {[clock microseconds] + $usec}]
>         while {$end > [clock microseconds]} {
>                 # Wait
>         }
>
> }
>
> It works perfectly on my machine (WinXP SP3 Version 2002 Intel Pentium
> 4). But on another PC (WinXP SP3 Version 2002 Intel Core 2 Duo) it is
> having problems, because the clock microseconds command returns the
> value in a millisecond resolution. This means the last three numbers are
> always the same (in most cases 000). So the delay is waiting for at
> least 1 millisecond.
>
> On both machines the same version of Tcl (8.5.7) is installed.
>
> Does anyone know what this problem is causing? I'm beginning to think
> that the CPU is providing a different resolution of the system clock on
> both machines. Is there another way to implement some kind of
> microsecond delay (must not be that accurate)?
>
> By the way, 'clock clicks -microseconds' is causing the same problem.

Yes, the underlying resolution of the clock can vary depending on
hardware and OS.
But more important, you won't be able to do submillisecond waits (like
with usleep()) in Tcl since [after] talks in milliseconds.
Moreover, given the speed of execution, even with our exquisite
bytecode compiler, getting down to such fine timings in Tcl sounds
fishy.
Can you explain the context ? Why do you need this resolution ?

-Alex

From: Jens Haines on 7 May 2010 02:39
Am 06.05.2010 19:26, schrieb Alexandre Ferrieux:
> On May 6, 4:52 pm, Jens Haines <bubblegumtr...(a)arcor.de> wrote:
>> Hello,
>>
>> I have stumbled upon a strange behavior of the 'clock microseconds'
>> command. I was trying to do a delay in microseconds (more precise then
>> the after command). The code is:
>>
>> proc uDelay {usec} {
>> # Busy waiting
>> set end [expr {[clock microseconds] + $usec}]
>> while {$end > [clock microseconds]} {
>> # Wait
>> }
>>
>> }
>>
>> It works perfectly on my machine (WinXP SP3 Version 2002 Intel Pentium
>> 4). But on another PC (WinXP SP3 Version 2002 Intel Core 2 Duo) it is
>> having problems, because the clock microseconds command returns the
>> value in a millisecond resolution. This means the last three numbers are
>> always the same (in most cases 000). So the delay is waiting for at
>> least 1 millisecond.
>>
>> On both machines the same version of Tcl (8.5.7) is installed.
>>
>> Does anyone know what this problem is causing? I'm beginning to think
>> that the CPU is providing a different resolution of the system clock on
>> both machines. Is there another way to implement some kind of
>> microsecond delay (must not be that accurate)?
>>
>> By the way, 'clock clicks -microseconds' is causing the same problem.
>
> Yes, the underlying resolution of the clock can vary depending on
> hardware and OS.
> But more important, you won't be able to do submillisecond waits (like
> with usleep()) in Tcl since [after] talks in milliseconds.
> Moreover, given the speed of execution, even with our exquisite
> bytecode compiler, getting down to such fine timings in Tcl sounds
> fishy.
> Can you explain the context ? Why do you need this resolution ?
>
> -Alex
>
Hi Alex,

Thank you for your help. I need some small delay, because I have some
problems with serial communication. Adding a small delay between single
characters makes the program work (but does not solve the underlying
problem). Until I found the real problem I need the program to work. So
the delay must not be exactly in microseconds, but way shorter than
milliseconds. This would slow down communication extremely.

I would like some kind of busy waiting 'for' loop. But I fear it won't
be very hardware independent, and may not work on different kind of PCs.

Greetings Jens

From: Gerald W. Lester on 7 May 2010 08:45
Jens Haines wrote:
>...
> Thank you for your help. I need some small delay, because I have some
> problems with serial communication. Adding a small delay between single
> characters makes the program work (but does not solve the underlying
> problem). Until I found the real problem I need the program to work. So
> the delay must not be exactly in microseconds, but way shorter than
> milliseconds. This would slow down communication extremely.
>
> I would like some kind of busy waiting 'for' loop. But I fear it won't
> be very hardware independent, and may not work on different kind of PCs.

You may need to turn on hardware handshaking or at least monitor it (i.e.
DTR/DSR).


--
+------------------------------------------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Alexandre Ferrieux on 7 May 2010 11:19
On May 7, 8:39 am, Jens Haines <bubblegumtr...(a)arcor.de> wrote:
>
> I need some small delay, because I have some
> problems with serial communication. Adding a small delay between single
> characters makes the program work (but does not solve the underlying
> problem). Until I found the real problem I need the program to work. So
> the delay must not be exactly in microseconds, but way shorter than
> milliseconds. This would slow down communication extremely.
>
> I would like some kind of busy waiting 'for' loop. But I fear it won't
> be very hardware independent, and may not work on different kind of PCs.

OK. If turning flow control on, as suggested by Gerald, is not an
option for you, then you may indeed require usleep().
(Note that it might be that the OS still doesn't honour the request
adequately. It might either over or undershoot :-/)

Now, if usleep() does the job, you can:

- use a generic DLL caller to call into libc to reach usleep():
see Ffidl.
- use a Windows-specific API gateway: TWAPI, to call the
equivalent of usleep() on Windows.
- write an external program that you will pipe your data through
at the appropriate granularity, and who will copy its input to the
serial device, interspersed with the usleep()s.

-Alex



 |  Next  |  Last
Pages: 1 2 3
Prev: Ball of String
Next: How to have access to all tcl procs and vars in a given interpreter