Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

GPS and GSM interrupt handling

Status
Not open for further replies.

emkay

Junior Member level 2
Joined
Feb 16, 2005
Messages
21
Helped
1
Reputation
2
Reaction score
0
Trophy points
1,281
Activity points
1,494
uart read write gps

Currently I try to develop tracking system, which use dual USART using PIC16F628A, I used hardware USART and also software USART. The software USART handle the data receiving from GPS while the hardware to receive and transmit the data to/from GSM modem.

The system flow is to receive data from GPS and store into EEPROM (24LC512) then transmit the data through GSM modem after dedicated period (might be 24hrs). I’ll set the interval for receiving the data form GPS for a minute (may change later).

Instead of transmitting the data for fixed period, the ‘server/user’ can request the data at anytime.

Both of my USART routine use interrupts to handle the task, but I have a problem to manage this thing. My plan is after receive the interrupt for GPS, I’ll filter the data to meet my requirement (time and location only), and then store/write that data to the 24LC512 and the system will wait for the interrupt from hardware USART (a call from ‘user’) for a less than a minute (because my interval to receive the GPS data is one minute…I do not want to ‘disturb’ my data collection).

My question is, what will happen if during receiving the GPS data, the second interrupt (hardware USART) occurred, what would PIC do? Continue collecting data (because still in external interrupt) OR will respond to the second one?

I want my PIC, finished the first task (receive- filter  store to 24LC512) before respond to the second interrupt. So how to do this? …How to give priority to the first interrupt?

And it will be same case if my hardware USART interrupt occurred first then suddenly the data from GPS coming…I want my hardware USART settle the job first before proceed to the receiving the GPS data. The task under USART hardware is…(receive call form ‘user’ pickup the ‘phone’ read data from 24LC512  transmit the data)

Both case need to settle the first one before proceed to the second interrupt…

Your comment and advice are highly appreciated…

If there are similar reference project, please forward to me.

Thanks in advance
 

gsm interrupt

Hi,
If you are using a standard GPS receiver, you may want to disable all the messages except those that you need. (RMC and one more should be sufficient) and then there is no need of filtering. As you may know, USART interrupt shall be more critical than the GPS.
hope this helps,
brmadhukar
 

gps handling process

If you are using a standard GPS receiver, you may want to disable all the messages except those that you need. (RMC and one more should be sufficient) and then there is no need of filtering

meaning that i can set manually which data i want to receive..but how...by software or what?...thanks..

.
As you may know, USART interrupt shall be more critical than the GPS.

but i do not want USART interrupt disturb my GPS data, in case interrupt happen during receive GPS data...

pls advice...
 

gps handling

I dont understand why you need interupts?

I will suggest a different approch that it might help (I am not experience with interrupts or very good in programming)

- First thing to do is to query the GPS (ask the GPS to send to the PIC the current data) and store this data to eeprom. This might take place at any predefine interval.
- Then ask the mobile phone for any (if any) new incoming SMS. Decode the SMS in order to see if it requests something. If so then read eeprom and send it to SMS receipient.
- Repeat cycle or do something else.

In Picbasic pro this command works as:
HSerout ["AT+CMGL=0",cr] Read Received and Unread Incoming messages only.

If there is no new message then nothing is going to PIC.

I hope it helps a little.
Regards
 

gsm handling sms interrupt

Yes, you can send the control command to GPS to select which command do you want to receive or suppress.
You may need to look in the GPS manual. It depends on the manufacture and which protocol you use NMEA, SiRF etc.
 

interrupt pic gsm software

Hi

I have a simple solution all you have to do is to colect the data into buffer 's during inerrupt and process the data in the main loop - the main loop is mutch faster then any inerrupt


All the best

Bobi
 

gps+interrupt

If you do not use rtos - you have to implement long ring buffers to keep whatever received from USART there .
If you have rtos - there is nothing you have to worry about .
 

gsm modem uart interrupt

Most GPS receivers can be configured, the time period at which they will output messages is programable. This can be from 0 (no data output) to several seconds. Check the config messages from the module datasheet. If you set the output period to 0, then you can ask the receiver to output the data at any moment. This is pooling. You can do the same with the GSM terminal, and thus you can handle both of them, and you will avoid conflicts. Another issue is the 24LC memory in which you want to store the GPS data ( I suppose you will process GGA sentence or its equivalent in the binary protocol). If you read the GPS fix data and write it to the memory every minute, you will perform a lot of writings in the memory. Check the datasheet of the memory's manufacturer, every such memory has a maximum number of write cycles. If you will write to it every minute, this means approx. 44.000 times every monts. With a memory which supports 100.000 write cycles, you will have a problem in less than three months.

