CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Difference between TX/RX and normal I/O with #use RS232 ???

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
chancaar



Joined: 23 Mar 2004
Posts: 6
Location: Belgium

View user's profile Send private message Send e-mail

Difference between TX/RX and normal I/O with #use RS232 ???
PostPosted: Sun May 30, 2004 2:27 am     Reply with quote

Hello!

PIC = 16F877

I'll have to communicate with a device using baudrate 9600,stopbit=1, non parity.
When I connect this device I first do some tests using the special TX to transmit data. I can see it is working that way sending a specific string for my application. It works in 3 ways...

So I Define:
#use rs232(baud=9600,bits=8,parity=N,xmit=PIN_C6,rcv=PIN_C7)

// 3 ways:
//
// I send the caracters one by one with:
// for(i=0;i<n;i++) { putc('char');}
//
// or the entire string using puts("string");
//
// or I do is by printf("string")


Later I tried it using another normal (output declared) pin with the "#use rs232"...

So I Define for example (using PIN_B5 and PIN_D4):

(I configured PIN_B5 as an output, PIN_D4 as an input...)

#use rs232(baud=9600,bits=8,parity=N,xmit=PIN_B5,rcv=PIN_D4)

//and none of the 3 ways are working like mentioned above...

What's the different between normal I/O and TX/RX for sending and receiving signals when I define for both of them: the baudrate, parity bit, stop bit, transmit pin and receive pin???

I realise the TX/RX PIN is specially made for RS-232 communications but when I "talk" to a simular configured hyperterminal by using the normal I/O pins, it works! When I connect the device instead of the hyperterminal, it doesn't.

The TX/RX port is allready in use for another device in my project...

I hope somebody can help me with this problem.

Thanks for your time!

Yves
_________________
Yves Willemaers
Belgian student
dfnr2



Joined: 26 Dec 2003
Posts: 2

View user's profile Send private message

PostPosted: Sun May 30, 2004 7:05 am     Reply with quote

What is your clock speed? The difference is that when you use the UART, the timing is generated in hardware, and for other pins, the timing is done in software. It is possible that for slow clock speeds, the software timing could be marginal.

I assume that you're using an apropriate conversion between RS2323 and chip logic levels.

D
chancaar



Joined: 23 Mar 2004
Posts: 6
Location: Belgium

View user's profile Send private message Send e-mail

PostPosted: Mon May 31, 2004 8:07 am     Reply with quote

I use a 20 MHz clock speed... and I'm using a MAX233 to transform the level.
_________________
Yves Willemaers
Belgian student
rwyoung



Joined: 12 Nov 2003
Posts: 563
Location: Lawrence, KS USA

View user's profile Send private message Send e-mail

PostPosted: Mon May 31, 2004 8:45 am     Reply with quote

20MHz xtal or 20MHz ceramic resonator?

Get out your oscilloscope and x10 probe and check:

1) OSC2 should be 20MHz
2) Look at pin B5 while you transmit the value 0x55. Check that the pulse widths are correct. If they are more than a few percent slow or fast some RS232 devices will not work correctly
3) Look at the RS232 levels without your device connecteded. Generally the MAX233 swings about +/-9V.
4) Look at the RS232 levels WITH your device connected. Are the levels still valid? What levels is your device expecting? Eventhough something says it accepts RS232 input levels they may not mean anything from 3V to 15V, some cheap interface designs won't function properly without sufficient amplitude.
5) With your scope probe on pin B5 (your TX pin), force the PIC to reset. Are you seeing spurious transmissions? Could those lockup your receiving device? Most UARTs have timeouts built in so that if they do not detect the stop bits within a reasonable amount of time from the start bit, the received data is delcared invalid and the UART will watch for a new start condition.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month!
Ttelmah
Guest







Re: Difference between TX/RX and normal I/O with #use RS232
PostPosted: Mon May 31, 2004 8:47 am     Reply with quote

chancaar wrote:
Hello!

PIC = 16F877

I'll have to communicate with a device using baudrate 9600,stopbit=1, non parity.
When I connect this device I first do some tests using the special TX to transmit data. I can see it is working that way sending a specific string for my application. It works in 3 ways...

So I Define:
#use rs232(baud=9600,bits=8,parity=N,xmit=PIN_C6,rcv=PIN_C7)

// 3 ways:
//
// I send the caracters one by one with:
// for(i=0;i<n;i++) { putc('char');}
//
// or the entire string using puts("string");
//
// or I do is by printf("string")


Later I tried it using another normal (output declared) pin with the "#use rs232"...

So I Define for example (using PIN_B5 and PIN_D4):

(I configured PIN_B5 as an output, PIN_D4 as an input...)

#use rs232(baud=9600,bits=8,parity=N,xmit=PIN_B5,rcv=PIN_D4)

//and none of the 3 ways are working like mentioned above...

What's the different between normal I/O and TX/RX for sending and receiving signals when I define for both of them: the baudrate, parity bit, stop bit, transmit pin and receive pin???

I realise the TX/RX PIN is specially made for RS-232 communications but when I "talk" to a simular configured hyperterminal by using the normal I/O pins, it works! When I connect the device instead of the hyperterminal, it doesn't.

The TX/RX port is allready in use for another device in my project...

I hope somebody can help me with this problem.

Thanks for your time!

Yves

What you describe should work. The big 'caveat', is what else the computer is doing at the time. The problem is that soft RS232, is completely dependant on the processor remaining scanning the pin (or driving the pin), and not being interrupted. Hence try the experiment of disabling interrupts before you access the 'soft' RS232 port. My suspicion is that you are receiving perhaps serial, or timer interrupts, and this is killing the timing on the soft serial. It _should_ behave the same with the PC UART, _but_ there can be small differences in the acceptable margins. If (for instance), the other device uses a different sampling strategy, or has the serial timing slightly fast, then the allowable error for the PIC serial being slow, would fall...
If you disable the hardware serial interrupts on a 'per character' basis when sending, then the hardware buffer in the chip, should still allow it all to work. So if you 'wrapper' the software serial transmit function with something like:
Code:

void SoftSend(int8 chr) {
    disable_interrupts(GLOBAL);
    fputc(chr,YOUR_SOFT_STREAM);
    enable_interrupts(GLOBAL);
}

Then use 'printf' with this function, rather than fprintf to drive the software serial, you may find it works.

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group