gsm sim 900

Now your keyboard caps-lock has failed again. You really should go get a new keyboard - "screaming" on forums isn't the best way to get help...

How to send an integer? If you have a channel that doesn't support a binary transfer, then you need to encode the integer. This forum can't handle binary data but I can still send the integer 12345 to you. I just follow the normal encoding conventions on web forums and send it as the ASCII characters '1', '2', '3', '4', '5' after each other. Note that the language have ways of converting between ASCII digits and integer numbers on both directions. And it's also quite simple to "manually" perform the conversion using simple C code. 4103 is 4*1000 + 1*100 + 0*10 + 3*1.
Or in the other direction:
4103/10000 = 0.
4103 - 0*10000 = 4103
4103/1000 = 4
4103 - 4*1000 = 103
103/100 = 1
103 - 1*100 = 3
3/10 = 0
3 - 0*10 = 3
3/1 = 3
3 - 3*1 = 0
Ignore the initial zero and the above got you 4, 1, 0, 3 which forms the decimal number 4103.

Your delay really is quite interesting - programming is the hobby of how to create complex functionality out of simpler primitives. All the way down to the language primitives of the compiler/assembler.

Doing:

delay(1000);delay(1000);delay(1000);delay(1000);

seems pretty silly when it's much easier to do:

delay(4000);

Next thing - it's way better to try to create a delay primitive that has some recognizeable physical property and then reuse it for longer delays. With some physical unit, it's way easier for a reader to understand how long the delay is expected to be.

If you have a function delay_one_ms() then you can implement:

void delay_milliseconds(unsigned ms) {
    while (ms) {
        --ms;
        delay_one_ms();
    }
}

void delay_seconds(unsigned s) {
    while (s) {
        --s;
        delay_milliseconds(1000);
    }
}

void delay_hours(unsigned h) {
    while (h) {
        --h;
        delay_seconds(3600);
    }
}

void delay_days(unsigned d) {
    while (d) {
        --d;
        delay_hours(24);
    }
}

Suddenly, you can with a single call delay_days(65535u) on a 16-bit processor create a delay of more than 179 years - longer than the longest human life. So why have a huge number of delay() calls after each other?

Note of course that a busy-loop delay that just counts clock cycles will give too long delays in more complex designs where the processor may allocate clock cycles to other things - like interrupt processing. That's why it's best to only create very short "at least" delays using busy-loop delays and make use of timers or other hardware to create longer delays with good precision.

I think you need to figure out what you want. You want to learn how to program? Then you can't give up and demand solutions from other people whenever you get stuck. You have to be willing to invest whatever time it takes to learn. As you learn, you'll notice that what you originally thought of as hard is actually quite simple. Just as it's extremely hard to implement walking robots but we humans manages quite well after a bit of training. There is no shortcut to avoid the need for training - you really do need to invest own time!

Now your keyboard caps-lock has failed again. You really should go get a new keyboard - "screaming" on forums isn't the best way to get help...

How to send an integer? If you have a channel that doesn't support a binary transfer, then you need to encode the integer. This forum can't handle binary data but I can still send the integer 12345 to you. I just follow the normal encoding conventions on web forums and send it as the ASCII characters '1', '2', '3', '4', '5' after each other. Note that the language have ways of converting between ASCII digits and integer numbers on both directions. And it's also quite simple to "manually" perform the conversion using simple C code. 4103 is 4*1000 + 1*100 + 0*10 + 3*1.
Or in the other direction:
4103/10000 = 0.
4103 - 0*10000 = 4103
4103/1000 = 4
4103 - 4*1000 = 103
103/100 = 1
103 - 1*100 = 3
3/10 = 0
3 - 0*10 = 3
3/1 = 3
3 - 3*1 = 0
Ignore the initial zero and the above got you 4, 1, 0, 3 which forms the decimal number 4103.

Your delay really is quite interesting - programming is the hobby of how to create complex functionality out of simpler primitives. All the way down to the language primitives of the compiler/assembler.

Doing:

delay(1000);delay(1000);delay(1000);delay(1000);

seems pretty silly when it's much easier to do:

delay(4000);

Next thing - it's way better to try to create a delay primitive that has some recognizeable physical property and then reuse it for longer delays. With some physical unit, it's way easier for a reader to understand how long the delay is expected to be.

If you have a function delay_one_ms() then you can implement:

void delay_milliseconds(unsigned ms) {
    while (ms) {
        --ms;
        delay_one_ms();
    }
}

void delay_seconds(unsigned s) {
    while (s) {
        --s;
        delay_milliseconds(1000);
    }
}

void delay_hours(unsigned h) {
    while (h) {
        --h;
        delay_seconds(3600);
    }
}

void delay_days(unsigned d) {
    while (d) {
        --d;
        delay_hours(24);
    }
}

Suddenly, you can with a single call delay_days(65535u) on a 16-bit processor create a delay of more than 179 years - longer than the longest human life. So why have a huge number of delay() calls after each other?

Note of course that a busy-loop delay that just counts clock cycles will give too long delays in more complex designs where the processor may allocate clock cycles to other things - like interrupt processing. That's why it's best to only create very short "at least" delays using busy-loop delays and make use of timers or other hardware to create longer delays with good precision.

I think you need to figure out what you want. You want to learn how to program? Then you can't give up and demand solutions from other people whenever you get stuck. You have to be willing to invest whatever time it takes to learn. As you learn, you'll notice that what you originally thought of as hard is actually quite simple. Just as it's extremely hard to implement walking robots but we humans manages quite well after a bit of training. There is no shortcut to avoid the need for training - you really do need to invest own time!

Thanks. one more favour, it is possible to send message to multiple contacts via GSM sim 900A module. If so send me reference code. please

That, surely, would be answered in the documentation for the SIM900A?

Have you studied the documentation for the SIM900A? Or contacted SIMCOM or your local supplier?

simcomm2m.com/.../

I tried but i am not getting any useful information there. so please guide me.

So why not just solving your problem by sending multiple SMS one at a time after each other? Would that be a too simple solution?

Hi, initially i am using AT89s52, but my coding size beyond 8kb. so i purchased AT89s8253. As per the datasheet its having 12kb, still my keil compiler version 4 showing (LIMIT 0800 BYTES. Now what i shall do.

Consider reading this page:
http://www.keil.com/demo/limits.asp

Then consider if you have bought a commercial license or if you are running an evaluation version of the compiler limited according to the above information.

So what, exactly, did you find?

If there is no documented way to do it, then it's probably fair to assume that it is not supported.

So, as already mentioned, you will have to create a way to send multiple messages ...

I repeat what someone else said.

I suggest you consider a different course/hobby.

A very basic concept which turns up in all forms of programming is Looping - where you write a bit of code only once, but that code can be executed many times in succession:

en.wikipedia.org/.../Control_flow

There have already been (at least) three examples so far in this thread of where Looping would be applicable ...