Searching \ for '[PIC] 16F913 usart issue' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=usart
Search entire site for: '16F913 usart issue'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 16F913 usart issue'
2007\10\15@162407 by alan smith

picon face
So I really havent done much with 16F serial, and the 18F stuff I can get to work flawlessy (so far at least), so I am having a small issue with this code on the '913
 
 
 To preface, it works...almost.  I have a string defined such as it uses a jump table to index into it, and has a null on the end to terminate.  I can address into it, grab the character and it sends it out, so the USART is setup properly, and single stepping it displays each character, so far so good.
 
 Now, when I do it full speed....I lose characters.  I'm thinking...ok....the buffer isnt clearing out by the time I go to get the next character and send it.  Cheating....add delay.  But doesnt fully explain things.
 
 So here is the code that sends the character, held in Wreg
 
 TX_CHARACTER
     banksel     TXSTA
     bsf            TXSTA,TXEN
     banksel     TXREG
     movwf       TXREG
_txCharLoop
     call           DEBOUNCE
     btfsc         TXSTA,TRMT     ; check buffer, wait till empty (1=empty)
     goto         _txCharLoop
     bcf           TXSTA,TXEN
return

 
 This code is the one that works yet drops characters.  If I pull out the debounce call, it breaks.  I was thinking that checking the TRMT bit should do the job without the delay but doesn't appear to.  I was thinking banksel needs to be set prior to looking at the TRMT bit, but adding that breaks it.  So I can break it...meaning that it might send the first character or just a '.'  It has to be something obvious, but what I've play with doesnt seem to help.
 
 I am running a 4MHz xtal, with the BRG and SPRGH settings for 9600baud, 8/n (if that was wrong then i would imagine I wouldnt be getting out good data at all).
 
 Any thoughts?

     
---------------------------------
Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV.    

2007\10\15@171331 by Timothy J. Weber

face picon face
alan smith wrote:
{Quote hidden}

Hmm... Why are you clearing and re-setting TXEN on each character?  I
don't immediately see how it could cause the behavior you're seeing, but
I would delete those lines - all you should have to do is FIRST wait for
TRMT to go high, THEN put your data in TXREG.

(This is from memory.)
--
Timothy J. Weber
http://timothyweber.org

2007\10\15@172549 by Jan-Erik Soderholm

face picon face
Any special reason to enable/disable the USART sender
for each character ?

Jan-Erik.

alan smith wrote:
{Quote hidden}

2007\10\15@174122 by Dave Wheeler

flavicon
face
As well as the other comments

After the ' banksel TXREG' you will be in BANK0, TXSTA is in BANK1 so I
would change your call to DEBOUNCE for banksel TXSTA, I personally
always restore my calls to BANK0 so I would add a BANKSEL 0 (might be
wrong syntax, I use a macro) before returning

Good Luck

Dave


Jan-Erik Soderholm wrote:
{Quote hidden}

2007\10\16@001820 by Christopher Head

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
I think you want "btfss", not "btfsc".

BTFSC means "test and skip if CLEAR", which means "SKIP IF TRMT=0",
which means skip OUT of the loop if TRMT=0 => transmit register is NOT
empty => transmit register is full => still sending.

BTFSS means "test and skip if SET", which means "SKIP IF TRMT=1", which
means skip OUT of the loop if TRMT=1 => transmit register IS empty =>
finished sending.

I assume TRMT means the same on the 913 as it does on the 648A (I don't
have a 913 datasheet to hand). If the polarity is inverted, then (1)
ignore my message, and (2) your comment is backwards.

Chris

alan smith wrote:
{Quote hidden}

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHFDuKytrPjvMzl6YRAvXGAJ4wbUC/XSWGc15taBM6Zr13Z3AyPQCfVA8f
yN/nXmG10dd2H07aqtv6QIM=
=ESTX
-----END PGP SIGNATURE-----

2007\10\16@092449 by alan smith

picon face
OK.....so to answer the couple of questions...
 
 why did I set and clear the TXEN bit? only because when I put the module together I was making sure on entry and exit it would be a known state, but once I had the calls and other structure put together, I could clean that up..which I did.
 
 So it appears the real culprit was the btfss vs btfsc
 
 Sometimes you can't see the forest for the trees  :-)
 
 
 
 
Christopher Head <spam_OUTcheadTakeThisOuTspamtelus.net> wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
I think you want "btfss", not "btfsc".

