🚀 go-pugleaf

In article <1992Aug12.074102.10533@jyu.fi> ap@jyu.fi (Patric Aalto) writes:
>Hi!
>
>I am coding a multi-player game that allows the connection between two
>PC machines using a serial connection. I am having a problem with
>interrupted RS-port output, perhaps you can help?

Of course...

>I have coded many programs to use interrupt-driven input from COM ports,
>but now I decided to try also the interrupt-driven output to speed up
>my game. My routine works quite well a little while, but then the UART
>just simply stops giving 'free-to-transmit' interrupts. I have not yet
>figured out why. Perhaps there is a bug in my code (probably), but I
>would like to know if I am doing something wrong.

It's hard to tell without your code.  Are you writing it in assembly or in
C?  I have experienced problems with serial interrupt routines with C.  The
PIC can call an interrupt between your outportb(0x20,0x20) and your IRET (in
the compiled C routine).  This causes the port to "hang" and call no more 
interrupts.  The Interrupt Identify register will not have a 1 in it.  Check
on this...

>What should one do if one gets the 'free-to-transmit' interrupt from
>UART but one has nothing to send? 

Don't send anything.  :)

>Currently I send a null character and mask this interrupt off inside my IRQ 
>handler. Then when I again have something to send I re-enable the interrupt. 
>Is this the correct way to do it? 

This would probably work also.  I don't send anything if the output buffer is 
empty.  You can "kickstart" your interrupt sending process by sending a new 
character when you are ready.

>What happens if I just ignore the 'free-to-send' interrupts when I have 
>nothing to send? 

Nothing...  This is what you should do.

>Does the UART generate this interrupt again after a while, or what? 

No.  You have to restart the routine by sending a new character.

To summarize:

INT handler:
Only send when there is a character in your out-going buffer.  Otherwise
send nothing and exit handler.  Must be written in assembly.  Send EOI to PIC
at very end of routine.

Send string to port routine:
Check to see if the out-going buffer is empty.  If it is, you need to restart 
the routine by sending the first character in your string.  You must put the
rest of the string (2nd char to end) in the out-going buffer first before
you send the first character.  With fast bauds (>9600) the first character can 
be transmitted before you are finished placing the string in the buffer.

If the out-going buffer is not empty, just tack on your string to the end
of your buffer.

>Is the interrupt-driven output commonly used, and is it reliable?

Sure.  It's the only efficient thing to do when CPU time is very important.

If you have any more questions, feel free to send me some Email...


	Sean Starkey			starkey@netcom.com
Home:	444 Saratoga Ave.	Work:	Process & Cryogenic Services, Inc.
	Apt. 19K			2220 Martin Ave.
	Santa Clara, CA 95050		Santa Clara, CA 95050
	(408) 985-1454			(408) 727-3700