rs232 with hardware USART

[Smity42]

hey all

I am trying to interface a PIC16F876A with the PC using the hardware USART, using a max232. I can send data from the pic to PC no problems at all, but i can't get communication from PC to the pic.

So i wrote the following which should echo back binary numbers:

*******


DEFINE OSC 20

' Set receive register to receiver enabled
DEFINE HSER_RCSTA 90h
' Set transmit register to transmitter enabled
DEFINE HSER_TXSTA 20h
' Set baud rate
DEFINE HSER_BAUD 9600

DEFINE HSER_ CLROERR 1

datain var byte


TRISC.6 = 1
TRISC.7 = 0


main:

HSERIN [datain]

Hserout [datain]
goto main

End

********************


Now what it does is just echo back '0's, and furthermore it echos 0's constantly, wether anything is sent from the PC or not.

What is going wrong here?

Thanks for your help

[mister_e]

what about if you just write this code ???



DEFINE OSC 20

' Set baud rate
DEFINE HSER_BAUD 9600

DEFINE HSER_ CLROERR 1

datain var byte

main:

HSERIN [datain]
pause 200 ; if this working now, try to remove this line
; or reduce delay
Hserout [#datain]

goto main



let me know. Case it's not working i'll try something in real world.

regards

[Smity42]

Hello mister_e,

your code is working but without the # on the hserout command

what is this hash supposed to do?

also what is your reasons for leaving out the
DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 20h
lines?

And why is this delay needed?

Thank you

[Smity42]

also:


the echo back seems to be delayed by 1 transmission.

ie i send 12 and nothing is echoed back
then i send 16 and 12 is echoed back
then i send 58 and 16 is echoed back

etc...

what would be the cause of this?

I have added LEDs to indicate the recieved number and they are changing straight away. Only the echo is delayed.

Thanks

[mister_e]

Nop i'm wrong there. Next is working



DEFINE OSC 20

' Set baud rate
DEFINE HSER_BAUD 9600

DEFINE HSER_ CLROERR 1

datain var byte

main:

HSerin [datain]
Hserout [datain]

goto main

[Smity42]

Thank you. That works perfectly. But as far as i can tell the only diff with my original code is not setting the trisc directions and not including the

DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 20h

lines. Now which of these was causing the problem and why?

Thank you

[mister_e]

"ie i send 12 and nothing is echoed back
then i send 16 and 12 is echoed back
then i send 58 and 16 is echoed back

etc...

what would be the cause of this?"


o.k i don't know if it's working for you now without the delay but in case not it seems to be an baud rate problem. So now you have to try those one and remove DEFINE HSER_BAUD 9600 command line.

DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 20h
DEFINE HSER_SPBRG 31


or if it's not working good


DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 24h
DEFINE HSER_SPBRG 129


Q."what is this hash supposed to do?"
A. typing problem from myself ... i'm not proud of me. but in this
case it suppose to return you the ASCII decimal value of your
entry. EX if you send 1 to pic he will return 49


Q."also what is your reasons for leaving out the
DEFINE HSER_RCSTA 90h
DEFINE HSER_TXSTA 20h
lines?"

A. it seems that you don't need them if you use DEFINE
HSER_BAUD 9600 line... but i'm really not sure since i've never
use them before this post

"the echo back seems to be delayed by 1 transmission."
As you must know, if you use MicroCode Studio or hyperterm or other if you send 11, the result of datain is not 11. It will be separate in two byte that contain ASCII value (49 decimal,31 Hex). if you want to send value you must send them in one byte.
that mean if you want to get 11 as value you have to send 11 in hexadecimal. or baddest way if value<99

Hserin [FByte, SByte]
value = ((FByte-48)*10)+(Sbyte-48)
Hserout[#value]
it works but this is really stupid to do it like this.

regards

[mister_e]

It seems we write our reply at the same time...

As i experiment when Picbasic Pro is use, you don't really need to define them by any TRIS stuff. In many case you can use the same i/o pin for getting entry from push button and out to a led without any TRIS define


And you write this for PIC16F876

TRISC.6 = 1
TRISC.7 = 0

but PORTC.6 is for trasmit, so output... must be set to 0
and PORTC.7 is for receive....................must be set to 1

oops :)

regards

[shadowlight69]

hi.
I just used the below code on a pic18f4550 with max232 chip, running a 20mhz crystal, and i am getting no communication at all in either direction

I have no clue what could be wrong. i tried anouther brand new ic, but to no avail.
I also read the pbp manual and couldn't find the answer there.
It would be very kewl to get this working.

Thanks.

Device = 18F4550
Xtal 20
DEFINE HSER_BAUD 9600
TRISB.6 = 0
TRISB.7 = 1
DEFINE HSER_ CLROERR 1
datain var Byte
main:
HSerIn [datain]
HSerOut [datain]
GoTo main
End

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

[Archangel]

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.Hi Dave,
I seldom test devices together until ready to use them, So I Have to use the resistor or my serial lcd will not even boot, Bruce's synopsis explained it very well so as to include both camps, that the max232 serves that pull up function. And yes Dave I do make lots of mistakes and stand corrected without bruised ego. Bottom line is I think we are all trying to help. I brought up the idle status because I have tripped over that too many times. Maybe it is not the OPs problem, getting to the problem usually requires eliminating what it is not. To that end, We have posted.
To the OP:
Have you got it working yet?
Did we help?
will your PIC blink an LED ?
What configs are you using . . Default / roll your own ?