Mail Archives: djgpp/1997/03/12/09:12:23
On Wed, 12 Mar 1997, Christoph Kukulies wrote:
> One of these functions is 'steer steppers into zero position against the
> bumper switches'. When the switches are sensed, the motion stops
> and the steppers are steered a bit outwards so that they leave the
> switch inactive again. The switch state which is passed back in the
> said memory buffer should be zero then. (This all happens while the program
> is in their driver). Now and then it happens though, that a
> switch state of 0x07 (every axis - xyz - occupies a bit) is passed
> back.
If I understand correctly, the real-mode driver writes the switch
state into the buffer whose address you pass it (in your case, the
DJGPP transfer buffer), right? If so, then this doesn't seem like a
cache-related issue at all: once that address is written, it is marked
dirty in the cache and either written to memory right away, or (if
your cache has write-back operation enabled) will cause the CPU to
supply the data from the cache to any other access to that address.
However, there's one caveat that you should be aware of when using the
transfer buffer. If you call any library functions between the moment
the driver puts the switch state into __tb and the moment you read the
state with `_farpeekl', you should make sure that those library
functions don't themselves use the transfer buffer. If they do, they
will overwrite its contents. For example, if you use file I/O
functions or `printf' before fetching the data from __tb, you will see
such problems.
Other than that, I'd indeed suspect EMM or some other oddity with the
driver.
- Raw text -