Ok, I have to join the windows world ...

I've been in embedded/real-time for a long time.  I've put-off having
to learn the Microsquash programming world for a while.  I now an
submitting ....  In any embedded O/S or kernel, the following is
easy...

I've written utilities using VC++ (6.0) on and off, mainly repackaging
binaries for CRC's, Hex/S formats etc...  I'm running on XP pro.

I need to make a "continuous" calculation, say 10 -> 100 times a
second.

The calculation is not compute intensive.

I want to "sleep" the process/task/thread for the appropriate time to
achieve the
required frequency...  I do not want to do busy-waiting in a loop, I
have to free up the
CPU bandwidth for other stuff...

I know Windows is NOT real-time or deterministic by any stretch of the
imagination...
It's not required for the simulation I'm doing...

so .... the pattern is simply for now, compute; print; sleep ->
eventually I'm going to pass this compute result to another "process"
running on the CPU -> another cosole instance is preferred.

This is a CONSOLE app...   There appears to be a POSIX interface that
may allow me to do what I need, is there any other API I can use that
will allow me to remain in a console APP?
or do I have to submit myself to re-learning the windows proc loop to
use windows API's for this???  Hmmm, just remembered a book on
windows/NT threading I think...

BUT, I come here first for the wizened sages who have gone thru
learning window "re-terminology" for all we learned in school (the way
back machine here... Windows was still 16 bit when I was in school....)

TIA,
-Dan

> I want to "sleep" the process/task/thread for the appropriate time to
> achieve the
> required frequency...  I do not want to do busy-waiting in a loop, I
> have to free up the

Why not write it as a cygwin app, and not deal with any Windows APIs at
all? :)

packer44@hotmail.com wrote:

> I've been in embedded/real-time for a long time.  I've put-off having
> to learn the Microsquash programming world for a while.  I now an
> submitting ....  In any embedded O/S or kernel, the following is
> easy...
> 

Why not use Linux instead. It's dead easy.

IAn

packer44@hotmail.com wrote:
> I've been in embedded/real-time for a long time.  I've put-off having
> to learn the Microsquash programming world for a while.  I now an
> submitting ....  In any embedded O/S or kernel, the following is
> easy...

snip

> I need to make a "continuous" calculation, say 10 -> 100 times a
> second.
>
> The calculation is not compute intensive.
>
> I want to "sleep" the process/task/thread for the appropriate time to
> achieve the
> required frequency...  I do not want to do busy-waiting in a loop, I
> have to free up the
> CPU bandwidth for other stuff...

If it is that simple you can use the Sleep() function that takes the
number of milliseconds as a parameter.

This is probably not the right ng for this kind of questions, unless
you want people to express their sympathy ;)

Thanks gents,
  I came here because I AM an embedded developer...  I used SleepEx()
...

Put this one to bed...

Thanks,
-D

On 18 Nov 2005 09:34:10 -0800, packer44@hotmail.com wrote:

>so .... the pattern is simply for now, compute; print; sleep ->
>eventually I'm going to pass this compute result to another "process"
>running on the CPU -> another cosole instance is preferred.
>
>This is a CONSOLE app...   There appears to be a POSIX interface that
>may allow me to do what I need, is there any other API I can use that
>will allow me to remain in a console APP?
>or do I have to submit myself to re-learning the windows proc loop to
>use windows API's for this???  Hmmm, just remembered a book on
>windows/NT threading I think...

No need for a message loop.

In a console application, at the end of your calculations, simply call
the WaitForMultipleObjects with no handles but with a suitable timeout
parameter. While the timeout parameter is in milliseconds, the actual
resolution is 10 ms (or 15.625 ms for multiprocessor kernels).

Paul

On 18 Nov 2005 09:34:10 -0800 in comp.arch.embedded,
packer44@hotmail.com wrote:

>I've been in embedded/real-time for a long time.  I've put-off having
>to learn the Microsquash programming world for a while.  I now an
>submitting ....  In any embedded O/S or kernel, the following is
>easy...

I have in the past compared Windoze programming to old text-based
adventure games -- you don't have everything you need, but if you dig
around a little, find the important bits, and invoke the magic
incantation, you can make what you need.

>
>I've written utilities using VC++ (6.0) on and off, mainly repackaging
>binaries for CRC's, Hex/S formats etc...  I'm running on XP pro.
>
>I need to make a "continuous" calculation, say 10 -> 100 times a
>second.
>
>The calculation is not compute intensive.
>
>I want to "sleep" the process/task/thread for the appropriate time to
>achieve the
>required frequency...  I do not want to do busy-waiting in a loop, I
>have to free up the
>CPU bandwidth for other stuff...

