 |
 |
| View previous topic :: View next topic |
| Author |
Message |
zenjhen
Joined: 26 Sep 2003
Posts: 3
Location: Albuquerque
|
| 877 and GPS data/ senior design project |
 Posted: Fri Oct 31, 2003 9:39 pm |
 |
|
i'm having difficulties with understanding how the
#use rs232 works.
i am tring to request and receive an ASCII string from a Motorola GPS module. i'm using a RS232 chip and have verified that the comm pins are hooked up correctly. As far as I can tell, the GPS is getting the request (the RX led lights up). Now I realize that the data I am requesting is mixed into a constant stream of TX, so I will have to deal with getting the right data later, but right now, I would just like to be able to get ANY data. i get hung up on the first or sometimes second getc(). I know I need a buffer, but how is this done? I must need to use the USART. How is this done? not too sure about khbit() either... How does getc() work with use RS232
I am looking for suggestions or explanations!!!!
Thanks for the time...
| Code: |
#include <16F877.h>
#fuses HS,NOWDT,PUT,NOPROTECT,NOLVP
#use delay(clock=10000000) //set clock speed 10MHz
#include <k_lcd.c>
#zero_ram //clear ram
#case
#include <stdlib.h>
// ----- Function Prototypes
#define txToGPS PIN_C6 //pin 25
#define rxFromGPS PIN_C7 //pin 26
float velocity;
float heading;
#use rs232 (BAUD=9600 , XMIT=txToGPS, RCV=rxFromGPS, BRGH1OK)
//just took a stab and through in BRGH1OK cuz i though it might help with timing issues
char smart_comm(void)
{
long timeout;
timeout = 0;
while (!kbhit()&&(++timeout<50000))
delay_us(10);
if (kbhit())
return (getc());
else return 0;
} //end smart_comm
void parse_gps_data(void)
{
char in1[69]; // i would like to have [96] here but run out of RAM
char in2[27]; // is there any way to allocate memory differently to make room
char c;
int i;
// first send the request to the GPS
puts("@@Eq01");
lcd_putc("\fSent Request");
// do we need to wait here some minimum time frame???
// snarf all the data from the GPS unit
for (i = 0; i < 69; i++)
{
printf(lcd_putc, "\ffirst loop: %d", i);
c = smart_comm();
if (c == 0)
{
lcd_putc("\fbad comm"); //getting stuck here
return;
}
in1[i] = c;
}// end for 69
for (i = 0; i < 27; i++)
{
printf(lcd_putc, "\fsecond loop: %d", i);
c = smart_comm();
if (c == 0)
{
lcd_putc("\fbad comm in 2");
return;
}
in2[i]=c;
} //end for 27
} // end get gps data
void report_gps_data(void)
{
}
void main(void)
{
int i;
lcd_init();
while(1)
{
delay_ms(1000);
parse_gps_data();
report_gps_data();
}
} |
|
|
 |
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Sat Nov 01, 2003 12:26 am |
|
|
| Search this board for lots of examples on how to use buffers, interrupts for serial communication. You should also include the errors parameter in your RS232 statement in case you have a buffer overrun which could cause your program to hang. I would also suggest that you use Hyperterminal instead of your GPS to debug with until you get your communication routines working correctly. |
|
|
Ttelmah
Guest
|
| Re: 877 and GPS data/ senior design project |
| Posted: Sat Nov 01, 2003 7:41 am |
|
|
| zenjhen wrote: | i'm having difficulties with understanding how the
#use rs232 works.
i am tring to request and receive an ASCII string from a Motorola GPS module. i'm using a RS232 chip and have verified that the comm pins are hooked up correctly. As far as I can tell, the GPS is getting the request (the RX led lights up). Now I realize that the data I am requesting is mixed into a constant stream of TX, so I will have to deal with getting the right data later, but right now, I would just like to be able to get ANY data. i get hung up on the first or sometimes second getc(). I know I need a buffer, but how is this done? I must need to use the USART. How is this done? not too sure about khbit() either... How does getc() work with use RS232
I am looking for suggestions or explanations!!!!
Thanks for the time...
|
As another poster has said, look for examples (several have been posted on this board), of serial buffer handling.
Other comments:
1) You don't want your buffer to be larger than it needs to be. Basically look to having a buffer large enough to hold the longest expected reply. Much larger buffers being needed are a sign of something else being wrong.
2) Add the line "#device *=16" at the top of the code immediately after the first include. Without this, your total RAM is limited to one page. This gives smaller and faster code, but severely restricts your RAM useage. This is why it wouldn't accept the larger buffer.
3) Look especially, for a code example from Neutone, which shows how to use a combination of a serial ISR, buffer, and timer, to handle comms with a timeout. Exactly what you need.
4) You shouldn't really need to use BRGH10K with a 10MHz clock, and 9600bps, on a 16F877.
Note that #zero_ram, adds a lot of boot overhead, and is not really needed. The compiler will allways zero 'global' declarations, and others can be set as required. Generally, it is faster to make buffers global (which then results in them being zeroed automatically), especially since the real 'need' for a buffer comes with interrupt driven comms, where the data then needs to be available to the other code.
Best Wishes |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Sat Nov 01, 2003 8:19 am |
|
|
| Quote: |
Note that #zero_ram, adds a lot of boot overhead, and is not really needed. The compiler will allways zero 'global' declarations, and others can be set as required. Generally, it is faster to make buffers global (which then results in them being zeroed automatically), especially since the real 'need' for a buffer comes with interrupt driven comms, where the data then needs to be available to the other code.
|
I know back in the 2.xxx days this statement would have been incorrect. None of my Global Vars were initialized unless I did it myself. I choose to use the zero_ram option rather than explicitly declaring their values to be 0. It took up less code that declaring each of them and the zero_ram code was only about 30 or so instruction.[/code] |
|
|
Ttelmah
Guest
|
|
| Posted: Sat Nov 01, 2003 11:30 am |
|
|
| Mark wrote: | | Quote: |
Note that #zero_ram, adds a lot of boot overhead, and is not really needed. The compiler will allways zero 'global' declarations, and others can be set as required. Generally, it is faster to make buffers global (which then results in them being zeroed automatically), especially since the real 'need' for a buffer comes with interrupt driven comms, where the data then needs to be available to the other code.
|
I know back in the 2.xxx days this statement would have been incorrect. None of my Global Vars were initialized unless I did it myself. I choose to use the zero_ram option rather than explicitly declaring their values to be 0. It took up less code that declaring each of them and the zero_ram code was only about 30 or so instruction.[/code] |
It is one of the areas, that is annoying/fun... :-(
If you look under the definitions for 'data types', even on V2.xxx, it states that the 'static' qualifier (if used), makes the variable global, and initialised to zero. However on V2.xxx, they didn't initialise normal global variables this way. Later they switched to this initialisation, and it is a pain!. If you have a system that is designed to 'soft recover' from a watchdog restart, you can fnd variables being initialised on the restart.
I complained to CCS about this, when the initialisation was changed, and there reply was that the manual said that global variables would be initialised to zero (it doesn't, it says that ones using the 'static' keyword will be).
Though #zero_ram, may only be a few dozen instructions, it adds a lot of _time_ (it loops). Even on small chips, think in terms of perhaps 1000 instructions, while on chips with several hundred bytes of RAM, it can add sufficient code to make it impossible to start without a watchdog timeout!. On a 18F452, the extra code, is 4608 instructions during the boot.
Unfortunately, the code is 'thick'. The compiler initialises the same area twice (if the variables are global).
Realistically, it is a matter of 'taste', but I'd prefer no default initialisation, and options for #zero_ram, to control whether this initialised all memory, or just static variables.
In the end, I avoided the default initialisation, by manually 'locating' variables into a RAM area I reserved.
Best Wishes |
|
|
Guest
Guest
|
| GPS |
| Posted: Wed Nov 05, 2003 12:28 am |
|
|
| Be aware that a lot of GPS units run at 4800 baud. This may be a problem. |
|
|
atabac_2000
Joined: 21 Apr 2004
Posts: 10
|
| GPS programming experience |
| Posted: Sat Aug 28, 2004 2:34 pm |
|
|
| hi! does anybody here experienced with GPS programming with PIC? I would like to seek advices on the material i need to buy during development of such programs thank you |
|
|
dyeatman
Joined: 06 Sep 2003
Posts: 1912
Location: Norman, OK
|
| Interrupt Buffer Example |
| Posted: Sat Aug 28, 2004 5:59 pm |
|
|
| See the exampe EX_SISR.C in the examples directory for the interrupt buffer example. |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
