![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
chancaar
Joined: 23 Mar 2004 Posts: 6 Location: Belgium
|
Difference between TX/RX and normal I/O with #use RS232 ??? |
Posted: Sun May 30, 2004 2:27 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
dfnr2
Joined: 26 Dec 2003 Posts: 2
|
|
Posted: Sun May 30, 2004 7:05 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
chancaar
Joined: 23 Mar 2004 Posts: 6 Location: Belgium
|
|
Posted: Mon May 31, 2004 8:07 am |
|
|
I use a 20 MHz clock speed... and I'm using a MAX233 to transform the level. _________________ Yves Willemaers
Belgian student |
|
![](templates/subSilver/images/spacer.gif) |
rwyoung
Joined: 12 Nov 2003 Posts: 563 Location: Lawrence, KS USA
|
|
Posted: Mon May 31, 2004 8:45 am |
|
|
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! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
Re: Difference between TX/RX and normal I/O with #use RS232 |
Posted: Mon May 31, 2004 8:47 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|