Searching \ for '[PIC] TXREG not being cleared' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'TXREG not being cleared'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] TXREG not being cleared'
2011\09\01@211024 by Nathan House

picon face
My PIC18 datasheet says the following:

"Once the TXREG register transfers the data to the TSR register ...
the TXREG register is empty ..."

In my ISR, I have this:


       if(PIR1bits.RCIF == 1) // if the USART receive interrupt flag has been set
       {
               if(TXREG == 0) // check if the TXREG is empty
               {
                       TXREG = RCREG; // echo received data back to sender
               }
               
               PIR1bits.RCIF = 0; // clear the USART receive interrupt flag
       }


I know it's a good idea to check and make sure there isn't data
waiting to be sent, so I added the IF statement to check if the TXREG
register is empty. The problem is, it's not being cleared, although
the datasheet says it should be. Using my ICD3 debugger I set a
breakpoint in the ISR, and after the first byte is received and echoed
back, no more bytes get sent, which is because the TXREG contains the
first byte sent and is never cleared. Why would this be? Is there a
better way to check if it's "safe" to send data?

Thanks!

Nathan

-- Student Hobbyist
http://www.roboticsguy.co

2011\09\01@213210 by davidcou

picon face
TXIF is what I use to see if it is safe to load the TXREG.





-----Original Message-----
From: Nathan House <spam_OUTnathanpiclistTakeThisOuTspamgmail.com>
To: Microcontroller discussion list - Public. <.....piclistKILLspamspam@spam@mit.edu>
Sent: Thu, Sep 1, 2011 8:10 pm
Subject: [PIC] TXREG not being cleared


My PIC18 datasheet says the following:
"Once the TXREG register transfers the data to the TSR register ...
he TXREG register is empty ..."
In my ISR, I have this:

  if(PIR1bits.RCIF == 1) // if the USART receive interrupt flag has been set
  {
      if(TXREG == 0) // check if the TXREG is empty
      {
          TXREG = RCREG; // echo received data back to sender
      }
             PIR1bits.RCIF = 0; // clear the USART receive interrupt flag
  }

know it's a good idea to check and make sure there isn't data
aiting to be sent, so I added the IF statement to check if the TXREG
egister is empty. The problem is, it's not being cleared, although
he datasheet says it should be. Using my ICD3 debugger I set a
reakpoint in the ISR, and after the first byte is received and echoed
ack, no more bytes get sent, which is because the TXREG contains the
irst byte sent and is never cleared. Why would this be? Is there a
etter way to check if it's "safe" to send data?
Thanks!
Nathan
-- tudent Hobbyist
ww.roboticsguy.com
- ttp://http://www.piclist.com PIC/SX FAQ & list archive
iew/change your membership options at
ttp://mailman.mit.edu/mailman/listinfo/piclist

2011\09\01@220817 by IVP

face picon face
> check if the TXREG register is empty. The problem is, it's not
> being cleared, although the datasheet says it should be

Nathan, half of my support tickets have been about flags that don't
work properly. I suggest you just do what works for you, no matter
what the datasheet says. Check the errata too, although there's no
guarantee that'll confirm what you suspect

Jo

2011\09\01@225013 by Mark Rages

