[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: user-written interrupt handlers
Howard Chu writes:
> >> Signal handlers aren't good replacements for interrupts; they take too
> >> much time to be serviced -- maybe a tenth of a second, versus a few
> >> microseconds for an interrupt handler. It would be unusable, for
> >> instance, for the serial interrupts, while it would be quite appropriate
> >> for "Monochrome Detect", say.
> >>
> >> Well, since my only purpose here was to drive my interrupt-driven sound
> >> routines on the Falcon, that was just fine anyway. (Using the monochrome
> >> detect interrupt, fancy that.)
> >
> > btw what is the difference, isn't monochrome detect level 6 too? :)
> >(not that this should be a problem here...)
> >
> > cheers
> > Juergen
>
> Heh. Well, I doubt a monochrome monitor will burn out in a few milliseconds
> of bad video signal, and I know you won't hear a few milliseconds lag in
> swtching the buffer addresses of a DMA-driven sound playback, but you could
> lose several bytes in that amount of time in a serial interrupt handler.
well whether you'll hear it depends on what you play back :) but when a
cat >/dev/audio uses an interrupt handler that takes too long it will
annoy uucico processes running at the same time as well as when its a
serial interrupt handler with this problem...
>
> It's too bad there weren't a couple more DMA channels in the regular ST;
> like one for the 68901 USART. Running that chip in sync mode would let you
> do some really mean high-speed internetworking...
btw anyone using the TT's SCC DMA yet? its too bad mega STe don't have it :)
(and have all this SCC problems too.)
>
> Hm.... Now that I think of it, how could you call post_sig from an rs232
> interrupt handler? You need to get back to receiving the characters of
> the next incoming frame right away, so you need some way of firing off the
> call to post_sig at a lower priority.
hmm. if there is no one else hooked into the same vector `above' you
you could reset the interrupt level from the stack after flipping the
68901 in-service bit and then send the signal and rte... (is post_sig etc
re-entrant(sp?) ?)
> I guess you could set another flag
> to indicate SLIP or PPP end of frame, and have a VBL routine check that...
...and otherwise (interrupt level on stack was >= 5) do this.
>
> On a different topic, I've seen my system freeze up completely from time
> to time, only to return to regular operation some indeterminate amount of
> time later. Anyone else seen this? (I'm still talking MultiTOS here.) No
> keypresses or button clicks register, drop-down menus don't drop, etc.,
> only the mouse-cursor tracks. Awfully disconcerting...
maybe the disk driver? when my quantum disk gets accessed while it
recalibrates i get a few second `sleep' too. but that has nothing to do
with multitos...
> -- Howard
cheers
Juergen
--
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
...ohne Gewehr
PGP public key fingerprint = 8A 18 58 54 03 7B FC 12 1F 8B 63 C7 19 27 CF DA