Searching \ for '[PIC] USART on 16F876' 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: 'USART on 16F876'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] USART on 16F876'
2006\10\14@020756 by Jason

flavicon
face

I'm trying to interface the PIC to a PC through the USART.

I tried to set up the registers based on the datasheet. The TX pin
goes high, but when I try to transmit, it just stays high with no
signal. Any ideas what could be causing this?

Thanks,
Jason

My test code is:

include f877_4
include jlib

var volatile byte SPBRG at 0x99
var volatile byte TXSTA at 0x98
var volatile byte RCSTA at 0x18
var volatile byte TXREG at 0x19
var volatile byte RCREG at 0x1a
var volatile byte PIR1 at 0x0c

-- set USART up
pin_c6_direction = output -- transmit is an output
pin_c7_direction = input -- receive is an input
TXSTA = 0b_0010_0100 -- asynch, 8-bit, transmit enabled
RCSTA = 0b_1001_0000 -- asynch, no address detect, 8-bit

-- set for 300 baud
SPBRG = 207
BRGH = low

var bit LED is pin_b1
pin_b1_direction = output

forever loop
delay_100ms( 5 )
LED = high
TXREG = "H"
TXREG = "e"
TXREG = "l"
TXREG = "l"
TXREG = "o"
TXREG = " "
delay_100ms( 5 )
LED = low
end loop

2006\10\14@055748 by Brent Brown

picon face
Jason wrote:
<snip>
> pin_c6_direction = output -- transmit is an output
> pin_c7_direction = input -- receive is an input

The above seems correct, intuitively, but...

The data sheet says "Bit SPEN (RCSTA<7>) and bits TRISC<7:6> have to be set in
order to configure pins RC6/TX/CK and RC7/RX/DT as the Universal Synchronous
Asynchronous Receiver Transmitter."

This has got me before, definitely a trap for new players.

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  spam_OUTbrent.brownTakeThisOuTspamclear.net.nz


2006\10\14@141826 by slippyr4

picon face
furthermore, after filling TXREG, you need to wait for TXIF to be set
(either by configuring interrupts or by polling it) before loading the
next char. At least that's how it works with the other 16-series i've
used - i've not got that datasheet in front of me.

On 14/10/06, Brent Brown <.....brent.brownKILLspamspam@spam@clear.net.nz> wrote:
{Quote hidden}

> -

2006\10\14@170913 by Jason

flavicon
face
From: "Brent Brown" <.....brent.brownKILLspamspam.....clear.net.nz>
Sent: Saturday, October 14, 2006 2:56 AM


> The data sheet says "Bit SPEN (RCSTA<7>) and bits TRISC<7:6> have to be
> set in
> order to configure pins RC6/TX/CK and RC7/RX/DT as the Universal
> Synchronous
> Asynchronous Receiver Transmitter."
>
> This has got me before, definitely a trap for new players.

Definately confusing.  I changed it to set both those TRIS bits now.


From: "slippyr4" <EraseMEslippyr4spam_OUTspamTakeThisOuTgmail.com>
Sent: Saturday, October 14, 2006 11:18 AM


> furthermore, after filling TXREG, you need to wait for TXIF to be set
> (either by configuring interrupts or by polling it) before loading the
> next char. At least that's how it works with the other 16-series i've
> used - i've not got that datasheet in front of me.

I knew about that, but at this point, I'm just trying to get a signal on TX
to make sure that part is working.  If bytes get lost it is not a problem
yet.  I did change it to check that flag just in case my overflows were
turning off the USART or something like that.

Now, TXIF is never being set, so I'm never even trying to transmit (and of
course have no signal on TX).

Thanks,
 Jason


2006\10\14@173450 by stef mientki

flavicon
face

> I knew about that, but at this point, I'm just trying to get a signal on TX
> to make sure that part is working.  If bytes get lost it is not a problem
> yet.  I did change it to check that flag just in case my overflows were
> turning off the USART or something like that.
>
> Now, TXIF is never being set, so I'm never even trying to transmit (and of
> course have no signal on TX).
>  
why starting so difficult,
where there are dozens of working RS232 libraries available for free ?

Stef

2006\10\15@043210 by Jason

flavicon
face
From: "stef mientki" <s.mientkispamspam_OUTmailbox.kun.nl>
Sent: Saturday, October 14, 2006 2:34 PM


> why starting so difficult,
> where there are dozens of working RS232 libraries available for free ?

