|
|
View previous topic :: View next topic |
Author |
Message |
newby
Joined: 26 Sep 2004 Posts: 32
|
strange RS232 problem |
Posted: Sun Sep 26, 2004 5:11 am |
|
|
Hello !
...i am trying my first RS232 project and having strange troubles.
I use the hardware uart of a 18F452 for receiving at 4800 baud data from another pic (18F1320) which is sending the data. Both running with each a 8 MHz crystal resonator. I use the same RS232 settings (9 Bits, no parity, same baud rate(4800), hw pins) on both chips.
The problem is, that if i send more than one char, the receiver (18F452) is receiving only garbage after the 1st char.
If i send a string char by char with delays, the string is being received correctly.
I have tried different baud rates, with MAX2323 and with out, i also tried sending the data directly from my laptop which lead to the same result.
I tested "khbit" and also the interrupt method to look for a new char, but it doesn�t change anything.
I think it looks like a timing problem, but what is wrong ?!? My main progam does nothing than waiting for the data (or sending it). Therefore i guess the data baud rates are incorrect - but what could i do ? I also tried to use the BRGH1OK optin in the #use RS232 but i didnt help ?!?
Thank�s for any help... |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1636 Location: Perth, Australia
|
|
Posted: Sun Sep 26, 2004 5:18 am |
|
|
The laptop will not know what do do with 9 bits unless the 9th bit is a 1 (space aka idle). Try repeating your tests after selecting 8 bits. |
|
|
newby
Joined: 26 Sep 2004 Posts: 32
|
|
Posted: Sun Sep 26, 2004 6:07 am |
|
|
Ok, i have set the #use RS232 bits to 8 and now i am able to receive the data from laptop correctly, but it still doesn�t work from PIC to PIC (i have changed the bit# on both pics to 8 ).
Is it a mistake, if i only connect the according transmit pin (18F1320 is sending data) with the receive pin (18F452 should receive data) without connecting the transmit pin from the 18F452 with the receiver pin from the 18F1320 ? I didn�t do it because i only use one direction...
Thank�s for your great help ! |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1636 Location: Perth, Australia
|
|
Posted: Sun Sep 26, 2004 6:54 am |
|
|
A single transmit and receive is ok. Did you mean the Laptop now RECEIVES data from the PIC?
How about posting some code so I can have a look. |
|
|
Guest
|
|
Posted: Sun Sep 26, 2004 8:01 am |
|
|
I don�t use one pin for receiving and sending, but i only connected the receive PIN from the 18F452 (receiver) with the transmit PIN from the transmitter 18F1320 - the other way (from 18F452 to 18F1320) is disconnected.
i am able to send data FROM the laptop to the 18F452 without problems now, but still not from 18F1320 to 18F452.
..here comes the code (i reduced the code to the real problem, data is only dummy...)
18F1320: should provide GPS test data and send it to the 18F452
#zero_ram
int32 dummy_counter;
int8 time;
void main() {
disable_interrupts(global);
setup_wdt(WDT_OFF);
port_b_pullups(TRUE);
while (TRUE) {
dummy_counter++;
if (dummy_counter == 450000) {
time++;
#use rs232(baud=4800, parity=N, xmit=PIN_B1, rcv=PIN_B4, bits=8)
printf("$GPRMC,%u,A,B,N,9.3,E,a,,q,0.4,E,A*19", time);
dummy_counter = 0;
}
}
}
***********************************************
18F452: should receive GPS data and temp "store" it for further operation
#ZERO_RAM
#define max_char_anz 40
int1 new_char;
int8 char_counter;
char GPS_data[max_char_anz], char_dummy;
#use rs232(baud=4800, parity=N, xmit=PIN_C6, rcv=PIN_C7, bits=8, stream = GPS)
#int_RDA
RDA_isr() {
new_char = 1;
char_dummy = fgetc(GPS);
}
void main() {
port_b_pullups(TRUE);
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_psp(PSP_DISABLED);
setup_spi(FALSE);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL);
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL);
while (TRUE) {
if (new_char) {
new_char = 0;
if (char_counter < max_char_anz) {
GPS_data[char_counter] = char_dummy;
} else {
char_counter = 0;
GPS_data[char_counter] = char_dummy;
}
char_counter++;
}
}
} |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1636 Location: Perth, Australia
|
|
Posted: Sun Sep 26, 2004 8:16 am |
|
|
Could you send the fuse lines. Note that the 32 bit integer 'dummy_counter' is not initialised (maybe CCS sets non initialised variables to zero - i don't know) however, if not then the first iteration of the loop could take a very long time. |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Sun Sep 26, 2004 8:38 am |
|
|
asmallri wrote: | (maybe CCS sets non initialised variables to zero - i don't know) |
Not unless you tell it to. See #zero_ram compiler directive. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
drh
Joined: 12 Jul 2004 Posts: 193 Location: Hemet, California USA
|
|
Posted: Sun Sep 26, 2004 10:04 am |
|
|
In you RDA interrupt routine try:
new_char = 1;
char_dummy = RCREG; _________________ David |
|
|
newby
Joined: 26 Sep 2004 Posts: 32
|
|
Posted: Sun Sep 26, 2004 10:32 am |
|
|
The "dummy_counter" var is only to send a "GPS sentence" about every second, nothing more, this code shoes only the part which is malfunctioning...
the #fuses comes direct from the "project -> PIC WIZARD"
transmitter:
#include <18F1320.h>
#use delay(clock=8000000)
#fuses NOWDT, H4, NOFCMEN, NOBROWNOUT, PUT, NOCPD, STVREN, NODEBUG, NOLVP, WRT, NOWRTD, WRTC, IESO, NOEBTR, NOEBTRB, NOMCLR, PROTECT, CPB, WRTB
receiver:
#include <18F452.h>
#device ICD=TRUE
#use delay(clock=8000000)
#fuses NOWDT,WDT128,HS, NOPROTECT, NOOSCSEN, NOBROWNOUT, BORV20, PUT, STVREN, DEBUG, NOLVP, NOWRT, NOWRTD, NOWRTB, NOWRTC, NOCPD, NOCPB, NOEBTR, NOEBTRB
@drh: RCREG doesn�t function -> unkown identifier...
Thanks a lot for your assistance ! |
|
|
drh
Joined: 12 Jul 2004 Posts: 193 Location: Hemet, California USA
|
|
Posted: Sun Sep 26, 2004 12:02 pm |
|
|
Sorry about that.
#BYTE RCREG = 0x0FAE
One of the first things I do when using a new processor is create a xxx.def file. I #include this near the beginning of my source file. This file contains all the special function register addresses and bit definitions. _________________ David |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1636 Location: Perth, Australia
|
|
Posted: Tue Sep 28, 2004 7:19 am |
|
|
Quote: | One of the first things I do when using a new processor is create a xxx.def file. I #include this near the beginning of my source file. This file contains all the special function register addresses and bit definitions. |
I am surprised that CCS does not inlude this in the device file |
|
|
Guest
|
...problem found |
Posted: Wed Sep 29, 2004 10:13 am |
|
|
...the problem was, that i have used the PLLx4 mode in combination with an ceramic resonator as oscillator. After i have swichted off the PLLx4, it worked....
[censored] happens ... thanks a lot for your help ! |
|
|
|
|
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
|