Printable View
First, I am asking this with no knowledge
In a multi-tasking environment is the OS smart enough not to end a threads time-slice in the middle of writing to the ISA bus?
Of coarse I should say Windows 2000, although I am not sure if it matters (Perhaps something like this is part of a ISO standard)
I believe its usually the other way around. The ISA peripheral is usually smart enough to handle information bursts, and since most device commands are usually issued through things like interrupts (with atomic interrupt handling driver callbacks for messages the other way), things are usually not a problem even with preemptive multitasking.
But I am curious what the reason is for your concern. Is it a particular device you are thinking of?
First thanks Galathaea for taking the time...
Yes, it is a Servo Controller that we have developed. We bought Jungo drivers to get things going fast, which means I am dealing with a black box and really don't know what is going on.
My problem is I have to be able to handle eight of these boards in a single computer with two seperate systems on each board and so was going to have 16 threads sending out commands (running programs in our "programming language") to the boards. In particular two of the threads would be talking to the same board and so I was worried about issues of the threads messing up each others info (at least to the same board)
I would guess, then, that the concern would have to focus on the command set and how the boards know which of its two systems a series of commands is for. If each atomic command does not contain that information, and instead there is some kind of "set active system" command that precedes a burst of commands, then you may have problems in user mode if the driver doesn't handle things properly. I've never used WinDriver, so I don't know what would be needed there, but it may be a fairly straightforward task to directly program a driver that handles the different systems properly by sending only completely specified commands (probably with the assistance of independent buffers for asynchronous communications). It may depend on the communication protocol for your systems, but it probably would not be much of a problem to have the driver send commands for one buffer (if any commands in it) at a time in designated time slices, having it perform the proper setting of the active system before working one each buffer. You don't have to empty a buffer's commands to make a switch (it can be time based), but in this way the driver only works on one system at a time, and there are no threading issues to deal with.