I haven't been able to get an RS232 library to work in Jal 0.46.  I see on
your site you have a Jal 2.0 library but I've got other issues with Jal 2.0
that aren't worth bringing up under the [PIC] tag.  I also see some
bit-banging libraries including the one that came with Jal and one that says
16F84 only.  There's an 18F452 version.  I wouldn't mind switching to that
chip but I haven't managed to get it to work with Jal and I don't want to
add more problems right now.


2006\10\17@174033 by trossin

picon face

Here it is in BoostC format.  You should be able to convert to JAL.

-------------------------serial.c------------------------

#include <system.h>
       
void RS232putch(unsigned char ByteVal)
{
   while(!(test_bit(pir1,4)));
   txreg = ByteVal;
}

unsigned char RS232getch(void)
{
   while(!(test_bit(pir1,5)));
   clear_bit(pir1,5);
   return(rcreg);
}

unsigned char RS232peekch(void)
{
   if(test_bit(pir1,5)) return(1);
   return(0);
}

       /* Set up serial port to run at desired baud rate */
       
void RS232Init(unsigned char BaudRate)
{
       set_bit(trisc,7);        // PORTC[RX] is Input
       clear_bit(trisc,6); // PORTC[TX] is Output
       spbrg = BaudRate;        // Set baud. see header file
       txsta = 0x24;                // Set TXEN and BRGH to 1
       rcsta = 0x90;                // Set SPEN and CREN to 1

       /*
       movlw        (1<<TXIE)|(1<<RXIE)
       iorwf        PIE1                        ; Enable Transmit and receive interrupts
   */

}

-----------------------serial.h---------------------------
void RS232Init(unsigned char BaudRate);
void RS232putch(unsigned char ByteVal);
char RS232getch(void);
unsigned char RS232peekch(void);

#define RS232_20MHZ_BAUD_115000                10
#define RS232_20MHZ_BAUD_57600                20
#define RS232_20MHZ_BAUD_28800                42
#define RS232_20MHZ_BAUD_19200                64
#define RS232_20MHZ_BAUD_9600                129

#define RS232_16MHZ_BAUD_115000                8
#define RS232_16MHZ_BAUD_57600                16
#define RS232_16MHZ_BAUD_28800                33
#define RS232_16MHZ_BAUD_19200                51
#define RS232_16MHZ_BAUD_9600                103

#define RS232_10MHZ_BAUD_115000                4
#define RS232_10MHZ_BAUD_57600                10
#define RS232_10MHZ_BAUD_28800                21
#define RS232_10MHZ_BAUD_19200                31
#define RS232_10MHZ_BAUD_9600                6
--
View this message in context: www.nabble.com/USART-on-16F876-tf2441492.html#a6840330
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2006\10\17@182011 by Jason

flavicon
face
From: "trossin" <@spam@ted_rossinKILLspamspamyahoo.com>
Sent: Monday, October 16, 2006 11:35 AM

> Here it is in BoostC format.  You should be able to convert to JAL.

Thank you.  I still haven't gotten anywhere on the problem.

I can try translating that, but so far the only thing in it I see that I
haven't tried is enabling the transmit and receive interrupts

> set_bit(trisc,7); // PORTC[RX] is Input
> clear_bit(trisc,6); // PORTC[TX] is Output

I'm confused by this now.  As Brent Brown pointed out earlier in the thread,
the datasheet says both tris bits should be set.  I originally was setting
RX and clearing TX as this code does.  I changed it to set both.

Jason


2006\10\17@185734 by trossin

picon face

Enabling interrupts will not be the answer.  I just left this in comments in
case I want to enable it one day.  I have used this code on many projects
(previously in assember form) without trouble on many 16F87x parts.  When
you enable the UART it will override the PORTC TX and RX I/O control so in
theory it does not matter what you set the TRISC value to.  When TXEN (bit 5
of TXSTA) is set, PORTC[6] will become an output.

In looking at your code again it seems that you have the correct settings.
The only thing I can suggest is to create a loop that checks the status like
my RS232putch and keep sending a character with lots of toggles.  Also,
double check that you are using the correct pin (pin 25 on the 40-pin
package, pin 17 on the 28 pin package).  Sometimes it is the simple stuff
that is going wrong when nothing makes sense.


Jason-55 wrote:
{Quote hidden}

> --

2006\10\17@192827 by Jason

