🚀 go-pugleaf

"Charles Hacker" <reply.to@borland.newsgroups> wrote in message 
news:489A25D4.BE924FDC@borland.newsgroups...
> Hi there,
>
> I am updating an old Win98 app, that is used to control a Servo-Motor.
> The old Win98 program utilised machine code, with tempoary disabiling
> interupts, to get an exact as possible 1ms pulse output.
> (i.e. with interupts disabled, Windows did not interfer with pulse
> width).
>
> I am now updating the app (to WinXP using Delphi 5, but also have Delphi
> 7 if needed).
> The 'CLI' and 'STI' disable/enable interrupts (obviously) does NOT work
> in WinXP.
>
> So I am wondering is there any way of 'increasing priority' of the code
> segment (during the 1ms pulse) to limit Windows interrupting the code,
> and thus varing the pulse output width?

I recommend you don't  do this. A small microcontroller on a USB or COM port 
will do the job perfectly and will work on any PC.

While you may get some code to mostly work on one particular PC, this is 
never going to be solid.  A desktop OS like Windows is designed on the basis 
that 1ms is miniscule - which is true in terms of human perception.

Roger Lascelles 

Roger Lascelles wrote:
> 
> I recommend you don't  do this. A small microcontroller on a USB or COM port
> will do the job perfectly and will work on any PC.

I realise this, and for a dedicated system I would certainly build a
seperate controller.

However, this is an "Educational Task", to get students to develop a
"Real-Life" task to control an external device.
(I am a University lecturer, at Griffith University, Qld Australia).

The control will not be perfect, and will not necessarily be the way to
go, but it is a task that is possible for students to do.

But in anycase, I was just wondering if there is any way to 'improve'
the response (though it may never be perfect).

I noticed the 'SetPriorityClass' command, and it has 'Real_Time' Class.
So anyone know if that is a good way to go?
Any better (or other) suggestions?

-- 
Charles Hacker

If your machine has is multiprocessor then there is nothing wrong with doing 
your timing in a separate thread with a very high, even real-time priority. 
If you have only a single processor, then you will have issues with starving 
other threads and apps. But in any case you can adjust the priority of the 
thread to a higher value.

Dan

"Charles Hacker" <reply.to@borland.newsgroups> wrote in message 
news:489A7184.365DE8E@borland.newsgroups...
> Roger Lascelles wrote:
>>
>> I recommend you don't  do this. A small microcontroller on a USB or COM 
>> port
>> will do the job perfectly and will work on any PC.
>
> I realise this, and for a dedicated system I would certainly build a
> seperate controller.
>
> However, this is an "Educational Task", to get students to develop a
> "Real-Life" task to control an external device.
> (I am a University lecturer, at Griffith University, Qld Australia).
>
> The control will not be perfect, and will not necessarily be the way to
> go, but it is a task that is possible for students to do.
>
> But in anycase, I was just wondering if there is any way to 'improve'
> the response (though it may never be perfect).
>
> I noticed the 'SetPriorityClass' command, and it has 'Real_Time' Class.
> So anyone know if that is a good way to go?
> Any better (or other) suggestions?
>
> -- 
> Charles Hacker 

Charles,

> So I am wondering is there any way of 'increasing priority' of the code
> segment (during the 1ms pulse) to limit Windows interrupting the code,
> and thus varing the pulse output width?

This is a good place to start...

http://msdn.microsoft.com/en-us/library/ms685100.aspx


   pc := GetPriorityClass( GetCurrentProcess );
   try
     tp := GetThreadPriority( GetCurrentThread );
     try
       SetPriorityClass( GetCurrentProcess, HIGH_PRIORITY_CLASS );
       SetThreadPriority( GetCurrentThread, THREAD_PRIORITY_HIGHEST );
       // do your thing here
     finally
       SetThreadPriority( GetCurrentThread, tp );
     end;
   finally
     SetPriorityClass( GetCurrentProcess, pc );
   end;


Good luck, Brian

Nobody wrote:

> SetThreadPriority(GetCurrentThread, THREAD_PRIORITY_HIGHEST);

PRIORITY_HIGHEST had no good effect for me (OS steals the time).
PRIORITY_TIME_CRITICAL was much better (of course for short time
intervals).
-- 
Alex

"Charles Hacker" <reply.to@borland.newsgroups> wrote in message 
news:489A25D4.BE924FDC@borland.newsgroups...
> Hi there,
>
> I am updating an old Win98 app, that is used to control a Servo-Motor.
> The old Win98 program utilised machine code, with tempoary disabiling
> interupts, to get an exact as possible 1ms pulse output.
> (i.e. with interupts disabled, Windows did not interfer with pulse
> width).
>
> I am now updating the app (to WinXP using Delphi 5, but also have Delphi
> 7 if needed).
> The 'CLI' and 'STI' disable/enable interrupts (obviously) does NOT work
> in WinXP.
>
> So I am wondering is there any way of 'increasing priority' of the code
> segment (during the 1ms pulse) to limit Windows interrupting the code,
> and thus varing the pulse output width?
>

There are some problems with this.  A page-fault interrupt, for example, 
must run to allow the required code to be loaded from disk.  To get round 
this, you would need to make the code pages/s that contain the high-priority 
code as non-paged.  You really need a driver to attempt this sort of stuff 
on Windows and, even then, it is likely to be interrupted by higher-priority 
drivers.  IMHO, you were lucky to get your stuff to work on W98, never mind 
'real' OS like W2k/XP.

As others have said - Windows is not a real-time OS.

Rgds,
Martin