High Priority Code Segment
Charles Hacker
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?
--
Charles Hacker
Roger Lascelles
news:489A25D4...@borland.newsgroups...
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
Charles Hacker
>
> 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
DJSox
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" <repl...@borland.newsgroups> wrote in message
news:489A7184...@borland.newsgroups...
Nobody
> 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
AlexB
> 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
Martin James
"Charles Hacker" <repl...@borland.newsgroups> wrote in message
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