home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / msdos / programm / 8558 < prev    next >
Encoding:
Text File  |  1992-08-15  |  3.3 KB  |  86 lines
  1. Newsgroups: comp.os.msdos.programmer
  2. Path: sparky!uunet!sun-barr!decwrl!csus.edu!netcom.com!starkey
  3. From: starkey@netcom.com (Sean Starkey)
  4. Subject: Re: RS-port interrupt driven output, help please?
  5. Message-ID: <kg8mysp.starkey@netcom.com>
  6. Date: Sun, 16 Aug 92 08:04:07 GMT
  7. Organization: Netcom - Online Communication Services (408 241-9760 guest)
  8. References: <1992Aug12.074102.10533@jyu.fi>
  9. Lines: 75
  10.  
  11. In article <1992Aug12.074102.10533@jyu.fi> ap@jyu.fi (Patric Aalto) writes:
  12. >Hi!
  13. >
  14. >I am coding a multi-player game that allows the connection between two
  15. >PC machines using a serial connection. I am having a problem with
  16. >interrupted RS-port output, perhaps you can help?
  17.  
  18. Of course...
  19.  
  20. >I have coded many programs to use interrupt-driven input from COM ports,
  21. >but now I decided to try also the interrupt-driven output to speed up
  22. >my game. My routine works quite well a little while, but then the UART
  23. >just simply stops giving 'free-to-transmit' interrupts. I have not yet
  24. >figured out why. Perhaps there is a bug in my code (probably), but I
  25. >would like to know if I am doing something wrong.
  26.  
  27. It's hard to tell without your code.  Are you writing it in assembly or in
  28. C?  I have experienced problems with serial interrupt routines with C.  The
  29. PIC can call an interrupt between your outportb(0x20,0x20) and your IRET (in
  30. the compiled C routine).  This causes the port to "hang" and call no more 
  31. interrupts.  The Interrupt Identify register will not have a 1 in it.  Check
  32. on this...
  33.  
  34. >What should one do if one gets the 'free-to-transmit' interrupt from
  35. >UART but one has nothing to send? 
  36.  
  37. Don't send anything.  :)
  38.  
  39. >Currently I send a null character and mask this interrupt off inside my IRQ 
  40. >handler. Then when I again have something to send I re-enable the interrupt. 
  41. >Is this the correct way to do it? 
  42.  
  43. This would probably work also.  I don't send anything if the output buffer is 
  44. empty.  You can "kickstart" your interrupt sending process by sending a new 
  45. character when you are ready.
  46.  
  47. >What happens if I just ignore the 'free-to-send' interrupts when I have 
  48. >nothing to send? 
  49.  
  50. Nothing...  This is what you should do.
  51.  
  52. >Does the UART generate this interrupt again after a while, or what? 
  53.  
  54. No.  You have to restart the routine by sending a new character.
  55.  
  56. To summarize:
  57.  
  58. INT handler:
  59. Only send when there is a character in your out-going buffer.  Otherwise
  60. send nothing and exit handler.  Must be written in assembly.  Send EOI to PIC
  61. at very end of routine.
  62.  
  63. Send string to port routine:
  64. Check to see if the out-going buffer is empty.  If it is, you need to restart 
  65. the routine by sending the first character in your string.  You must put the
  66. rest of the string (2nd char to end) in the out-going buffer first before
  67. you send the first character.  With fast bauds (>9600) the first character can 
  68. be transmitted before you are finished placing the string in the buffer.
  69.  
  70. If the out-going buffer is not empty, just tack on your string to the end
  71. of your buffer.
  72.  
  73. >Is the interrupt-driven output commonly used, and is it reliable?
  74.  
  75. Sure.  It's the only efficient thing to do when CPU time is very important.
  76.  
  77. If you have any more questions, feel free to send me some Email...
  78.  
  79.  
  80.     Sean Starkey            starkey@netcom.com
  81. Home:    444 Saratoga Ave.    Work:    Process & Cryogenic Services, Inc.
  82.     Apt. 19K            2220 Martin Ave.
  83.     Santa Clara, CA 95050        Santa Clara, CA 95050
  84.     (408) 985-1454            (408) 727-3700
  85.  
  86.