GSM interface with 8051 microcontroller

But the AT commands are not really any more advanced than normal printf() output. If is first when you start with ppp to establish IP communication that the controller-side software will explode in size/complexity.

The only potential obstacle may be to handle unsolicited messages from the modem. They may require some synchronization relative to your use of the AT commands.

There are a large number of applications around the world that is communicating with modems using normal serial ports, or just having stdin/stdout redirected to a modem. Google for code. Read the code. Understand what they are doing. Apply to your own hardware.

The only really machine-specific part is the serial read/write code, and the processing of potentially specific AT commands your _your_ modem.

There is no requirement to use a multithreaded application to handle the AT commands. It is just a question of issuing the commands and synchronize the queries with regularly checks of received data from the same serial port.

And as I already said - if you have an evaluation kit, you can normally connect the GSM phone/module directly to a PC and use whatever terminal program you have available to check out the specific AT commands. If you do not have an evaluation kit, I would recommend that you build the required glue hardware to allow you to connect the modem to a RS232 port on the PC. Note the requirements for supply voltages, signal levels on the I/O signals etc.

Contact the supplier for the AT command reference for the modem. If that isn't available from the supplier, consider using another phone/modem, or google for other users who have been programmed the specific unit, and check if they have either documentation or source code.

If no AT command reference can be found - check for command references for similar products from the same manufacturer, and check with a PC of those commands do work with your modem. If not, definitely switch to another phone/module!

But the AT commands are not really any more advanced than normal printf() output. If is first when you start with ppp to establish IP communication that the controller-side software will explode in size/complexity.

The only potential obstacle may be to handle unsolicited messages from the modem. They may require some synchronization relative to your use of the AT commands.

There are a large number of applications around the world that is communicating with modems using normal serial ports, or just having stdin/stdout redirected to a modem. Google for code. Read the code. Understand what they are doing. Apply to your own hardware.

The only really machine-specific part is the serial read/write code, and the processing of potentially specific AT commands your _your_ modem.

There is no requirement to use a multithreaded application to handle the AT commands. It is just a question of issuing the commands and synchronize the queries with regularly checks of received data from the same serial port.

And as I already said - if you have an evaluation kit, you can normally connect the GSM phone/module directly to a PC and use whatever terminal program you have available to check out the specific AT commands. If you do not have an evaluation kit, I would recommend that you build the required glue hardware to allow you to connect the modem to a RS232 port on the PC. Note the requirements for supply voltages, signal levels on the I/O signals etc.

Contact the supplier for the AT command reference for the modem. If that isn't available from the supplier, consider using another phone/modem, or google for other users who have been programmed the specific unit, and check if they have either documentation or source code.

If no AT command reference can be found - check for command references for similar products from the same manufacturer, and check with a PC of those commands do work with your modem. If not, definitely switch to another phone/module!

Just type "GSM" into the search box; it's all been covered here before - and very recently!