| View previous topic :: View next topic |
| Author |
Message |
jfk1965
Joined: 21 Oct 2003
Posts: 58
|
| Do I need to use the Invert option? |
 Posted: Tue Jan 16, 2007 6:31 am |
 |
|
Hi
I'm doing a simple one wire RS232 interface between two pics they are only 3" apart on a pcb so I figured this was the easiest way.
My question is do I need to use the INVERT option on the #USE RS232 statement?
JFK |
|
 |
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
| Re: Do I need to use the Invert option? |
| Posted: Tue Jan 16, 2007 6:36 am |
|
|
| jfk1965 wrote: | | My question is do I need to use the INVERT option on the #USE RS232 statement? |
No, you shouldn't need INVERT option. As long as the PICs have the same INVERT option setting (either both have INVERT or both don't have it). the serial link should work. |
|
|
davekelly
Joined: 04 Oct 2006
Posts: 53
Location: Berkshire, England
|
|
| Posted: Tue Jan 16, 2007 6:38 am |
|
|
What you need is actually cross-over, where the Tx on 1 PIC is connected to the Rx on the other, and vice versa.
The invert parameter is to (as it says) invert the polarity - ie all the 1 bits become 0's and vice versa. Used if you have an inverting buffer on the input of the receiver. It is only available for software implementations of the UART as well. |
|
|
jfk1965
Joined: 21 Oct 2003
Posts: 58
|
|
| Posted: Tue Jan 16, 2007 6:58 am |
|
|
I have TX and Rx set as the same Pin on both Pics as the communication is one way only. Seem to be having difficulty with the kbhit() as it never recognises that there is anything there I have the FLOAT_HIGH option set in my RS_232 statement full statement as below.
| Code: | | #USE_RS232(baud = 9600, float_high,xmit = pin_A4, rcv = pin_A4) |
This is on the PIC receive the data, the PIC sending is the same except for the RCV & xmit pins set to pins B1.
This is the first time I've used RS232 or any comms between devices so please bare with me.
JFK |
|
|
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
|
| Posted: Tue Jan 16, 2007 8:50 am |
|
|
| jfk1965 wrote: | I have TX and Rx set as the same Pin on both Pics as the communication is one way only.
| Code: | | #USE_RS232(baud = 9600, float_high,xmit = pin_A4, rcv = pin_A4) |
|
That could be confusing the compiler. Try leaving out rcv (or xmit).
| Code: |
#USE_RS232(baud = 9600, float_high, xmit = pin_XX) // transmittign PIC
#USE_RS232(baud = 9600, float_high, rcv = pin_YY) // receiving PIC
|
|
|
|
davekelly
Joined: 04 Oct 2006
Posts: 53
Location: Berkshire, England
|
|
| Posted: Tue Jan 16, 2007 9:05 am |
|
|
Which PIC are you using?
Many PIC's have RA4 as an open collector output - a pull-up resistor is needed when using as the output for the Tx line. |
|
|
jfk1965
Joined: 21 Oct 2003
Posts: 58
|
|
| Posted: Tue Jan 16, 2007 9:36 am |
|
|
| davekelly wrote: | Which PIC are you using?
Many PIC's have RA4 as an open collector output - a pull-up resistor is needed when using as the output for the Tx line. |
I'm using the 16F737 (Pin RA1)for transmitting and the 18F4580 (Pin RA4)for receiving, I have a 1K pullup to the 5V.
The 737 is running at 4MHz and the 4580 @ 20MHz but having the USE DELAY statement set correctly means this won't be a problem right?
Any more suggestions?
Thanks
JFK |
|
|
jfk1965
Joined: 21 Oct 2003
Posts: 58
|
|
| Posted: Tue Jan 16, 2007 10:13 am |
|
|
Here's my simple transmit and receive programs can you check them over to see if I've done anything wrong please.
Transmit
| Code: |
#include <bms.h>
#include <stdlib.h>
//device 16F737
//written on compiler version 3.245
#use rs232(baud=9600, float_high,bits=9, xmit = PIN_A1, rcv = PIN_A1)
int batt = 150;
void main()
{
setup_adc_ports(AN0);
setup_adc(ADC_CLOCK_DIV_2);
setup_counters(RTCC_INTERNAL,RTCC_DIV_16);
enable_interrupts(global);
Do
{
putc(batt);
}
while(1);
}
|
Receive
| Code: |
#include <18f4580.h>
#include <can-18xxx8.c>
#fuses HS,NOPROTECT,NOLVP,NOWDT
#use delay (clock=20000000)
#use rs232(baud=9600,float_high,bits=9,xmit = PIN_A4,rcv = PIN_A4)
int packv;
main()
{
setup_adc_ports(AN0_to_AN5);
setup_adc(ADC_CLOCK_DIV_2);
setup_counters(RTCC_INTERNAL,RTCC_DIV_16);
enable_interrupts(global);
do
{
//get pack voltage from RS232
If(kbhit())
{
packv = getc();
}
}
while (1);
|
Any pointers would be really helpful
thanks
JFK |
|
|
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
| questions |
| Posted: Tue Jan 16, 2007 10:16 am |
|
|
How do you determine that the character has bee received or not?
Do you see serial data bits on the scope? |
|
|
jfk1965
Joined: 21 Oct 2003
Posts: 58
|
| Re: questions |
| Posted: Tue Jan 16, 2007 10:36 am |
|
|
| kender wrote: |
Do you see serial data bits on the scope? |
No I don't thats why i'm wondering what I've done wrong, i've diconnected from the Recv PIC and nothing changes so it's nothing to do with that.
Getting a bit stumped now would like to have cracked this today but might have to work a bit longer at it.
JFK |
|
|
tojape
Joined: 14 Jan 2007
Posts: 20
Location: Hungary
|
|
| Posted: Tue Jan 16, 2007 10:44 am |
|
|
First try to localize the problem. (tx side or rx side)
If you have an oscilloscope you may observe your TX side. Transmitting a 0x55 char continuously (1stopbit no parity) will result a baudrate/2 freq rectangle signal with 50% duty cycle. (There are free oscilloscope progs utilizing a sound card input which is far enough at this frequency range if you don't have one)
Having checked the transmit side you may follow with the receiving side. Write a small prog which has the only task to receive on your rx pin and transmit the received data on another pin. Observe the output signal with the oscilloscope.
If you get the sufficient result, there must be something wrong in your original code.
Note that receiving and transmitting on a simple IO pin is very sensitive to interrupts, because the timing is highly affected by the time elapsed during the interrupt handling (ie. the time spent in an interrupt servicing function)
Best wishes,
tojape
_________________
The computer helps solving the problems which would have never arised without computers |
|
|
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
|
| Posted: Tue Jan 16, 2007 10:56 am |
|
|
| tojape wrote: | | First try to localize the problem. (tx side or rx side) |
I think, it's the TX side, because JFK had disconnected the RX, but still he couldnt't see the bits with the scope. At least he should have seen the start or stop bits. My feeling is that the compiler (or the PIC) is confused bye the fact that the #use rs232 specifies one and the same pin as both xmit and rcv. How is it supposed to figure out, whether the pin is input or output ? 
JFK, try removing the "rcv = PIN_A1" from the TX PIC code, don't insert the RX PIC and look at the serial output with the oscope. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jan 16, 2007 11:02 am |
|
|
Most of the code shown in the two posted test programs is unnecessary.
1. You're not using the CAN bus, you're testing serial i/o. Delete the
#include line for the CAN driver.
2. You're not using stdlib.h. Delete the #include line for it.
3. There's no reason for setting the bits = 9. You're sending an 8 bit
value.
4. You're not using the A/D or the timer. There's no reason to set them
up. They are disabled by default upon power-on reset.
5. You're not using interrupts and you have no interrupt handler.
You should not be enabling interrupts at all.
6. There's no reason for the call to kbhit(), as getc() waits for an
incoming byte anyway. It incorporates kbhit().
7. In the 16F737 code, the #fuses and #use delay statements are
concealed in another .h file. They should be openly shown in a
test program.
8. There's no reason for a do-while() statement. A simple while(1)
statement will work.
My rule is, in test programs, go ultra-simple. Make everything visible.
Look at the data sheet and the .LST file. Find out what's wrong. |
|
|
jfk
Guest
|
|
| Posted: Tue Jan 16, 2007 3:23 pm |
|
|
| PCM programmer wrote: | Most of the code shown in the two posted test programs is unnecessary.
1. You're not using the CAN bus, you're testing serial i/o. Delete the
#include line for the CAN driver.
2. You're not using stdlib.h. Delete the #include line for it.
3. There's no reason for setting the bits = 9. You're sending an 8 bit
value.
4. You're not using the A/D or the timer. There's no reason to set them
up. They are disabled by default upon power-on reset.
5. You're not using interrupts and you have no interrupt handler.
You should not be enabling interrupts at all.
6. There's no reason for the call to kbhit(), as getc() waits for an
incoming byte anyway. It incorporates kbhit().
7. In the 16F737 code, the #fuses and #use delay statements are
concealed in another .h file. They should be openly shown in a
test program.
8. There's no reason for a do-while() statement. A simple while(1)
statement will work.
My rule is, in test programs, go ultra-simple. Make everything visible.
Look at the data sheet and the .LST file. Find out what's wrong. |
The need for the RS232 was a late addition to the project, I do use the CAN,A/D etc in the main project but once there was a problem with adding the RS232 I removed all the other code to create a test program.
I will try all suggestions in the morning and see if there are any improvements.
I programmed a 2nd PIC and I could see the serial data on the TX pin of the 737 but I didn't have time to do anything else before I had to go.
JFK |
|
|
jfk1965
Joined: 21 Oct 2003
Posts: 58
|
|
| Posted: Wed Jan 17, 2007 5:01 am |
|
|
I tried all of PCM's suggestions and it didn't transmit at all, the culprit was the while only loop, putting it back to the DO - While loop it start transmitting again.
So now to work on the receiving.
JFK |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