flavicon
face
I've checked the hardware many times, but I checked again and I'm definately
on pin 17 (it's the 28 pin package).  When I clear the tris bit for the TX
pin before enabling the UART, the pin is driven low for a few instruction
cycles before it goes high and stays high.

My polling loop right now is:
forever loop
 delay_100ms( 5 )
 LED = high
 delay_100ms( 1 )
 if (TXIF == low) then
  LED = low
 else
  TXREG = "H"
 end if
 delay_100ms( 5 )
 LED = low
end loop

So I'm using the LED to help me see what TXIF is.  TXIF never goes high, so
I never even try to transfer a byte, so with this code, it's no surprise
that I'm getting no signal on TX.

Jason



{Original Message removed}

2006\10\17@202243 by Jinx

face picon face
Jason, maybe you can see something in this code. It's for an
F877 and comes from a working product

;================================================
;        Initialise RS232 serial comms
;================================================

; 19200 with BRGH = 1

; 19200 = 18.432MHz / (16 * (X+1))

; X = ( (18432000 / 19200) / 16 ) -1
; X = (960/16)-1
; X = 59

        bank1
        movlw   .59          ;19200 baud @ 18.43200MHz
        movwf   spbrg
        movlw   b'00100100'  ;brgh=1, Asynch, 8-bit, Tx enabled
        movwf   txsta

        bank0
        movlw   b'10010000'  ;Asynch, 8-bit, Rx enabled
        movwf   rcsta
        movf    rcreg,w      ;clear receive buffer and rcif
        bcf     rcsta,cren   ;clear any errors
        bsf     rcsta,cren

;initialise comms traffic

sendi    movlw   "I"          ;get PC's attention
        call    byte_out

        call    byte_in      ;wait for "I" back from PC
        movlw   "I"
        xorwf   temp,w
        btfss   zero
        goto    sendi

rest of code

;================================================
;        Transmit byte to PC from W
;================================================

byte_out bank0
        movwf   txreg
        bank1
        btfss   txsta,trmt   ;wait for data gone
        goto    $-1
        bank0
        return

;================================================
;        Receive byte from PC into W
;================================================

byte_in  bank0
        btfss   pir1,rcif    ;wait for received data flag
        goto    $-1
        movf    rcreg,w
        movwf   temp
        return



2006\10\17@211626 by Jinx

face picon face
Jason, have you looked at

http://www.piclist.com/techref/microchip/rs232.htm

2006\10\18@025728 by Jason

flavicon
face
From: "Jinx" <RemoveMEjoecolquittTakeThisOuTspamclear.net.nz>
Sent: Tuesday, October 17, 2006 5:19 PM


> Jason, maybe you can see something in this code. It's for an
> F877 and comes from a working product

I'm not seeing anything I'm missing, but the lines
        bcf     rcsta,cren   ;clear any errors
        bsf     rcsta,cren
are something I haven't done.  It doesn't look like it should affect what
I'm doing though.

I tried assembling your code to see if I could run it and MPLAB didn't seem
to like it, the goto $-1 lines confused the assembler.

Do you have a hex file I can load in the chip that will repeatedly output a
letter and you know works?  At the very least it should see if my hardware
and test setup are working to prove the problem is in software.


2006\10\18@030715 by stef mientki

flavicon
face
hi Jason,

why not discuss this on the JAL-list ?
(there they know exactly all the quirks of JAL v0.xx).
  and / or
move to JAL v2.xx which solves all these nasty things.
(didn't I suggest that before ;-)

But here 2 things to check:
- remember JAL v0.xx only can access bank-0 registers directly (TXSTA ?)
- there are a number of bad libs for JAL v0.xx around on the web

Stef

Jason wrote:
{Quote hidden}

> {Original Message removed}

2006\10\18@033559 by Jinx

face picon face

> I tried assembling your code to see if I could run it and MPLAB
> didn't seem to like it, the goto $-1 lines confused the assembler

Shouldn't have, $-1 is a valid arithmetic operator. You could try
labels instead eg

wait_rx         btfss   pir1,rcif    ;wait for received data
               goto    wait_rx

> Do you have a hex file I can load in the chip that will repeatedly
> output a  letter and you know works?

Sorry, have nothing like that

2006\10\18@052500 by Jason

flavicon
face
From: "stef mientki" <spamBeGones.mientkispamBeGonespammailbox.kun.nl>
Sent: Wednesday, October 18, 2006 12:07 AM


{Quote hidden}

Hi Stef,
 You're right, on the JAL list, they gave me a library which seems to be
working so far.

 I posted here because it seems like independant of JAL, I'm doing
something wrong with how I'm using the UART.  I want to learn how to use it
directly for my own knowledge.  For now I need to read over the working
library to see where my mistake was.


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