Post by thread:[PIC] 16F913 usart issue

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.

alan smith wrote: {Quote hidden}> 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 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

Any special reason to enable/disable the USART sender for each character ? Jan-Erik. alan smith wrote: {Quote hidden}> 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.

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}> Any special reason to enable/disable the USART sender > for each character ? > > Jan-Erik. > > alan smith wrote: > >> 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. >>

-----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}> 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. -----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-----

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_OUTcheadTakeThisOuTtelus.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}> 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. -----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-----

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

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" <.....twKILLspam@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