GSM modem interfacing with 89c51

sir, i am interfacing GSM modem with MSP430.
By sending AT commands, i am sending msg through GSM modem.
GSM modem gives acknoledgement such as if i send "AT" command, GSM modem send acknoledgement "OK" on Hyper terminal.
This acknoledgement i am not recieving on MSP430 controller.
And also i can not able to read msg stored on SIM memory.

sir, i am interfacing GSM modem with MSP430.
By sending AT commands, i am sending msg through GSM modem.
GSM modem gives acknoledgement such as if i send "AT" command, GSM modem send acknoledgement "OK" on Hyper terminal.
This acknoledgement i am not recieving on MSP430 controller.
And also i can not able to read msg stored on SIM memory.
i am expecting that if anyone send sms on SIM that i have inserted in GSM modem, i wnat to read that SMS and store it in Controller memory.

i have same problem on 89c52 also.
that's why i asked on Keil forum.

And how did you expect anyone to know that?

You need to make these things clear in your posts - we cannot read your mind!

Remember: nobody knows anything about you or your project(s) or your hardware or your software other than what you clearly and explicity state in your posts.

If you make confusing and/or conflicting posts, how do you expect people to help you?

Sir, any solution to this problem.

"Sir, any solution to this problem."

Yes, a huge number of them since talk about GSM modules and SMS are covered several times every month on this forum. There are extra many threads about it whenever the schools are busy handing out project assignments.

The big question is: Why should we repeat every answer several times every month? Why can't you instead use the search function and locate a thread already containing suitable answers?

ok. I will search on forum.
Thank you.

No - because it is impossible to tell what the problem is from what little information you have provided!

Again, nobody knows anything about you or your project(s) or your hardware or your software other than what you clearly and explicity state in your posts.

That's why you need to give complete and detailed answers to the questions that I asked you earlier:

What have you tried?

What were the results?

What results were you expecting?

What review, testing, debugging, etc have you done to account for the difference?

One thing we can notice: you say you've tried this on both 89c52 and MSP430, so the problem can't be anything specifically to do with either processor - can it?

There must be something fundamentally wrong with your design.

So you should probably go back to basics, and start again from scratch.

As Per says, this is a very common project so you will find ample reference materials and examples all over the web - including plenty on this very forum.

Basics that you need to start with are:

Hardware connections - check the documentaion for your GSM unit

AT Commands - study the AT Commands manual for your GSM unit and ensure that you thoroughly understand the commands & responses required to achieve your goal.

Note: You need to distinguish the actual "messages" that are sent via SMS from the "commands" that you send to the GSM module and "responses" that you receive from the GSM module...

Well, I guess that's not actually true:

You could (also) have processor-specific faults in each implementation.

It should be obvious that the first thing you need to do is to get reliable serial comms working - sending and receiving characters.

Once you have reliable serial comms working, you can then move on to use that for sending & receiving AT Commands & Responses - which are, after all, just sequences of characters.

The low-level detail of getting serial comms working will be chip-specific, but you could provide a common interface so that the higher-level code can be the same for both processors...

"but you could provide a common interface"

Yes, it's quite common to implement a low-level layer with send/receive support and making use of two ring-buffers of configurable size. Optionally with support for reporting a timeout if no data is received within a given time period or (in case the link uses handshake) if no data has been possible to send for a while.

Even better is to have the receive driver support a configurable record-termination character allowing you to call a get-record function that returns a full record (text line), or timeouted partial data or a "check again later - still receiving data", or finally a "buffer full without termination character".