rs232 with hardware USART

[DocDingwall]

Shadowlight69
I'm also facing the same issue (and have been stuck for weeks now). The main issue (so far as I can understand) is that the processor timing is more complicated with this family of chips. The processor in your case is probably not running at 20MHz. The way to tell is to set a loop to flash an LED with a longish pause between flashes (say "pause 5000" for instance) and see how long it actually takes to flash. If it is not 5 seconds then your processor is not running at 20 MHz. My problem is trying to figure out from the fuses what the processor IS running at.

Can I ask you to start this as a new thread? We'll get help quicker that way.

Thanks,
DD.

[Dave]

shadowlight69 , Is that the actual program you are trying to run? If so "Xtal 20" is not a command but, "DEFINE OSC 20" is.

Dave Purola,
N8NTA

[Archangel]

Just a reminder: Hardware serial port USART in PICs require a pull UP resistor to work as they send Data TRUE.

[Dave]

Joe S. , What? "Hardware serial port USART in PICs require a pull UP resistor to work " I have never heard of such a thing.. The USART port's on all of the MicroChip processors are capable of sinking as well as sourcing current... At least the last time I read them.... Better read your data sheet's Joe.

Dave Purola,
N8NTA

[Archangel]

Data TRUE idles high, Data inverted idles Low - Hserin receives data TRUE. Hardware usart receive is an input. It neither sources or sinks current, although there may be chips with internal pullups. I know the chips I have used will not receive without the pullup.

[Bruce]

If he has the PIC connected to a max232 hooked to a PC serial port the RX pin should already be held at logic 1 through the max232.

http://www.rentron.com/Files/bMAX232.gif

PIC to PIC using the hardware UART the tx pin on both will idle high so that works also without a pull-up. Even bit-banged serial should hold the tx pin at the idle logic state during idle periods.

But;
Device = 18F4550
Xtal 20

Indicates he's probably using the Proton compiler, so I would post the question there. It's most likely a configuration problem. Without config options in your code you're using whatever defaults they have in the include file, so it's probably not running at 20MHz.

[Dave]

Joe S. I thought you were talking about the output of the USART. The input requires a digital digital which should be supplied by the source of the other communicating device. If it is an open collector type output from the other device then, yes there should be some type of pullup device to produce the source current for driving the USART input. Sorry for the confusion on my part of the reply.