Sleep(10) should sleep for close to 10 ms for you.  About 10 ms
granularity.  Certainly not deterministic.

>
>I know Windows is NOT real-time or deterministic by any stretch of the
>imagination...
>It's not required for the simulation I'm doing...
>
>so .... the pattern is simply for now, compute; print; sleep ->
>eventually I'm going to pass this compute result to another "process"
>running on the CPU -> another cosole instance is preferred.
>
>This is a CONSOLE app...   There appears to be a POSIX interface that
>may allow me to do what I need, is there any other API I can use that
>will allow me to remain in a console APP?
>or do I have to submit myself to re-learning the windows proc loop to
>use windows API's for this???  Hmmm, just remembered a book on
>windows/NT threading I think...

Look up memory-mapped shared files.  They're not hard to use.  At a
PPOE, I created a bunch of inter-process communications primitives
based on them.  Things like a deque, where the consumer could
optionally block until data became available and the producer could
optionally block until the queued data was extracted.  It's the
blocking stuff that can get strange to someone used to RTOS and
multitasking kernels...

>
>BUT, I come here first for the wizened sages who have gone thru
>learning window "re-terminology" for all we learned in school (the way
>back machine here... Windows was still 16 bit when I was in school....)

Bill Gates thought 640k oughtta be enough for anybody back when I was
in school.

Regards,
                                        -=Dave

-- 
Change is inevitable, progress is not.

Paul Keinanen wrote:
> In a console application, at the end of your calculations, simply call
> the WaitForMultipleObjects with no handles but with a suitable timeout
> parameter. While the timeout parameter is in milliseconds, the actual
> resolution is 10 ms (or 15.625 ms for multiprocessor kernels).

While you may be correct for normal thread priority, my experience
shows 1ms granularity in RT thread.

Also one can achieve very low latencies in RT thread priority. I have
implemented a software LIN slave nodes few years back for my employer
by receiving buffer overrun (SOF) and responding back at 9600. There
was 6 such threads running on 6 UARTS (FIFOs off) each emulating 4
nodes. The response latency was about 200us and when putting entire
system under 100% stress (launching few memory and processor hungry
applications at the same time), oscilloscope shown the latency increase
by another 100us.

For the master units that counted as "real-time" response.

Of course I am talking about USER mode. That means about 50us expense
with each call to a driver stack on P4 / 2GHz

On 18 Nov 2005 21:11:28 -0800, "rziak" <news@ziak.com> wrote:

>Paul Keinanen wrote:
>> In a console application, at the end of your calculations, simply call
>> the WaitForMultipleObjects with no handles but with a suitable timeout
>> parameter. While the timeout parameter is in milliseconds, the actual
>> resolution is 10 ms (or 15.625 ms for multiprocessor kernels).
>
>While you may be correct for normal thread priority, my experience
>shows 1ms granularity in RT thread.

I haven't seen this documented anywhere, but it appears (at least on
NT4) that if _any_ process calls timeBeginPeriod with 1 ms resolution,
the WaitForSingle/MultipleObject and Sleep indeed works with 1 ms
granularity on all processes.

>Also one can achieve very low latencies in RT thread priority. I have
>implemented a software LIN slave nodes few years back for my employer
>by receiving buffer overrun (SOF) and responding back at 9600. There
>was 6 such threads running on 6 UARTS (FIFOs off) each emulating 4
>nodes. The response latency was about 200us and when putting entire
>system under 100% stress (launching few memory and processor hungry
>applications at the same time), oscilloscope shown the latency increase
>by another 100us.

I have done some thread wakeup tests with 100-500 MHz processors and
the jitter appears to be within a millisecond or two.

However, did you measure the worst case latencies ? These can be quite
hard to see on an oscilloscope.

In my experiments, I observed some rare 10-20 ms peaks at time to time
when there was a lot of other activity on the system. 

My colleague was using a system on which I had my cycle time
monitoring running. He was quite amazed, when the following day when I
told him when he had taken a break for smoking outside, by examining
the distribution of the cycle times :-).

Paul

packer44@hotmail.com wrote:

> I want to "sleep" the process/task/thread for the appropriate time to
> achieve the
> required frequency...  I do not want to do busy-waiting in a loop, I
> have to free up the
> CPU bandwidth for other stuff...

You can use Sleep() or CreateWaitableTimer + WaitForSingleObject. Take a 
look at MSDN for more help there.

ttyl,

--buddy