face picon face
On Thu, Sep 1, 2011 at 7:10 PM, Nathan House <nathanpiclistspamKILLspamgmail.com> wrote:
> My PIC18 datasheet says the following:
>
> "Once the TXREG register transfers the data to the TSR register ...
> the TXREG register is empty ..."
>
> In my ISR, I have this:
>
>
>        if(PIR1bits.RCIF == 1) // if the USART receive interrupt flag has been set
>        {
>                if(TXREG == 0) // check if the TXREG is empty
>

Why do you think "empty" means "zeroed"?

I think "empty" means "don't care" and you must look at TXIF to see if
it is empty or not.

Regards,
Mark
markrages@gmail
-- Mark Rages, Engineer
Midwest Telecine LLC
.....markragesKILLspamspam.....midwesttelecine.com

2011\09\01@230526 by William \Chops\ Westfield

face picon face

On Sep 1, 2011, at 6:10 PM, Nathan House wrote:

> "Once the TXREG register transfers the data to the TSR register ...
> the TXREG register is empty ..."

"And the TXIF flag is set"

> I added the IF statement to check if the TXREG register is empty.

You're confusing "empty" with "reads as zero."  What did you expect to  have happen if you transmitted a null (zero) byte?  You can't tell  whether a register is "empty" except by checking some additional flag  (or value) that MEANS it's empty by whatever criteria happen to mean  "empty" for that peripheral.  (In this case, "the character has been  transferred to another register, and you're allowed to put a new  character in the register.")

BillW

2011\09\01@231743 by Harold Hallikainen

face
flavicon
face
"Empty" doesn't mean it has zero in it. The "empty" may be a bit
misleading. The TXIF bit is set if the USART is ready to accept another
character. Note that it may still be transmitting the previous one. When
it is finished transmitting the character, data in the transmit holding
register is transferred to the transmit shift register for transmission.

So, there are two bit available that tell you what the transmit side of
the usart is doing.

TXIF is set if the usart is ready for another character.

TRMT is set if the usart has finished transmitting and has nothing else to
transmit.

Harold



-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\09\02@010502 by IVP

face picon face
> TRMT is set if the usart has finished transmitting and has nothing
> else to transmit

PICs with a UART FIFO work like that. You can check if the buffer
is not full (BF = 0, another character can be added) or if it's empty
(TRMT = 1, last byte has gone out

2011\09\02@015032 by John Temples

flavicon
face
On Thu, 1 Sep 2011, Nathan House wrote:

>                PIR1bits.RCIF = 0; // clear the USART receive interrupt flag

RCIF is a read-only bit.  You cannot write a zero to it.  It reflects
the state of RCREG: set when there is data waiting to be read, clear
when there isn't.

TXIF is also read-only.

--
John W. Temples, II

2011\09\02@043346 by alan.b.pearce

face picon face
> > check if the TXREG register is empty. The problem is, it's not
> > being cleared, although the datasheet says it should be
>
> Nathan, half of my support tickets have been about flags that don't
> work properly. I suggest you just do what works for you, no matter
> what the datasheet says. Check the errata too, although there's no
> guarantee that'll confirm what you suspect

But from my reading of Nathans post, he is expecting something that will not happen, he is not looking at the flags. This is because of the nomenclature used in the datasheet or family reference manual.

Nathan, when it says that the TXReg is cleared, it doesn't mean that the data you loaded into it is turned into zero bits, which is what you are testing for in your code. It means that the data has been transferred to the shift register, and so you are now clear to load the next data into TXREG. As someone else mentioned the correct way to test is to look at the TXIF bit in the status register.
-- Scanned by iCritical.

2011\09\02@055642 by IVP

face picon face
> But from my reading of Nathans post, he is expecting something
> that will not happen, he is not looking at the flags. This is because
> of the nomenclature used in the datasheet or family reference manual.

Ah, yes, read it a bit too quickly. The data would be_copied_ from
TXREG to TSR. TXIF is the 'TXREG empty' flag (user data has
been copied to the TSR), TRMT is the 'TSR empty' flag (the data
in TSR has left the building)

2011\09\02@083022 by Kerry Wentworth

flavicon
face
Are you sure of that?  I've not seen it documented anywhere, but I have set interrupt flags to generate an interrupt.

For example, using interrupt on PortB change to read an encoder.  Reading/writing PortB for other I/O can cause the interrupt to fail to occur.  By keeping track of the state phase A and B were in at the last interrupt, you can detect if a change happened that failed to cause an interrupt.  You can then set RBIF = 1 and cause an interrupt.  I know for sure it works that way for 16F chips, and see no reason it wouldn't work with 18F as well.

Kerry



John Temples wrote:
{Quote hidden}

>

2011\09\02@084801 by Jan-Erik Soderholm

face picon face
But RBIF != RCIF or TXIF.

There is no rule that RCIF and TXIF must be writeable
just becuse RBIF is.

The datasheet for 16F690 specificaly says "R/W" för RABIF
(port-change flag for PORTA/B) and "R" for TXIF and RCIF.

Jan-Erik.



Kerry Wentworth wrote 2011-09-02 14:28:
{Quote hidden}

2011\09\02@090154 by Kerry Wentworth

flavicon
face
You are correct, sir.  The same is true for the 16F887, which is the data sheet I looked at.  You just need to look at the correct page!

Kerry


Jan-Erik Soderholm wrote:
{Quote hidden}

>>>

2011\09\03@205705 by Nathan House

picon face
Thanks for all of your help! I see now that my mistake was
interpreting "empty" as meaning "cleared."

Is there any reason to wait to write until TRMT is set as opposed to TXIF?

>RCIF is a read-only bit.  You cannot write a zero to it.  It reflects
>the state of RCREG: set when there is data waiting to be read, clear
>when there isn't.

Isn't that unusual for an interrupt flag? Don't interrupt flags
generally have to be cleared, else the ISR will continually be called?
Does reading from the RCREG (like "variable = RCREG") clear the
interrupt flag, then?

Thanks,

Nathan

-- Student Hobbyist
http://www.roboticsguy.co

2011\09\03@213535 by Bob Ammerman

flavicon
face


> Thanks for all of your help! I see now that my mistake was
> interpreting "empty" as meaning "cleared."
>
> Is there any reason to wait to write until TRMT is set as opposed to TXIF?

You would normally wait for TXIF. You would only use TRMT if you needed to know that all the data had gone out the wire, perhaps before turning around a line driver or something.

{Quote hidden}

You are exactly right about RCIF, you clear it by reading RCREG. Note that it might remain set if there are additional characters in the receive FIFO.

-- Bob Ammerman
RAm Systems

2011\09\03@231135 by William \Chops\ Westfield

face picon face

On Sep 3, 2011, at 5:57 PM, Nathan House wrote:

>> RCIF is a read-only bit.  You cannot write a zero to it.
>
> Isn't that unusual for an interrupt flag? Don't interrupt flags
> generally have to be cleared, else the ISR will continually be called?

Yes; many interrupt controllers and some raw interrupt sources will  require that you specifically reset the appropriate bit.  However,  that tends to be for peripherals that are less obviously connected to  the reasons for their interrupts.  It's pretty common for UART  interrupt flags to be cleared automatically when the code takes the  appropriate action.

> Does reading from the RCREG (like "variable = RCREG") clear the
> interrupt flag, then?

Yes, exactly.  This is probably backward compatible with some ancient  UART chip or something.  I've seen some uarts where less obvious  interrupt sources (modem control line changes, error conditions) have  to be explicitly reset...

BillW

2011\09\04@012223 by Harold Hallikainen

face
flavicon
face

>
>
>> Thanks for all of your help! I see now that my mistake was
>> interpreting "empty" as meaning "cleared."
>>
>> Is there any reason to wait to write until TRMT is set as opposed to
>> TXIF?
>
> You would normally wait for TXIF. You would only use TRMT if you needed to
> know that all the data had gone out the wire, perhaps before turning
> around
> a line driver or something.

I usually watch TXIF, but have watched TRMT for transmitting DMX-512 where
I need to know that last byte went out before sending a break (this on
PICs where the UART does not know how to do a break, so I do it with
external hardware). It would be nice if there were an interrupt on TRMT,
but I got around it by using a timer interrupt.

Harold


-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...