We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I am trying to generate an interrupt when a byte is received via the serial port of an Atmel AT89C51. I am not having much luck. Here is my code:
#include <reg51.h> #include <CTYPE.H> #include <STDIO.H> #include <INTRINS.H> int big_d, count, dogg, i, j; void rcv (void) interrupt 4 { big_d = _getkey(); count++; dogg = 1; RI = 0; } void main(void) { SCON = 0x50; /* SCON: mode 1, 8-bit UART, enable rcvr */ TMOD |= 0x20; /* TMOD: timer 1, mode 2, 8-bit reload */ TH1 = 253; /* TH1: reload value for 9600 baud @ 11.0592MHz */ TR1 = 1; /* TR1: timer 1 run */ TI = 1; /* TI: set TI to send first char of UART */ ES = 1; /* enable serial interrupts */ dogg = 0; count = 0x30; do{ putchar(count); for(j=0; j<255; j++) { for(i=0; i<255; i++) { _nop_(); _nop_(); _nop_(); _nop_(); } } if(dogg == 1) { putchar(count); printf("\n"); putchar(big_d); printf("\n\n\n"); dogg = 0; } }while(1); }
Start by making variables shared between background and interrupt functions volatile. This goes for memory mapped hardware variables too. The call to _getkey() is potentially dangerous too if called by other non-interrupt functions. Just read SBUF and clear RI if set. Remember, either TI or RI will set off your interrupt so you need to check for RI before reading SBUF. - Mark
I meant to say check for RI, read SBUF, and then clear RI. You would never need to read SBUF if RI was not set. - Mark
There are several problems with this program. 1. Global interrupts are not enabled. You must set the EA bit to enable them. 2. You set the TI bit initially to allow transmission of characters, however, this triggers an interrupt. Your interrupt routine does not handle sending characters. 3. You interrupt calls _getkey to retrieve the character from the SBUF. The problem with this is that _getkey clears the TI bit. Your interrupt ALSO clears the TI bit. So, if a serial character is receive between these times, it will be lost. 4. I can only assume that this program is designed to receive serial characters in the interrupt and to transmit serial characters in a polled fashion. This is BAD. A serial I/O example program already exists for the 8051. Take a look at http://www.keil.com/download/docs/intsio.zip.asp for a working example. Jon
Thanks for the info. Do I need to send my characters in my interrupt subroutine as well? I would like to just use the interrupt to receive characters so I can increment a counter everytime I receive a byte. Jake
Do I need to send my characters in my interrupt subroutine as well? Well, technically speaking, no, you don't need to send characters from the interrupt. However, if you enable the serial interrupt, you will receive an interrupt when TI is set or when RI is set. And, you will have to do a lot of work to get around this. The example link that I provided already handles serial transmit and receive in the interrupt, so you don't have to write anything. Jon
"The example link that I provided already handles serial transmit and receive in the interrupt, so you don't have to write anything." Yes, I have used the example code that Jon cited and can confirm that it really does work - just like it says on the tin!
"I would like to just use the interrupt to receive characters so I can increment a counter everytime I receive a byte." Increment the counter only if (RI) Erik
No, polling of only the transmitter is common (and I would argue "good") practice. Since there is no bit for "Transmitter Register Empty" (TRE), you can use the transmitter interrupt to implement TRE. I'd suggest that you consider using JBC when polling TRE to avoid potential design problems in case you ever decide to send characters from the receive interrupt. This might happen if you needed XON XOFF flow control.
_1: JBC TRE, _2 JMP _1 _2:
Do you understand that there is no transmit interrupt vector? The 8051 has a combined serial interrupt vector that either the RI or TI flag or both cause a vector to. You cannot have a serial receive interrupt vector service routine that does not check RI and TI or at least ignore TI. Polling for TI is silly if you want to have some level of hardware muti-tasking. You fill up a packet buffer, set TI and let the UART ISR send out the entire packet without further intervention from the background task or main() loop. Going further, you can ring buffer both the xmit and recv so that getchar pulls from the recv ring and putchar puts into the xmit ring. The serial ISR puts and pulls from the opposite rings. It all works swimmingly. The only caveat is that at very high baud rates, slower 8051's cannot get the next byte into/from the Tx/Rx buffer in time with interrupt overhead. - Mark
The example code cited earlier by Jon implements the ring buffer technique just described by Mark.
Using a transmit interrupt to send data is an unnecessary complication if you want to avoid the extra complexity of a transmit ring buffer. And what are you going to do if your ring buffer is full? Poll the ring buffer? Depending on the application, you might just as well have saved all the timing overhead from filling the ring buffer. As for multi-tasking applications, there is no requirement in multi-tasking that you have more than one task that needs to transmit characters.
Using a transmit interrupt to send data is an unnecessary complication if you want to avoid the extra complexity of a transmit ring buffer. Trivial complexity. And what are you going to do if your ring buffer is full? Poll the ring buffer? Same thing you do when TI is not set. Block. You just block on txRingFull or throw an assert if it shouldn't happen or return a failure and put the task to sleep for another timer tick if mutitasking. Depending on the application, you might just as well have saved all the timing overhead from filling the ring buffer. There's very little over head in having putchar check file scoped bit var called txRingFull. No more than checking if TI is set. I always write my own putchar/getchar. As for multi-tasking applications, there is no requirement in multi-tasking that you have more than one task that needs to transmit characters. Says who? It is a very critical requirement on my current project. All tasks must be able to have printf call level atomicicity to prevent inter char output mangling. It works very well. Regards. - Mark
Depending on the application, you might just as well have saved all the timing overhead from filling the ring buffer. There's very little over head in having putchar check file scoped bit var called txRingFull. No more than checking if TI is set. I always write my own putchar/getchar. Polling requires a delay of 1 character time between writes into SBUF. So, at 2400 baud, when you write into SBUF you must wait for 1/240th seconds. This is FOREVER in a real-time program. Sending a 240-byte string eats up 1 second of processing time (including waiting for the TI bit). Circular buffers are FAST. Writes into the buffer execute in a few instruction cycles. Assuming the buffer is large enough, sending a 240-byte string is practically instantaneous. Using an RTOS, you can implement a DELAY to allow other tasks to run. With polling, the delay will always be 1 character time. However, with a buffered system, the delay will be the total character time represented by the buffer (which can be closer to 0.3-0.4 seconds). The argument that interrupt-driven/buffered serial I/O is complex is moot. If you implement the circular buffer for receive, just copy it and make a few changes for transmit. It's only 3-4 lines of code in and out. But, my primary point is... It's already been written. It's available for you to use. There's no royalty required. You get source code. It's commented. What more could a developer want? :-) Jon P.S. Andrew, I refuse to make a Windows-based configurator for the interrupt-driven serial port example--so don't even ask. :-p
"P.S. Andrew, I refuse to make a Windows-based configurator for the interrupt-driven serial port example--so don't even ask. :-p" I wasn't going to - FastChip does it for me! ;-)
A hybrid design in which characters are received via interrupts and sent using polling is common professional design. The 8051 has the complication that the transmit interrupt cannot be ignored. I've already shown that the polling loop needs only two instructions. Moving the character to SBUF requires one. That is three opcodes. The transmit interrupt can be as simple as:
SERIAL_INTERRUPT: JBC TI, TINTERRUPT <receive interrupt processing> TINTERRUPT: SETB TRE RETI