jlblom at neuroweave.nl
Wed May 31 00:19:20 CEST 2006
Marc Santhoff wrote:
>Am Dienstag, den 30.05.2006, 16:24 -0400 schrieb Alain Michaud:
>>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:
>IMO this is your main problem: the rotten old board. ;)
>To get away from "dangerous programming" I personally would solve it by
>using an I/O-Board that drives Interrupts on the host computer. Even
>cheap ones are able to make 1 ms timing.
>Another hardware based solution would be to connect a microcomputer
>board inbetween the computer and the sensor stuff. A little AVR or
>similar can easily programmed to get one trigger command and then read
>in values at 1ms timing for 200ms. Afterwards it can transfer data to
>> 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.
>If the measure is extremely critical, why does the computer have other
>tasks to do? Can't you use a dedicated machine for the measurement?
>fpc-pascal maillist - fpc-pascal at lists.freepascal.org
I think your problem id not hardware but software. Simply, Windows is
not a real-time operating system. You need an operating system (like
RTOS) that can set process priorities. Giving your process the highest
priority guarantees that no other process van interrupt your process.
There are some Linux flavors that also have priority scheduling but I
don't know if vanilla Linux has these capabilities.
In another era I used to supervise (and work at) the development of
real-time data-access systems and we did a lot with tricking plain DOS
to achieve our goal. Windows is too badly programmed to even remotely
achieve such a goal.
More information about the fpc-pascal