> You might want to give some more details about your "situation".
> arch? os? and why would you do this? There might be a better solution..
> than locking the hole system for 1/5 second ..
>
> Burkhard
Hi,
I feel a little bit guilty to use this list for my personal problems,
but here it is:
I use one of those (ISA) I/O bards: I write or read from a port and
control a "slow" experiment. More details about the timing:
I can trigger the experiment at any time I like. In fact, this is not
realy a "REAL TIME" experiment. Typically I use the TTimer component
which will "fire" every 10 seconds os so. This is easy!
Once the experiment has been started, then I monitor a voltage from the
same I/O board. Subsequently I plot the measured voltage waveform, save
the numbers on disk, wait for the laser to cool down, and repeat the
measurement. All this house cleaning is done AFTER the experiment is
finished therefore there is no timing problem. The only 'critical'
section is during the acquisition ('monitor') period. In fact this not
too critical either:
After the experiment has been trigered, I want to read one value every
milisecond for a total period of 200 milisecond MAXIMUM. Moreover the
jitter (fluctuation) on the sampling can be as large as 0.1 milisecond.
This is very easy to do. In fact I can just do a loop and monitor the
time counter, and call the driver to do a read as soon as one milisecond
has elapsed! I have done some tests already and this will meet my
requirement! Now the problem...
THE PROBLEM...
The problem: the problem is: even if the timing is not so critical and
the the experiment does not last for long, once it has started then the
processor should not leave and go answer the phone for another
process... I think that most process can be delayed for 200ms but my
acquisition loop should NOT be interrupted while it is doing its thing.
Now, I know that I can use spin-lock while I am in the device driver in
kernel space, but if I do that, then I have to take care of the timing
in the driver as well. It would be the driver who would be responsible
for the whole acquisition sequence.
I would realy prefer to do the timing in my pascal program and call the
driver to read the bytes only. This would be easier to program! and more
flexible (not as fast of course but this is OK).
The only way to acheive what I have just described is to disable the
interrupts or use a "spinlock". Again, I would prefer to do it in my
pascal code. I realy prefer programming Pascal than "kernel C"!
Now I should mention that I am in Mandriva Linux, the kernel is 2.6.12.
I used to do this in Windows 3.1 and DOS. There were no problems. I
would just put $FA$ (CLI) and $FF$ (STI) that would disable and enable
interrupts, but now with Windows XP, those tricks are not possible
anymore! This is what they call 'progress'.
Question:
Can I use "asm CLI end;" and "asm STI end;" in my pascal code?
Is there any trick that I can use to have high priority for a short
period of time (100ms)?
Is there a way to suspend all other processes?
Any idea is welcome.
Thank-you for reading.
Alain Michaud
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
