12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx

Hello,
 
You donot need to cofigure the serial data prompt of sms like CNMI on interrupts. Instead of this you should disable the CNMI reporting feature while you receieve new sms. And you can simply read the new sms in a loop afte a fix interval with CMGR command. Read sms and then delete the sim memmory with CMGD. If you got new message you can parse it. Yes it is the way that include $ sign or some other header to your sms command and then simply parse it.
 
I am also using the same version of compiler and doing sms stuff this way which is ok. here is little routine to check the at command response.
 
int waitResponse(unsigned int16 t){ // This method simply recieves the rs232 response from phone
                                    // while sending the AT-Commands to cell phone              
   int r;
  
   TIMEOUT = T;
   timeoutFlg = 1;
   Index = 0;
  
   do{
      if (kbhit()){
         buf[index] = fgetc(GSM);
         index++;
      }
      delay_ms(1);
      TIMEOUT--;
     }while(TIMEOUT > 0 && TIMEOUT < 31000 && index<50);
   BUF[INDEX]='\0';
        
   r = 0 ;
   if(STRstr(BUF,sSen)>0){    // error
      r = 4;
   }else if(STRstr(BUF,SER)>0){  // error
      r = 2;
   }else if(STRstr(BUF,SOK)>0){  // datasent ok
      r = 1;
   }
        
   if(r>0){
      return r;
   }else{
      return 0;
   }
  
}
Regards
Adnan Ahmad
www.technocrafts.com
 



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Reading SMS is as said best done by polling with cmgr, and deleting
after you have executed the command associated with the message etc.

If you want to send a response, some phones dont allow plaintext that
way but need the msg encoded, I suggest you download PDUspy if you do
that, and use it to work out the encoded value of your msg etc.

My phone when I read the msg sends it to my PIC encoded, so I had to
decode it, but in the end I gave up on decoding it and just watched
for byte values in the msg as it was faster and less steps, downside
of this is command messages sent to the phone must be in correct
format etc, IE ''windowclose''' would not be the same byte
sequence as ''windowclose'' or ''windowclose'' as
it be shifted by 7 bits and reversed nibble ordered........

Because of this I made the pic send an ''OK'' to all msgs it
understood, with confirmation of its actions.

I'd recommend checking the value of the originating phone number, so
it does not receive commands from ''another source'', I have this
allowed for 5 numbers, one master number, and four slaves, which the
master number can change by sms etc.

One day I will get it off the test bed and in my car...........

Reason for this, ever got into the far side of the mall and cant
remember if your locked the car.......

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )