| View previous topic :: View next topic |
| Author |
Message |
raptorman
Joined: 08 Mar 2008
Posts: 12
|
| Serial Port not working on Pic18 explorer board |
 Posted: Sat Jan 05, 2013 3:25 pm |
 |
|
Hi,
I'm trying to use UART2 on the PIC18 Explorer board. I'm hooking up a EM-406 GPS TX to PIN_G2, 5v, GND on the board. I set a breakpoint in my ISR_RDA2 and it gets there meaning the GPS is transmitting. But the character is always 0xF8H or zero. I know the GPS works by using Tera term at 4800 baud. Any Ideas? I'm using 4.140.
| Code: |
#include <18F87K22.h>
#fuses HSM,NOWDT,NOPROTECT,NOPUT,DEBUG
#use delay(clock= 10M)
#use rs232(UART2,baud=4800,PARITY=N,ERRORS)
int16 next_gps_ptr = 0;
boolean sentence = FALSE;
byte gps_buff[128]; // implemented as a circular buffer
#int_rda2
void rda_isr(void)
{
char c;
c = getc();
if (c=='$')
{
sentence=true;
return;
} // new sentence
if(sentence)
{
gps_buff[next_gps_ptr]=c;
if (++next_gps_ptr>sizeof(gps_buff))
{
next_gps_ptr=0; // circular buffer
}
if((c==10)||(c==13))
{
sentence=false;
}
}
}
//========================================
void main()
{
enable_interrupts(INT_RDA2);
enable_interrupts(GLOBAL);
while(1)
{
}
}
|
|
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9226
Location: Greensville,Ontario
|
|
| Posted: Sat Jan 05, 2013 4:02 pm |
|
|
some things to ponder...
1) I'd test the program by using a PC with terminal program instead of the GPS unit, starting off with a simple 'press a PC key ..send to PIC...echo it back to PC screen.
This would verify your code is OK...
2) Does your GPS have TTL or RS232 output? If RS232, do you have a MAX232 or similar on the PIC?
3) Hmm.. what VCC are you running? If 5 Volt PIC, is the GPS also 5 volts?
hth
jay |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Sat Jan 05, 2013 4:12 pm |
|
|
Hi,
Question 3 above is the key. The voltage "swing" of the EM-406 GPS is 0 to
2.85V. If you are running the PIC at 5V, you aren't going to reliably receive
data from the GPS module, and you'll need to add a buffer to boost the
voltage. It's an easy circuit if you need to do it!
See this thread: https://forum.sparkfun.com/viewtopic.php?f=17&t=32650
John |
|
|
raptorman
Joined: 08 Mar 2008
Posts: 12
|
|
| Posted: Sat Jan 05, 2013 4:53 pm |
|
|
I'm running at 5v. So I tried hyperterminal connected using a Sparkfun FTDI running at 5V. Connected the gnd,tx,rx on the ftdi to gnd, tx to rg2 and rx to rg1. Typed a 1 and I received a 0x80h in the ISR_RDA2.
Now in the ISR_RDA2 I have the following instructions:
| Code: |
char c;
c = getc();
putc(c);
|
I type 12345 and it echoes back ?2367 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19513
|
|
| Posted: Sun Jan 06, 2013 3:12 am |
|
|
I'd suggest you probably have two separate problems.
The first is common. It is very usual for the first byte received after wake-up from an external device to be garbage. Several things apply here:
1) Unless the external device wakes up as quickly as the PIC, the RX line on the PIC is often low when the UART is first enabled. Hence a garbage byte gets received.
Solutions: 1) Wait for the RX line to go high, _before_ enabling the UART.
2) Ignore data until you see some standard 'running' marker (STX for example).
3) Flush the UART of any byte received in (say) the first 1/10th second after power on.
4) Beware. Is your clock stable when the chip first starts?. On some chips you have PUT, to delay wake up till the crystal is stable. On others you can test a status bit to verify the oscillator is stable. If not, again the first byte will be corrupted...
On the second, I'd want to be dead sure your chip really is working correctly at 10MHz. The old basic 'flash an LED' test. Make the flash something like every ten seconds, and check with a stopwatch that this is the speed you get. I'd be strongly suspicious that your chip is actually clocking at a different rate to what you think it is.
If you compile code with your fuses, and look at the end of the .lst, you get:
| Code: |
Configuration Fuses:
Word 1: D315 VREGSLEEP INTRC_HP SOSC_DIG NOXINST HSM PLLEN FCMEN IESO
Word 2: 7C7F NOPUT BROWNOUT BORV18 ZPBORM NOWDT WDT1048576
Word 3: 8BF9 RTCOSC_T1 EXTADDRSFT ABW8 BW16 NOWAIT CCP2C1 ECCPE MSSPMSK7 MCLR
Word 4: 0011 STVREN BBSIZ2K DEBUG
Word 5: C0FF NOPROTECT NOCPB NOCPD
Word 6: E0FF NOWRT NOWRTC NOWRTB NOWRTD
Word 7: 40FF NOEBTR NOEBTRB
|
Note 'PLLEN'......
Best Wishes |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Sun Jan 06, 2013 6:46 am |
|
|
| Ttelmah wrote: | | Note 'PLLEN'...... |
I hate it that Microchip for these newer chips has set the default PLL setting to enabled. This is going to generate a lot of problem questions here on the forum.
Just another small bug that will haunt you in the future if you don't fix it: | Code: | | if (++next_gps_ptr>sizeof(gps_buff)) |
Change the '>' to '>='. |
|
|
raptorman
Joined: 08 Mar 2008
Posts: 12
|
|
| Posted: Sun Jan 06, 2013 8:28 am |
|
|
| NOPLLEN solved the problem. Thanks everybody for your help. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19513
|
|
| Posted: Sun Jan 06, 2013 8:33 am |
|
|
Yes. I'd suspect the 'point' is that they feel that PLL operation is/should be the default mode. Given the low power and higher speeds of the later generations of chips, and that all are capable of operating well beyond the maximum frequencies offered by their oscillators, they have made the 'erased' state of the fuses enable the PLL by default.
Best Wishes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
