Can't get TI flag to be set when writing into SBUF

while(1)
{
   SBUF = 'Y';
};

You need to choose whether to use interrupts or a polled approach. You are trying to mix the two - this will only make your life difficult.

Hi Stefan, I would like to use the interrupt based approach. Could you please post the same code in the way you suggest me to write. It would help a lot. Thanks.

Rohit,

If you're trying to use an interrupt-based methodology just to prove to yourself that you can send a string of 'H's or 'Y's out the port, just change your code as follows:

Make the ISR look like this:

void serial_int (void) interrupt 4 {
  if (RI)
    RI = 0;
  if (TI) {
    TI = 0;
    SBUF = 'Y';
  }
}

while (1){}

"I would like to use the interrupt based approach. Could you please post the same code in the way you suggest me to write."

If I did that I'd be posting code nearly identical to Keil's example. If you are having trouble understanding the code in their example just post any questions you might have.

If you want to use interrupt driven serial comms in your project you may as well bite the bullet and use a full implementation. The code is there, it's free and it (probably) works. Once you have compiled it into your project you can forget about SBUF, TI and RI, all you need to do is use the standard 'C' library functions.

Thanks Daniel for the code snippet. If I am to write to SBUF in the isr then I am facing an issue of reentrancy. My main interest is to say, write "Hello World" and I would like to use some_func(char *str) in the main(void) so I would give something like some_func("Hello World") in the main and our serial ISR is exected to print it and then wait for the next string whenever I send through some_func. How should do that?

Rohit,

You are incorrect about the reentrancy problem. You need to learn a bit more about the way the 8051's interrupt system works. While you are servicing an interrupt, you WILL not be interrupted again by the same source. In other words, your ISR WILL finish running even if the character finished transmitting before you finished what you needed to do in the ISR. Look at the "RETI" assembly instruction for the 8051 to understand why a bit more.

That being said, here is a way to do what you're trying to do, just to give you an idea how serial communications works. Also note, that this isn't the stylistically best way to do things, so just use this as a learning example.

unsigned char xmitbuf[25];
unsigned char outpos = 0;
unsigned char outsize = 0;

void serial_isr (void) interrupt 4 {
  if (RI)
    RI = 0;
  if (TI) {
    TI = 0;
    if (outpos < outsize) {
      SBUF = xmitbuf[outpos++];
    } else {
      outpos = 0;
      outsize = 0;
    }
  }
}

void some_func(char *str) {
  if (outsize == 0) {
    outsize = strlen(str);
    memcpy(xmitbuf, str, outsize);
    TI = 1;
  }
}


void main(void) {
  some_func("Hello World");
  while(1);
}

void main(void) {
  some_func("Hello World");
  some_func("Next Message");
  while (1);
}

"If I am to write to SBUF in the isr then I am facing an issue of reentrancy."

How do you figure that?

"My main interest is to say, write "Hello World" and I would like to use some_func(char *str) in the main(void) so I would give something like some_func("Hello World") in the main and our serial ISR is exected to print it and then wait for the next string whenever I send through some_func. How should do that?"

How about this:

printf("Hello world");

If you compiled Keil's serial interrupt code that is all you would have to do. Why are you determined to reinvent the wheel?

Stefan,

I'm hoping that Rohit just wants to use this as a learning exercise since he's obviously new to the 8051. If that's the case, it's probably not a bad idea for him to hack around with code like this. Just my two cents.

Thanks Stefan and Daniel. I am able to understand with the examples provided by you.

"I'm hoping that Rohit just wants to use this as a learning exercise since he's obviously new to the 8051. If that's the case, it's probably not a bad idea for him to hack around with code like this. Just my two cents."

Point taken, and I agree. However, if he were to thoroughly analyse Keil's code all his questions would be answered.

Stefan,

That's probably true. Unless he's nearly as feeble-minded as me and can't see the forest for the trees when looking at larger code samples. :)