From: Marko Mäkelä (marko.makela_at_hut.fi)
Date: 2004-05-13 09:14:00
On Thu, May 13, 2004 at 08:35:34AM +0200, Spiro Trikaliotis wrote:
> Upon reception of an ATN, each peripherel sets the DATA line almost
> immediately to tell the controller that it needs some more time. In
> fact, in the 1541, this is done with an XOR gate, so there is no need
> for the processor to process the ATN itself.
True, but the timeouts in the protocol allow a software-based response.
Womo measured that my C2N232 solution has a delay of a few microseconds,
even though it responds to ATN with an interrupt.
> As soon as the peripheral is ready, it unsets the DATA line. When the
> last one has done so, the control recognizes this and is able to put the
> appropriate command (LISTEN, TALK, ...) on the serial bus.
True. This is where flow control can be implemented: delay raising DATA
until the RS-232 transmission buffer is ready to accept data.
> On the other hand, for the controller, it is necessary to detect the
> DATA line to see a "ready to receive". The controller has to check that
> line and react on it with a latency not more than 100 us. So, if you
> want to implement a controller, the DATA line needs an interrupt.
Why? A microcontroller can easily do this with polling. At 38400 bps,
RS-232 receive interrupts can arrive every 260 µs. I've disabled the
RS-232 receive interrupts in some places in my serial bus code.
> For more details (and source code) for this, have a look at the cbm4linux [1]
> project. That's the reason why a XE1541 cannot be used with cbm4linux,
> but a new XM1541 was introduced.
On a multitasking computer, it's a completely different matter, as you can't
tie the processor for long periods of time. There, it's better to use
interrupts (or delegate the serial bus handling to an external microcontroller,
like the C2N232 with the serial bus modification).
Marko
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.