/pisoiu
 

nmea receiver in pic18 c

I have a simple solution all you have to do is to colect the data into buffer 's during inerrupt and process the data in the main loop - the main loop is mutch faster then any inerrupt

i can't get the picture...could you give me more ideas to do this?..thanks..

Another issue is the 24LC memory in which you want to store the GPS data ( I suppose you will process GGA sentence or its equivalent in the binary protocol). If you read the GPS fix data and write it to the memory every minute, you will perform a lot of writings in the memory. Check the datasheet of the memory's manufacturer, every such memory has a maximum number of write cycles. If you will write to it every minute, this means approx. 44.000 times every monts. With a memory which supports 100.000 write cycles, you will have a problem in less than three months.

i will check it..for reference...i'll take 52 bytes for every minutes...wait a minute..100k write cyles means ..1 byte / cycle?...
 

nmea gps data decode pic18 c

100k cycle means same location (byte-any) can be written 100k times. After that, it is not sure that what you read back is what you wrote.

/pisoiu
 

gps and start interrupt

I decide to not use interrupt for software USART (external interrupt) anymore but still uses interrupt for hardware USART.

The condition will be like this; hope can get your comment.

1. Wait for GPS data (bit test at receiver port)
2. After receive, process the data, which is store it to temp. register
3. Write to EEPROM
4. Enable interrupt (for hardware USART)
5. Delay 1 minute (interval for next GPS data)
- Here I have 2 option but I do not know which one is better
- To use delay by software routine (I use PICLoop)
- To use TMR1
6. Disable interrupt
7. Repeat

I do not know which one is the ‘best’ for the item no. 5. My requirement is, if USART interrupt happen, the ‘delay/timer’ still count so that I’ll not miss my 1-minute interval…

And if the TMR1 is more effective compare to the delay routine, how to do it. I never use timer module before…thanks
 

picbasic pro hserout

any idea?...

is there any tutorial on TIMER...thanks
 

transmitting data from pic to 24lc512

hello
You should know that the pic MC will not go to make other interrupt as long as the current interrupt is not finished yet
this is because when the interrupt occur - flag biit of a certain interrupt is set- the oic will go to the interrupt vector (0x004) and the GIE bit will be cleared.
Beacuse of that , no other interrupt can be handled as long as the procedure of the current interrupt is still processing but they could be sensed and their falg bit is affected
After the end of interrupt, we should exeute the "retfie" command which have 2 functions : first making a regular return second : re-enable the GIE bit
at this time if any other interrupt is pending, it will be handled according to the order of coding by which you asign the piorty for each interrupt.
 

Hello

If you want use interrupt,so do flags
How???

When the interrupt from GPS occurred do:
1- Receive the NMEA Command and store it in RAM.
2- Set Flag bit.
3- Return.


in main program:
1- chk the GPS flag bit.
2- if bit set :

a- filter the data.
b- store the data in your serial EEPROM
c- clr bit


and do this again with mobile

:D HO2a
 

haytham said:
hello
You should know that the pic MC will not go to make other interrupt as long as the current interrupt is not finished yet
this is because when the interrupt occur - flag biit of a certain interrupt is set- the oic will go to the interrupt vector (0x004) and the GIE bit will be cleared.
Beacuse of that , no other interrupt can be handled as long as the procedure of the current interrupt is still processing but they could be sensed and their falg bit is affected
After the end of interrupt, we should exeute the "retfie" command which have 2 functions : first making a regular return second : re-enable the GIE bit
at this time if any other interrupt is pending, it will be handled according to the order of coding by which you asign the piorty for each interrupt.

Not completely true. You can clear the interrupt flag and reenable the GIE bit in the interrupt routine. At that point another interrupt will interrupt the interrupt. This is really handy to make one interrupt a higher priority than the other. You just have to be careful about context handing (i.e. high priority interrupts must save WREG, STATUS, FSR, etc. to a different place than low priority interrupts since they can interrupt low priority interrupts).

Some PIC18 devices have a high priority interrupt and a low priority interrupt and do this for you.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top