| View previous topic :: View next topic |
| Author |
Message |
rmash
Joined: 15 Nov 2004
Posts: 3
Location: Athens, Ohio
|
| USART/printf vs Port C |
 Posted: Tue Nov 16, 2004 9:24 am |
 |
|
Greetings all,
compiler version 3.188
PIC16f688
I've set up a RS232 interface for debugging purposes and am finding out that it or the printf command interferes with my intended use of port C pins. When the printf("start cooler!\r"); line is executed port C line 1 goes to GND. I realize that the rx/tx lines use port C pins 4 and 5, but why is port C line 1 affected?
I've posted my code below.
anything obvious that i'm missing here?
| Code: |
#include<16f688.h>
#device adc=10
#fuses INTRC_IO, NOPROTECT, NOBROWNOUT, NOMCLR, NOWDT,NOPUT
#USE DELAY(clock = 8000000)
#use rs232(baud = 19200, xmit = pin_c4, rcv = pin_c5, bits = 8,parity = n, invert)
#include <stdlib.h>
int main()//--------------------------Main Function--------------------------------
{
setup_adc_ports(san0|san2|san3|vss_vref); // a0,a2,a3 a1 is vref
setup_adc(adc_clock_div_8);
bit_set(*0x001f,6); // allows adc reference
printf("Device Restart!\r");
output_low(pin_c1);
delay_ms(1000);
output_high(pin_c1);
delay_ms(1000);
printf("start cooler!\r");// at this point pin_c1 goes to gnd
loop:
{
delay_ms(500);
}
goto loop;
return(0);
}
|
|
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Nov 16, 2004 2:58 pm |
|
|
You need to shut off the comparators. Add the line shown in bold, below.
int main()
{
setup_comparator(NC_NC_NC_NC);
setup_adc_ports(san0|san2|san3|vss_vref);
setup_adc(adc_clock_div_8);
Also, I don't think that PCM vs. 3.188 properly supports the hardware
USART on pins C4 and C5. I made a test program and the compiler
generates code for a sofware UART on those pins. |
|
|
SherpaDoug
Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA
|
|
| Posted: Tue Nov 16, 2004 3:04 pm |
|
|
| PCM programmer wrote: |
Also, I don't think that PCM vs. 3.188 properly supports the hardware
USART on pins C4 and C5. I made a test program and the compiler
generates code for a sofware UART on those pins. |
If he is using "invert" I assume he intends a software UART.
_________________
The search for better is endless. Instead simply find very good and get the job done. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Nov 16, 2004 3:11 pm |
|
|
You're right.
But if that version of the compiler was operating properly for that PIC,
it would only permit a hardware UART with his #use rs232() statement.
It would kick out an error for the "invert". It could be that he saw
that the compiler wouldn't create a hardware UART, and so he settled
for a soft UART instead, and put in the "invert". I put in that statement
just as a "FYI". |
|
|
Guest
|
|
| Posted: Tue Nov 16, 2004 4:05 pm |
|
|
Thanks very much for your replies and discussion.
I'll try turning off the comparators, I should have thought of that...
About the UART, you're right that the compiler doesn't use the hardware. I found this by setting timer0 to interrupt every ~0.1mS and the printf function ceased working.
So i'll look into updating PCM to the latest, or should I try for an older stabler version? Any suggestions? Favorites?
thanks for your time and expertise gentlemen.
rmash |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Nov 16, 2004 4:14 pm |
|
|
PCM vs. 3.212 does generate code for the hardware UART in a 16F688.
The older version 3.191 does not. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