BTFSC means "test and skip if CLEAR", which means "SKIP IF TRMT=0",
which means skip OUT of the loop if TRMT=0 => transmit register is NOT
empty => transmit register is full => still sending.

BTFSS means "test and skip if SET", which means "SKIP IF TRMT=1", which
means skip OUT of the loop if TRMT=1 => transmit register IS empty =>
finished sending.

I assume TRMT means the same on the 913 as it does on the 648A (I don't
have a 913 datasheet to hand). If the polarity is inverted, then (1)
ignore my message, and (2) your comment is backwards.

Chris

alan smith wrote:
{Quote hidden}

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHFDuKytrPjvMzl6YRAvXGAJ4wbUC/XSWGc15taBM6Zr13Z3AyPQCfVA8f
yN/nXmG10dd2H07aqtv6QIM=
=ESTX
-----END PGP SIGNATURE-----

2007\10\16@095614 by Timothy J. Weber

face picon face
alan smith wrote:
> OK.....so to answer the couple of questions...
>    
>   why did I set and clear the TXEN bit? only because when I put the module together I was making sure on entry and exit it would be a known state, but once I had the calls and other structure put together, I could clean that up..which I did.
>    
>   So it appears the real culprit was the btfss vs btfsc
>    
>   Sometimes you can't see the forest for the trees  :-)

It's also an interesting example of how when we (I) find one issue, we
stop looking!

But another pattern I see here is that it would have been easier (for
me!) to see that bug in C.  E.g., compare these:

  _txCharLoop
  call DEBOUNCE
  btfsc TXSTA,TRMT ; check buffer, wait till empty (1=empty)
  goto _txCharLoop

vs.:

  // check buffer, wait till empty (1=empty)
  while (txsta.TRMT == 1)
    ;

...or even...

  inline bool serialReadyToTransmit(void)
  {
    return txsta.TRMT == 1;
  }
  ...
  // check buffer, wait till empty
  while (serialReadyToTransmit)
    ;

For me, either of the C examples would make it easier to spot the bug
(and harder to write it wrong in the first place).  And they would
probably produce identical assembly.

I know, the HLL vs. assembly debate is an old one and I don't want to
drag it out again...
--
Timothy J. Weber
http://timothyweber.org

2007\10\16@105405 by alan smith

picon face
ya..true.  You know I'd love to start writing in C, I own a compiler, but its the old adage...can't stop cutting the wood to sharpen the saw.  I honestly haven't written anything in C for about 8 years now..and then it wasn't embedded C, but on a unix box.  Its a matter of spinning up and taking advantage of it.  I just need to be a little less busy....

"Timothy J. Weber" <.....twKILLspamspam@spam@timothyweber.org> wrote:  alan smith wrote:
> OK.....so to answer the couple of questions...
>
> why did I set and clear the TXEN bit? only because when I put the module together I was making sure on entry and exit it would be a known state, but once I had the calls and other structure put together, I could clean that up..which I did.
>
> So it appears the real culprit was the btfss vs btfsc
>
> Sometimes you can't see the forest for the trees :-)

It's also an interesting example of how when we (I) find one issue, we
stop looking!

But another pattern I see here is that it would have been easier (for
me!) to see that bug in C. E.g., compare these:

_txCharLoop
call DEBOUNCE
btfsc TXSTA,TRMT ; check buffer, wait till empty (1=empty)
goto _txCharLoop

vs.:

// check buffer, wait till empty (1=empty)
while (txsta.TRMT == 1)
;

...or even...

inline bool serialReadyToTransmit(void)
{
return txsta.TRMT == 1;
}
...
// check buffer, wait till empty
while (serialReadyToTransmit)
;

For me, either of the C examples would make it easier to spot the bug
(and harder to write it wrong in the first place). And they would
probably produce identical assembly.

I know, the HLL vs. assembly debate is an old one and I don't want to
drag it out again...
--
Timothy J. Weber
http://timothyweber.org

2007\10\16@114434 by Timothy J. Weber

face picon face
alan smith wrote:
> ya..true.  You know I'd love to start writing in C, I own a compiler, but its the old adage...can't stop cutting the wood to sharpen the saw.  I honestly haven't written anything in C for about 8 years now..and then it wasn't embedded C, but on a unix box.  Its a matter of spinning up and taking advantage of it.  I just need to be a little less busy....

No chastisement intended!  :)

(OK, maybe just a teeeny bit)
--
Timothy J. Weber
http://timothyweber.org

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