ridder@elvira.enet.dec.com (Hans Ridder) (02/22/90)
In article <13570022@hpspdra.HP.COM> ric@hpspdra.HP.COM (Ric Peregrino) writes: >In reading the RKM I found a statement saying that one should >not disable interupts for more than 250us. My routine violated >this but it exited gracefully; at least with no other active >processes. Does any one know the underlying reason for the 250us? Mostly just to minimize interrupt response delays. That is, the longer you have interrupts disabled, the longer all interrupts have to wait get their job done. Serial ports start to get data overruns, and data (like MIDI) gets lost, etc. >How about comments on a "cleaner" way of interfacing to MIDI >without losing data on large data dumps (hundreds of kilobytes). Have you tried double buffering? Use two I/O requests, each with a large buffer (say 512 to 2K bytes, or more). SendIO() both of them, and then when one comes back, process it as quickly as possible and then SendIO it again. The idea is to keep at least one I/O request posted to the serial device at any moment, so make each of the buffers large enough so that you can process one before the other fills. If you can't do that, you're guaranteed to lose data at some point. During the dump, keep the processing to a minimum. Just look for the End of Exclusive or other Status byte, and stash the data away. After the dump you can fiddle with the date some more. You may need to raise the priority on the task processing the data (perhaps only during a dump?) to insure that it will run as quickly as possible after the I/O request is returned. >10 bits at 31.25kps (start+8+stop) is 320us. I noticed the >RBF interupt is priority 6. How long does it take between an >interupt to when service routine gets CPU? Gee, I dunno. I seem to remember seeing it mentioned somewhere before. The worst case (which is what you want to program for) depends on how long people disable interrupts, so violating the 250us guideline will make it longer.... >ric@hpspd NOTE: this is starting to look kinda .tech like, so followups directed there.... -hans ======================================================================== Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO