AVR Freaks

I'v tried it but all I found was dealing with Arduino, not AVR mcu

The Arduino is an AVR. On a specific board, and with a pre-programmed bootloader, but it is an AVR.

why I see nothing in UDR1 transmit buffer while sending "AT\r\n" command through UART1 ?

With what are you observing it? Some kind of debugger? You need to give all the details of your problem or else we can just guess, and that will likely be a waste of time for everyone involved.

I'll risk two guesses though:

1. You are writing to UDR1 in code you are testing with a debugger. When uoy step through the code you halt right after that writing to UDR1 and expect the value to still be in UDR1. But at the instance your write to UDR1 finishes the value will be shifted into the "transmit shift register" (whether the UDR1 will be cleared when that happens I do not know but I would not rule it out. By the time you have moved your eyes to the part of the screen where UDR1 is displayed, and Studio has actually updated the value,  it will not only have been shifted to the shift register but the it will most likely be shifted out of it. At 115200 BPS a byte is transmitted in about 50 microseconds.

2. The UDR1 is actually two registers at the same address. One transmit register (written to) and one receive register (read from). The debugger shows one of them, likely the receive register.

If you see what you transmit from the AVR on a scope and can verify it there, then why are you not trusting the code and hardware that is earlier in the chain? Why is it a problem you not seeing "nothing" in the I/O view of Studio?

What is the original problem you are trying to solve?

So what is acctually an AVR  ? A family of MCUs including Arduino, Atmel etc... ?

AVR (the 8 bit one) is a CPU design usually based around 32 general purpose registers and that can execute about 75 different RISC opcodes (Atmel claim more but many are synonyms). Atmel make about 300 different models of AVR. Among these are ATmega8, ATmega168, ATmega328, ATmega2560.

When the people at Arduino were looking for an easy to use micro to base their board/IDE/library design on they chose AVR. I think it was the mega8 they used at first but they soon traded up to mega168 and then shortly after that the mega328. For a long time almost all the Arduino boards used the mega328 ("Arduino Duemilanove", "Arduino Uno") and they made millions of the things. Then people asked for both "bigger" and "smaller" ones. So they made bigger ones with chips such as mega2560. Meanwhile other people saw the "power" and "utility" of the Arduino concept and especially how useful all the peripheral library code was so others went on to make variants based on other Atmel AVRs (both tiny and mega). There was also a call for "more powerful" CPUs so variants based on ARM Cortex chips were created (unfortunately this caused a split among the Arduino developers and there are now two competing designs based on ARM).

But when people say "arduino" about 95% of the time they still mean "Atmel ATmega328P".

Now while there are about 300 different 8bit AVRs on the whole most things are compatible or can be made so with small engineering changes. So even if you work with an AVR that isn't one of the ones officially used in the Arudino software:

~/windows/Program Files/arduino-1.6.3/hardware/arduino/avr$ grep "build.mcu" boards.txt 
yun.build.mcu=atmega32u4
uno.build.mcu=atmega328p
diecimila.menu.cpu.atmega328.build.mcu=atmega328p
diecimila.menu.cpu.atmega168.build.mcu=atmega168
nano.menu.cpu.atmega328.build.mcu=atmega328p
nano.menu.cpu.atmega168.build.mcu=atmega168
mega.menu.cpu.atmega2560.build.mcu=atmega2560
mega.menu.cpu.atmega1280.build.mcu=atmega1280
megaADK.build.mcu=atmega2560
leonardo.build.mcu=atmega32u4
micro.build.mcu=atmega32u4
esplora.build.mcu=atmega32u4
mini.menu.cpu.atmega328.build.mcu=atmega328p
mini.menu.cpu.atmega168.build.mcu=atmega168
ethernet.build.mcu=atmega328p
fio.build.mcu=atmega328p
bt.menu.cpu.atmega328.build.mcu=atmega328p
bt.menu.cpu.atmega168.build.mcu=atmega168
LilyPadUSB.build.mcu=atmega32u4
lilypad.menu.cpu.atmega328.build.mcu=atmega328p
lilypad.menu.cpu.atmega168.build.mcu=atmega168
pro.menu.cpu.16MHzatmega328.build.mcu=atmega328p
pro.menu.cpu.8MHzatmega328.build.mcu=atmega328p
pro.menu.cpu.16MHzatmega168.build.mcu=atmega168
pro.menu.cpu.8MHzatmega168.build.mcu=atmega168
atmegang.build.mcu=atmegang
atmegang.menu.cpu.atmega168.build.mcu=atmega168
atmegang.menu.cpu.atmega8.build.mcu=atmega8
robotControl.build.mcu=atmega32u4
robotMotor.build.mcu=atmega32u4

then it's usually possible to take the software and "engineer" it for some other model of AVR anyway.

Even if that is not directly possible you can just study the library code in Arduino for EPS8266 and see what commands/steps are being performed to configure and operate the device then just re-code the same algorithm for your chosen CPU in your own chosen language.

Arduino itself is C++ but the vast majority of the code written for it does not get beyond using the C only features of C++ so even if you are using C not C++ you'll often find you can just use the code "as is".

The advantage of using Arduino library code is that for many peripherals it is the most heavily engineered code available so you usually have a pretty cast iron guarantee that you are using robust, foolproof code.

I am really skeptical about the get_char_uart() and read_string() functions. Did they really come out of a "library" (or some such) from Atmel?

Also: If the remote device (in this case the ESP module) does "echoing" then data will begin to come in on the receiver part of the AVR UART long before the "AT\r\n" has all been transmitted. At that point in time you have no code running that can get incoming chars out of the UART so a data overrun is almost certain.

I know it sucks that things are complicated already when you're starting out, but I would really recommend to learn about interrupt-driven reception and circular buffers right away. It will handle the "incoming data while transmitting" problem, it will handle "data comes in too fast for me", and it will give you a nice simple way to detect if you've gotten a complete line of input from the remote device (i.e. "have we seen a \n yet?".

You can do this learning without the ESP module being involved. Just the PC and the AVR will do. When you've got that under control you pull the ESP into the picture again. Sorry, but sometimes you just need to take one step back in order to eventually take two steps forward.

BTW, if the ESC behaves according to normal "Hayes standard" you only need to send "AT\r". No '\n' is needed, and it might even be harmful. (When you tested the ESC with your PC you only pressed the Enter key at the end of the command, right? That sends just an '\r', and no '\n'.)

If you send "AT\n" and then get what you receive begins with "AT", what you are seeing is the module echoing back what it receives. This is normal for any Hayes-compatible device, unless you tell it not to.

As can be seen when you tested the module against a terminal program, this happened there too.

No, you wont destroy the module by ending lines with \r\n but I believe this is in part what disturbs you reception. The normal thing for a Hayes-device is to echo everything, and insert \n itself after a line.

So, sending: AT\r

The device echoes: AT\r\n

In your case, you're sending: AT\r\n

And the module echoes: AT\r\n\n

See that extra \n? That helps messing things up for you. Take my advice - send only \r at the end of a command. Itt will be completely sufficient, and you will do what all other Hayes-communication does. And you will not confuse people who look at your code to help you.

I would recommend that you shift from your current terminal program to one that sends character by character, rather than sending complete lines, and re-do some tests between the PC and your module. This will give you a better picture, since it mimicks how the communication between the AVR and the module is done (the AVR does not wait until a whole line is complete before sending it - it sends character per character).

A good choice, IMO, is "Terminal" (formerly known as "Brays terminal").

In your screen dumps above you have set "local echo", so the terminal program shows what you're typing. Then the module echoes that back upon reception. That's why you see "AT..." two times.

When you go from sending complete lines, to character by character things will look different (still with both local echo and remote echo). When you type A on the keyboard you will see you local echo, and immediately also the remote echo. I.e. you will see "AA". So after you've typed the complete AT[enter] and the module has replied, you will see something like this:

AATT

OK

 If you turn off "local echo" in the terminal program things will start to mimick the communication the communication between the AVR and the module quite well.

Eventually you will likely want to turn off the remote echo done by the module. There is an AT command for doing that. IIRC it is ATE0, but don't trust me on that. You will need to know a set of basic commands at heart anyway, so please look it up in the manual for the module. You will turn off remote echo because you don't want to deal with all those AT commands you send coming back again.

Administrativa: Prolly me messing up (again). I blame it on the cold-n-fever I'm experiencing ATM. Sorry.

And just for fun I deleted another two identical posts. You are in rare form Johan.

I really don't know why the response is not "\n\nOK" and just 'AT\n' 

Because the ESP module is still doing remote echo for you. It most likely defaults to that on every power-up.

If you'd go to interrupt driven reception into a ring buffer, you could then easily devise functions that

- Check if there is a complete line received and ready in the ring buffer. Lets assume that function has this signature: bool receivedLineAvailable()

- Get a complete line out of the ring buffer. With just a little bit of effort you could even make it trim off any line ending chars (\r, \n) before returning it. The signature woud look something like this: void getReceivedLine( char * line )

Now you can code a simple main loop going something like this

int main(void)
{
   char line[32];
   .
   .
   .
   while (1)
   {
      // Do other stuff needed
      .
      .
      .
      // If there is a complete response line ready from the ESP module, then deal with it
      if (receivedLineAvailable()) {
         getReceivedLine( line );
         if (strcnmp(receivedLine, "AT", 2) {
            // It's just an echo of a sent command - do nothing
         }
         else if (strcmp(line, "XYZ") {
            // We got the exact response "XYZ", and will deal with it here
            .
            .
            .
         } else if (strncmp(line, "PQR", 3) {
            // We got a response beginning with "PQR, and will deal with it here
            // Note that the complete response is still intakt in the variable line, for further analysis
         }
         // ... and so on ...
      }
      
      
   // Do other stuff here
}

This approach has several advantages, one being that the ring buffer will ...eeehh... buffer. I.e., even if you happen to spend time in another piece of code for a while, the interrupt driven reception will happily receive any incoming chars and place them in the buffer. They will stay there until you consume them at a later time. You just need to make sure that the ring buffer is big enough and/or you dont hang in other pieces of the code for too long to make sure the buffer wont be over-run (to wear both the belt and the braces, the interrupt driven reception should also cope with this and set a flag indicating any overrun, and your main loop should check it before trying to get anything meaningful out of the buffer).

Another advantage is that you get your code divided into more logical modules, and "the main code" will not see any of the nitty-gritty details of the reception. Why should it? Looking at te code in main you dont want to see those details. You want a (slightly?) bigger picture, i.e. one step up the abstraction ladder. You just want to do things like ask "Is a response available?" and "Get that response!".

----------

The quick-and-dirty approach would be to start out by sending "ATE0". That will possibly be echoed back, and then hopefully be followed by an "OK". Sit in your reception loop, either for a fixed time lie 1 second, just throwing away any incoming characters. At this point the echo is off. This is ugly, and is the wrong way to approach the problem if you ask me. But I see no reaction to my suggestions on interrupt driven so I'm presenting this alternative.

----------

To round off, think of this: You never really know when a character will be coming in. Characters are arriving asynchronously. Interrupts where devised exactly for dealing with asynchronous events. While they might seem complicated at first, they quite soon make the overall coding for asynchronous events much easier than if you use a polling approach. (There are of-course always some exception to this rule, but your case screams for interrupt driven reception.)

Add to that that the circular buffer will provide you with an excellent abstraction layer so that most of your code can deal with things on a higher level without being stuffed with details about the reception.

That's it from me for this evening. Nap time...

Breakpoints and incoming data on the UART does not go well together. When your ESP module has sent the echo you receive it and hit a breakpoint. Your AVR is now not executing any code at all, it is at a halt. Now the ESP module sends the "OK". Where will it go? Well..., the 'O' might make it into the hardware U(DR register in the UART, but just stays there. Nothing is picking it out. Right after that comes the 'K'. Kaboom!, and you have a collision in the UART. That is known as a data overrun.

Even with no breakpoints your current code copes badly, or not at all, with asynchronous events on the UART. You might spend too much time in other pieces of the code to come back quickly enough to be ready to start polling for the next char before it arrives. If you're unlucky and don't get back to the poll before the next-next character arrives you again have a data overrun. Again: The remedy is interrupt driven reception and a ring buffer. The ring buffer will also simplify your analysis of incoming data.

I'm currently implementing a ring buffer (rxstr) in my code

No, you're not. You're implementing a linear buffer. Sort of.

Please read up on ring buffers, an alternative term is "circular buffer". There have been MANY discussions on this before here on AVRfreaks. You will find ready-to-run code if you don't want to write your own.

With that, you now have the ring buffer functionality nicely separated from the rest of your code. You can deal with interrupt-driven reception, which will remedy the data overrun problem you're having. I won't talk here about how to set it up - we have an excellent tutorial here on AVRfreaks showing you how to do that. What I will sketch is how simple it will be to get a received character into the ring buffer:

Since the reception is interriupt driven, every received character will cause the ISR to run, the body of which will be extremely simple:

{
    ring_buffer_insert(UDR);
}

That's it! Get the char out of UDR and stuff it into the ring buffer. Done! The ISR exits and your main code resumes executing. Simple. To the point. No intertwined and convoluted main code to try be able to run around and "do everything".

Your intellectual effort now lies in how you in your main loop look for a complete line in the ring buffer, and get it if it is there. You should isolate this into separate functions as I suggested above.

----------

I believe that the tutorial on interrupt driven UART reception also has the basic code for a ring buffer but I'm not entirely sure. If it has, then you're about to make some really good progress after studying it.

----------

Your problem is not unique in any way. In fact, there have been many here before you asking about communication between an AVR and some device "talking the Hayes AT protocol". Look around and you shall find a lot!

the ISR should replace the call for get_char()

Yes. And the only thing the ISR will do is getting the char out of the UART and into the ring buffer.

and ReadString() functions

No. The closest I can come to saying something understandable is "ReadString should/can be re-coded so that instead of getting data directly from the UART will get the data from the ring buffer".

But that will not suffice for you. Remember that at any given time there might be an incomplete line in the ring buffer. You don't want to get that out of the buffer, since analysing an incomplete line will likely fail. You want to wait until there is a complete line, i.e. there is a sequence of chars that ends with the EOL marker your system uses.

You can do this by writing a function that peeks into the ring buffer to see if that situation is at hand. You call this function (in your main() thread of execution) repeatedly until it returns true - i.e. now you're polling the ring buffer instead of the UART, and you're polling it for a complete line rather than a single byte.

When the condition is true, you use the other function I suggested above to actually extract the line from the ring buffer into e.g. an ordinary string (array of chars, with null termination) and do the analysis using that array.

I use lots of AT90CAN32s. The 32 64 and 128s all have 2 uarts. If you write little terminal program, you can type from the pc terminal program to uart0, then your avr terminal program sends the char out to uart1, and chars from uart1 are sent back to uart0 where they come out on the pc. So there is no interrupts, no parsing, no strings, just getchar and putchar. The terminal program algo is something like: if char waiting in uart0, getchar from uart0, putchar to uart1. If char waiting in uart1, getchar from uart1, putchar to uart0. If the char from uart1 (from the pc) is a CTRL-E for exit, then exit. Now you can get into the avr terminal program and type ATcr and you should see everything that comes back.

OK then, I followed your instructions and I coded something initially (using a ring buffer and implemented the ISR i.e interrupt driven)

You did NOT code something using a ring buffer! Looking on the code you wrote, it is obvious that

1) You did not even have a look at the Wikipedia article on ring buffers (I linked to it above)

2) You did not have a look at the implementation of such a buffer (that you could just "steal") (I linked to it above

Asking for help and then ignoring even looking at suggested solutions in mighty impolite in my view.

With the effort you've been showing so far I predict you will not get it working. Just accept that and buy a solution from someone. (Unless this is school work - if so you should just face that you will fail this class' exam. Take another subject, that does not require reading stuff.)

I'm out.

No, even without any Arduino in the room, most ESP modules have the AT stuff already loaded.

Here's a library I wrote, may be helpful, https://github.com/Soulhealer95/...

So you have the Echo enabled on the module, then?

that is, every character you send to the modules it sends straight back to you as an "echo" ?

Terminal           Module
       A ---->
             <---- A      -- echo!

       T ---->
             <---- T      -- echo!

      \r ---->
             <---- \r     -- echo!
             <---- \n

             <---- O      -- response
             <---- K
             <---- \r
             <---- \n

EDIT

Highlight echoes & response 

yes i have echo enabled on my esp, 

NOW I'VE TRIED after disabling ECHO by ATE0

but the result be like with delay

OK

then nothing

and without delay

AT

AT+CIPMUX=1

busy p...
AT+CWSAP="ssid","pass"

busy p...

OK

kindly guide me like what to code for waiting for response.

I did tried that. but i guess that was totally wrong.

#define F_CPU 8000000UL               //using 8 MHz crystal
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include <stdlib.h>
#include <stdio.h>

unsigned char interface_var = 0;
unsigned char counter[34];
unsigned char var = 0;
unsigned char receive_data;         //variable to store received data

void usart_init(void)
{
    UCSRB |= (1<<TXEN) | (1<<RXEN) | (1<<RXCIE) ; //  enable receive transmit of usart
    UCSRC = (1<<UCSZ1) | (1<<UCSZ0) | (1<<URSEL);
    UBRRL = 51; //  baudrate = 9600 , Fosc=8MHz
}
void usart_send( unsigned char ascii)
{
    while(!(UCSRA & (1<<UDRE)));              //Usart sending function
    UDR = ascii;

}
unsigned char usart_receive(void)
{
    while (!(UCSRA & (1<<RXC)));             // usart receiving function
    return UDR;
}
void send_AT( unsigned char message[])
{
    unsigned char i=0;
    while(message[i] != '\0')                 // for send AT commands like AT+CIPMUX
{
    usart_send(message[i]);   // This sends data to esp-01
    i++;

}
}
int main()
{
    //OSCCAL = 0xA9;
	MCUCSR=1<<JTD;
    MCUCSR=1<<JTD;                  // to disable jtag for proper fuctioning of PORTC
   DDRC=0xFF;
   PORTC=0XFF;
    unsigned char AT[] = "AT\r\n";
    unsigned char CIPMUX[] = "AT+CIPMUX=1\r\n";
    unsigned char CWSAP[] =  "AT+CWSAP=\"ESP_002\",\"1234test\",4,3\r\n";         // commands 

    _delay_ms(200);

    usart_init(); // initialize usart
    _delay_ms(500);
    sei();

    _delay_ms(200);
    send_AT(AT);                    // sending AT\r\n

    send_AT(CIPMUX);   

    _delay_ms(2000);
    send_AT(CWSAP);

    while(1)
    {   

    }//while(1) close

}// main close

ISR(USART_RXC_vect)    // Every time an AT command is sent correctly type OK on the LCD (Logic analyzer works better though :-p)
{

}

this is my code.

and the missing part for reciving is deleted already by but i show u what was that

ISR(USART_RXC_vect)
{
    received_data=UDR;    
}



while(received_data!="ok")
{
    PORTC^=1<<0; //toggle led

And besides:

an unsigned char can only hold one single character!

It does seem that you need to brush-up on some of your 'C' basics.

Here are some 'C' reference & learning resources - including a free online textbook: http://blog.antronics.co.uk/2011...

As is so often said here, you need to stop just flinging code into your editor and design your program.

Think about the process of receiving characters, and seeing if they form a recognised response string ...

eg, draw a flowchart of how you will handle this.

As you should have picked up from the quoted threads (you did read them, didn't you?) a State Machine would be a common approach to a problem like this.

Now that may well be a bit advanced at this stage - but it's something to bear in mind ...

i tried all  those stuff but unfortunately none help me .....

i tried

1. if(received_data=='\0')

2.                           '\n'

3.                          'K'

 4.                         'O'

But all stucked at OK .

some shows other commands but after that they shows

1. busyp....

2. ok

    busyp....

    busyp....

please help me...unable to serach related response code 

Hmmm ... there seems to be a post missing!

I'm sure I wrote a post in which I advised you to set the ESP module aside for now, and just work with your AVR connected to a terminal app on a PC.

RealTerm is useful here, as it allows you to see the hex codes of non-printing characters - such as CR and LF

Here is a tutorial: https://learn.sparkfun.com/tutorials/terminal-basics/real-term-windows - with download link

Another useful tool is TeraTerm: https://ttssh2.osdn.jp/ - principally because it allows you to record a log of all sent & received data with timestamps.

So:

1. Get your code to send a string - any string - to RealTerm
   Pay attention to the control characters!
    
2. Get your code to receive a string - any string - from RealTerm.
   Agfain, pay attention to the control characters!
   Use the debugger to confirm that you are correctly receiving the string.
    
3. ​Now get your code to recognise specific strings from RealTerm.
    
4. Only when the above are all working, update your code to send the AT commands you want to send,
   and recognise the responses you expect.
    
5. Add handling for error responses, and unexpected responses.
    
6. Then - and only then - connect to an actual ESP module.

Here is the other one:

https://www.avrfreaks.net/forum/interfacing-esp8266-atmega32

Your level of patience in that thread was ridiculous. At one time you could not hold out for more than 12 minutes before adding on a "Please reply...".

You need to accept that things might take much longer than that. You might not know this, but the Earth is round, and at some times it is dark at a specific place, and then people tend to sleep. This can go on for 8 hours or even more. Suggest you plan for waiting for at least 24 hours before crying out for attention.

And yes, posting the same question in more than one place is considered bad form and manners. Apart from looking spoiled and "all over the place" there is a risk that people answer the same thing independently in the two places, whereby you effectively have wasted the time of one of those persons. Staying in your own one thread will be much more advantageous for both your progress and your reputation.

and, apparently, u weren't listening to what I said anyhow!

Ok let me clear myself.

This time i'll try to be more clear.

1. 

Here yes I did this,

I wrote some codes and used FTDI Serial cable to communicate with PC. 

2. 

Yes i did used Real term not only this i've used Putty as well.

     1. I did get that code to send string and paid attention to control characters!

     2. I Tried to get some code for Receiving a string and succeded.(But here either i am sending or receiving strings not getting \r\n anyway).

     3. I was not clear about this point (what did you want to say), But i tried sending more than 1 command and succeded.

     4. yes all above are working and i updated my code to send the AT Commands and did recognised the reponse i wanted .

     5. At this point instead of handling errors i used esp and tried above code.(But here i can receive all the strings correctly),But....

But.... the problem starts here, Controller sending data and ESP receiving it as i can see that on {Real Term, Putty, and Serial monitor of Arduino}.

But Esp Stops responding after receiving any delay either it is 2ms , 20 ms ,1000 ms what  ever it is not working, then i repled bac here to ask you if you guys can help.

Awneil you think 

But it is absolutely wrong, I did every single step you say i was just aint type here and tell everything, If u are saying something that means a lot to me and i really follow that but because of some less knowledge or less experience i don't understand what did u want to say exactly and it took me some time to understand what you are saying.

sir John I was not losing my patience it was just that i was searching related stuff and fortunately found this thread which is related to mine so instead of waiting i decided to ask here as well so someone online will help me as well.

can't expain more, Hope you understand.

1. You can manually send a sequence of command to the ESP from a terminal, and you see the expected replies?
   

   ---

   yes i did see the expected replies

   ---

    

2. You connect your AVR to a terminal, and it sends the exact same sequence of commands - with the exact same control characters,
   and waits (not just delays) while you manually send back the exact same responses - with the exact same control characters?

    

   ---

   yes

   ---

    

3. But when you connect your AVR with this code to the ESP, it "Stops responding" ?

right

How are you verifying, in particular, that you have all the control characters correct and identical?

because my AT commands works when single command send but when i send more than one it stucks.[Any command accepted and response back accurate]

Even more specifically, how do you know what your terminal sends when you press the 'Enter' key?

Well for that i used a led and put a condition if received_data is same as transmitted data then toggle my led and it does

Rather than pressing the 'Enter' key, have you tried explicitly using Ctrl+M for CR and Cltr+J for LF ... ?

No i didn't

Have you done as I suggested in https://www.avrfreaks.net/comment... to log both sides of the communication between AVR and ESP?

Not having two ftdi cables sorry but i've used arduino uno board and yes received and transmit successfully

Have you used the debugger to see exactly what your AVR code is receiving?

Sorry but i really don't know how to use debugger, i will surely search for this tommorow 

Have you drawn a flowchart of your design before just jumping into 'C' code?

I tried but i guess i m not good at it, i just made a simple sending data, receiving data, wait for response, if yes then do this else do this and finished

Control characters like /r/n ?
If yes then if I send commands without them then esp stop responding and prints only transmitted data without ok response.
And with them esp respond back and ok shown

Yes.

if I send commands without them then esp stop responding

Which is exactly the problem you say you're having!!

Doesn't that tell you something?

EDIT

Note that it's /r and /n

It is \r and \n

You can't be sloppy with stuff like this in programming!

So stop, then!!!

You're confused enough as it is without adding sleep deprivation to it!!

A number of mistakes have already been pointed out in that code, and you yourself have spoken of changes to it - if you're having trouble with that code, it is not surprising.

That code does not wait for responses - it just has blind delays.

So step away from the editor, get out your pencil and paper, look at the sequence in #63 and start thinking about the design of a program to handle that.

Start by taking the sequence in #63, and extend that to a few commands and their responses.

Awneil I made changes but that code is in pc. I will update here tomorrow early morning.
And with detailed statements.
And I tried using some response commands I'll show u tomorrow.

awneil wrote:

"Note that it's /r and /n"

Think you meant:

"Note that it's not /r and /n"

These things can make a difference in programming!

Awneil,

Sorry i did a blunder mistake there.

Instead of analysing receive characters using PC . I was analysing ESP response which shows "OK" for related COMMANDS.

But now i tried sending Characters through PC it receives 1st command then it stop responding.

I am so messed up, please help me here,

I don't understand how to read characters of usart receive and then use them accordingly.

Please help.

I did read what you ask me to, Now i'll tell you what i've got

#include <avr/io.h>
#define F_CPU       8000000UL   //--- CPU Clock Frequency
#define BAUD RATE   9600        //--- Transmission Baud Rate
#include<stdio.h>
void usart_init(void);      //--- Usart Initialize
void usart_tx(char x);      //--- Usart Transmit
char usart_rx(void);        //--- Usart Receive
void usart_msg(char *c);    //--- Usart Transmit String
void send_AT( unsigned char message[]);
char tx_data;

int main(void)
{
    unsigned char data;
    usart_init();                       //--- Usart initializing
    usart_msg("INITIALIZING USART");    //--- Send a set of String
    usart_tx(0x0d);                     //--- Cmd to jump to next line
    unsigned char ATE1[] = "ATE1\r\n";
    unsigned char AT[] = "AT\r\n";
    unsigned char CIPMUX[] = "AT+CIPMUX=1\r\n";
    unsigned char CWSAP[] =  "AT+CWSAP=\"ESP_003\",\"1234test\",4,3\r\n";
   usart_msg("<<");
         send_AT(ATE1);         //--- Receive the data from rxd
         usart_tx(0x0d);                //--- Next Line
         usart_msg(">>");
         data=usart_rx();             //--- send the received data back
         usart_tx(0x0d);                //--- Next Line
       while(data=='k')
       {
	  send_AT(AT);
	  data=0;
       }
       while(data=='k')
       {
	  send_AT(CIPMUX);
       }

    while(1)
    {

    }
}

//--- Proto Type Declaration ---//

void usart_init()
{
    UBRRH = 0x00;                       //--- Initialize UBRR value for Baud Rate
    UBRRL = 0x33;                       //--- Baud Rate Set as 9600 by Data Sheet
    UCSRB = (1<<TXEN) | (1<<RXEN);      //--- Transmit and Receive Enable
    UCSRC = (1<<URSEL) | (3<<UCSZ0);    //--- 8 bit data and UCSRC is selected
}

void usart_tx(char x)
{
    UDR = x;                            //--- Move data to UDR Data Reg
    while (!(UCSRA & (1<<UDRE)));     //--- Check whether UDR is empty
}

char usart_rx()
{
    while (!(UCSRA & (1<<RXC)));      //--- Check whether Receive is complete
    return(UDR);                        //--- Return Data from UDR
}

void usart_msg(char *c)
{
    while (*c != 0)                     //--- Check for null
        usart_tx(*c++);                 //--- Increment the pointer
}
void send_AT( unsigned char message[])
{
    unsigned char i=0;
    while(message[i] != '\0')
{
    usart_tx(message[i]);   // This sends data to esp-01
    i++;

}
}

Not when i press k it shows AT but after that i need another 'k' to get CIPMUX command but it stucks.\