esp8266 AT commands embedded code

Go To Last Post
64 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi to all ,

i am trying to write the embedded c code for esp8266 via AT commands .

flashed the AT commands firmware in the esp8266 . connected esp8266 via rx and tx with arduino mega pins 18-19.

Now first for testing purpose  i am just sending the AT command and expecting the response from esp8266 as OK.

 

 

#include <uarts.h>
#include <avr/delay.h>
int main(void)
{    char buff[100];
    //UART_Init0();  
    UART_Init3();        //for printing on serial monitor                
    UART_Init1();       ///for esp bauddrate is selected 115200
 printString3("******************hellow*****************");
 printString3("\n");
                     

    
    while(1)
    {    
        printString3("type a command  \n");
        printString1("AT");   //sending command to esp8266
        printString3("AT \n");   //printing command to terminal screen
        printString3("received response \n");
    //    rxstring1(buff);
                         for(int i=0;i<2;i++)
                                    {
                                        buff[i]=UART_RxChar1();
                                        UART_TxChar3(buff[i]);
                                        _delay_ms(1000);
                                   }

                      
        //printString3(buff);
        printString3("\n");

}}

 this is code which i have written and sending the AT command via serial UART now but in response i am not getting the OK command i am getting output like this.

https://drive.google.com/file/d/... (green output when sending code coloured in green and blue when sending clue cloured code)

Now I have 2 questions 

1) why i am not getting OK in response and instead getting the command which i am sending

2) does the response of AT commands had anything to with CR and NL ...

 

for reference below is my git repo for above uart functions ..

  https://github.com/gkunalupta/uart-/blob/master/code

 

This topic has a solution.

Kunal Gupta

github.com/gkunalupta

Last Edited: Fri. Jul 3, 2020 - 12:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Before adding the uncertainties of the AVR and its code, just connect the  esp8266  to a terminal program on your computer and practice sending commands to it manually, and seeing what responses you get.

 

Once you know what commands you need to send, and what responses to expect, then - and only then - move on to implementing that on an AVR.

 

Kunalgupta wrote:
why i am ... getting the command which i am sending

 

Probably becuase you have Echo enabled.

 

There is a huge amount of prior discussion here & elsewhere on dealing with AT commands in general - do spend some time searching!

 

eg, 

 

https://www.avrfreaks.net/commen...

 

https://www.avrfreaks.net/commen...

 

Some tips on debugging serial comms:

 

https://www.avrfreaks.net/commen...

 

 

See Tip #1 in my signature (below) for how to properly post source code:

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. May 29, 2020 - 11:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have sent the AT commands to the terminal screen and the work perfectly.

 

so reading from the URL's which u provide i conclude i have some confusions which if you can make clear will be very grateful.

1) when sending AT commands in terminal window we opt for BOTH NL and CR ....so that means

      a) that when we send command "AT" from serial monitor it is sent as  "AT\r\n" and thus esp respond to it with "OK".

       b) or We also get the response from esp8266 with both NL and CR that is we get OK as "OK\r\n".

2) if a send AT command by selecting Carriage return (CR) only then no response is received from esp8266 on serial monitor ... so does that mean when sending AT commands i have to send both  \r and \n with the command. So that command is recognised by the esp8266.

\b (backspace) Moves the active position to the previous position on the current line. If the active position is at the initial position of a line, the behavior of the display device is unspecified.

\n (new line) Moves the active position to the initial position of the next line.

\r (carriage return) Moves the active position to the initial position of the current line.

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

 

Probably becuase you have Echo enabled.

 

 

So how should i disable ECHO in terminal screen.

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Standard AT commands:

Echo off

ATE0

Echo on

ATE1

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you misunderstood my query in #1
When i send command AT to esp8266 in return as a response i only get the AT ( echo enabled) ....as i have echo enabled so it should send response
AT

OK

But it is only sending the AT .
Why is this happening ....i am not able to get the Response OK

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay so i think i find the reason why only response AT is coming ..... 

i debug my code by printing the bit value of UCSRnA each time before data is received and after data is received ...so that i can get the live status of RXCn bit.

and here is the output.

OUTPUT.

 

Now interesting thing which to see is

1) that as i have send the AT command to esp8266 with \r\n ....so in return esp8266 will send the response . So RXCn bit of UCSRnA register will be 1 till esp8266 is sending the response . But here after sending  2 or 3 characters this bit is cleared . as you can see in pic. So why is this happening??????

My esp8266 is receiving the command that is sure but at the time of printing response , it is not doing that. why??????

 

 

2) that 5th bit of UCSRnA ..that is DORn bit is set to 1 after receiving two characters. What can be reason for this , can this be the reason for clearing of my RXCn bit.

You can see the register details of UCSRnA here . 

 

 

here is revised code.

#include <uarts.h>
#include <avr/delay.h>
int main(void)
{    char buff[100];
	char str[30];
	//UART_Init0();
	UART_Init3();		//for printing on serial monitor
	UART_Init1();       ///for esp bauddrate is selected 115200
 //printString3("******************hellow*****************");
 printString3("\n");

	while(1)
	{
	   printString3("type a command to send  \n");
	   printString1("ATE1\r\n");   //sending command to esp8266
	   printString3("ATE1 \n");   //printing command to terminal screen
	   printString3("receiving  response \n");

	//UART_TxChar3(rxstring3(buff));
		 				for(int i=0;i<20;i++)
                     		{   printString3("\nWaiting to receive data \n");
								 buff[i]=UART_RxChar1();
								printString3(" received data \n");
                          	UART_TxChar3(buff[i]);
                              	_delay_ms(1000);

                            }
	}}

	/* function definations of uart functions which i used
	void printint3(int myint[])
{

	uint16_t i = 0;
	while (myint[i])
	{
		UART_TxChar3(myint[i]);
		i++;
	}

}

void UART_TxChar3(char  data)
{
	while((UCSR3A & (1<<UDRE3))==0);
	UDR3 = data;

}

void printString1(  char *myString)      /////to print any string
{
	char i = 0;
	while (myString[i])
	{
		UART_TxChar1(myString[i]);
		i++;
	}
}

int UART_RxChar1()
{
 	printString3(" UCSR1A value before receiving data   \n");
 	bit3(UCSR1A);
	printString3(" \n");

    while( !(UCSR1A & (1<<RXC1)));

 	printString3(" UCSR1A value after receiving data  \n");
 	bit3(UCSR1A);
 	printString3("\n");
	return UDR1;
}

 

Attachment(s): 

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please someone suggest some ways .....want to know how this obstacle can be cleared

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When you send a command to the ESP8266 it sends a reply.
If your receive code is too slow to read the UDRn to get the characters in that reply then a Data Overrun error will occur.
USART1 and USART3 are set to the same baudrate but in UART_RxChar1() you use a blocking write to print the bits of UCSR1A and a '\' but all of that takes time and the ESP8266 is probably still sending characters !
As a general rule do NOT print from inside a receive routine.

also, check what you want the UART_Initn() routines to actually do, because you are setting a UPEn bit (which is in the UCSRnA register) in the UCSRnC register.

Last Edited: Sun. May 31, 2020 - 01:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kunalgupta wrote:
Please someone suggest some ways .....want to know how this obstacle can be cleared

If you want to do stuff (like printing strings) between sending the AT command and receiving the response you will need to switch to an interrupt driven UART receiver as opposed to the simple register polling function you have now.

 

There have been recent threads on UART receiving where this is demonstrated by example and I would expect also to find a tutorial.

 

BTW: Your AT command is terminated wrongly, you just need '\r'. Here are examples of AT command strings from my own code.

const char __flash ATI4_P[] = "ATI 4\r";
const char __flash ATOK_P[] = "OK\r\n";

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried the things which u suggest but still same thing is happening .... Things which i tried
1) remove the print from the receive routine
2) checked the baudrate of both the uarts.
Still same thing is happening .

Can anybody suggest ways to write the function for receiving at response in embedded c.
Or can tell me if i am on right track for doing this thing

On net most of the functions i found are using arduino hardware serial library but i want from embedded c

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:

Kunalgupta wrote:
Please someone suggest some ways .....want to know how this obstacle can be cleared

If you want to do stuff (like printing strings) between sending the AT command and receiving the response you will need to switch to an interrupt driven UART receiver as opposed to the simple register polling function you have now.

 

There have been recent threads on UART receiving where this is demonstrated by example and I would expect also to find a tutorial.

 

BTW: Your AT command is terminated wrongly, you just need '\r'. Here are examples of AT command strings from my own code.

const char __flash ATI4_P[] = "ATI 4\r";
const char __flash ATOK_P[] = "OK\r\n";

 

Okay let me try these ...i didn't see your post before sending the above reply

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kunalgupta wrote:
On net most of the functions i found are using arduino hardware serial library but i want from embedded c

 

Look at the Arduino core code for the serial library then and see how it does it. Note that Arduino is written in C++ and C - look at what it does rather than the code itself.

 

What is this 'embedded C' you speak of?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:

[

There have been recent threads on UART receiving where this is demonstrated by example and I would expect also to find a tutorial.

 

Threads in receiving the at Response from uart pooling ?????
If yes,
Can u plss share the resources if u can it will be greatfull and also will make my understanding more clear on this topic.

N.Winterbottom wrote:

BTW: Your AT command is terminated wrongly, you just need '\r'. Here are examples of AT command strings from my own code.

const char __flash ATI4_P[] = "ATI 4\r";
const char __flash ATOK_P[] = "OK\r\n";

 

Well that thing i have checked AT commands for esp8266 only gets Response if they are ended with Both /r and /n or only with /n .I have checked this thing by sending AT commands through serial monitor.

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kunalgupta wrote:
Threads in receiving the at Response from uart pooling ?????

No I meant generic (not modem specific) UART receive using interrupts.

 

As suspected there is a tutorial https://www.avrfreaks.net/forum/tut-soft-using-usart-interrupt-driven-serial-comms unfortunately it has as colossal 340 comments/replies and avrfreaks.net has garbled the code. So I cannot recommend it. Perhaps I should write an up-to-date one.

 

<edit>

I just spent a short time looking for threads on both interrupt driven UART and AT commands but just realised awneil has already done this in #2. They're all his own comments but that doesn't make them invalid, so read them and if you have time also read the whole associated thread. You're not doing anything here that's not already been done by a thousand other freaks; and it's all been answered before.

</edit>

Last Edited: Sun. May 31, 2020 - 12:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried everything again but still after sending 2-3 characters same thing is happening ...*data over run error*
Now not even printing anything from the receive routine . Checked my clock ...but still.

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:
You're not doing anything here that's not already been done by a thousand other freaks; and it's all been answered before.

Absolultely!

 

And not just AVR: apart from the basic mechanics of getting a character into & out of the UART, none of this is specific to any particular microcontroller.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agrees .... I am able to send and receive the strings and character between normal 2 uart pairs like sending and receiving data from laptop to phone via HC-05 bluetooth .
But when i do it for esp8266 it receives the command but when i record the response it only send 2-3 characters .
Plss give some clue or guidance through which i can solve the problem

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kunalgupta wrote:
I am able to send and receive the strings and character between normal 2 uart pairs like sending and receiving data from laptop to phone via HC-05 bluetooth

So you can send & receive strings between your AVR and a laptop?

 

Is that just typing manually, or have you tried sending complete strings from the PC - eg, by pasting a string into the terminal?

 

Plss give some clue or guidance through which i can solve the problem

See the link in #2 for debugging serial comms...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

So you can send & receive strings between your AVR and a laptop?

 

Is that just typing manually, or have you tried sending complete strings from the PC - eg, by pasting a string into the terminal?

yes  sending and receiving of string .... like from my laptop i send string to AVR via UART0 and that string is printed on my phone via bluetooth(HC-05),using UART1 of atmega2560.

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

what has bluetooth got to do with it?

 

keep things simple!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It js simple it is Just simple UART communication module .. hc05 does not increase any complexity

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kunalgupta wrote:
hc05 does not increase any complexity

Of course it does!

 

and introduces a whole bunch of (potential) differences between your PC-to-AVR and your ESP-to-AVR cases.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay i have one thing to clarify plss tell mee...

If my DOR1 bit is set to 1 then my RXC1 bit will be set to 0 automatically even if more data is coming in receiver...

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


DOR indicates that a Data Overrun has occurred; RXC indicates that a received byte is available for your code to read:

 

 

The meanings of those flags are further described here:

 

 

http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega640-1280-1281-2560-2561-Datasheet-DS40002211A.pdf

 

https://www.microchip.com/wwwproducts/en/ATmega640

 

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Whilst your code is busy printing a string, its not reading the incoming characters. Thus the overrun.
Also note that you may get dud characters when your code starts or when the power is cycled, so if you expect 3 chars and they must be AT\r, then it is unlikely your code will see this.
Find some code that gives you a standard interrupt usart receive with a circular buffet. Standard solution to a common problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

okay if baud rate of my receing and transmiting modules is not same then should uart work properly...

like here my esp8266 sends response at default 115200 and avr records that at 9600 . 

so should this work ?????

 

because in doing so i am receiving two characters (which is size of the receive buffer) and then DOR error occurs.

 

 

also in the datasheet it is written that 

The DORn Flag is cleared when the frame received was successfully moved from the Shift Register to the receive buffer .

and

This bit is valid until the receive buffer (UDRn) is read

So will making a while loop when DOR is set should work untill all the data from UDRn is read?????????

Kunal Gupta

github.com/gkunalupta

Last Edited: Thu. Jun 4, 2020 - 01:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

No

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For which question u answered ?

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It was the question as it stood at the time; IIRC:

 

You wrote:
okay if baud rate of my receing and transmiting modules is not same then should uart work properly...

like here my esp8266 sends response at default 115200 and avr records that at 9600 . 

so should this work ?????

To which the answer is, "No."

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

 

Kunalgupta wrote:
all the data from UDRn

UDRn is just one byte!   <-- see correction in #32 !  blush

 

EDIT

 

 

EDIT 2

 

And the way Shift Register and Receive Buffer (UDR) are used is described:

 

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Jun 4, 2020 - 04:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

awneil wrote:
UDRn is just one byte!

Actually no - it's two. Note the dividing line. It indicates a small FIFO.

 

20.11.1 UDRn – USART I/O Data Register n

...

...

The receive buffer consists of a two level FIFO. The FIFO will change its state whenever the receive buffer is
accessed

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 Okay so according to datasheet Data over run error occures (DORn=1) when The receive buffer is full(That is not read) and their is character already present in UDRn buffer  and is not read before the next character has been shifted into the receiver shift register.

 

And DORn is cleared(DORn=0) on reading the UDRn buffer register  so that UDRn buffer is emptied and now new data can be read ... so i have created a function in which i am monitoring the DORn bit and when it is 0 then everything is fine and when it will be set to 1 then i want that either it first read the UDRn register or make the UDRn buffer register empty (like anything so that my buffer becomes free).

char UART_at1(char *str)
{   
    int i=0;
    char value,dvalue;
    
// if RXC bit is 1 then go inside the while loop and it means their is data present to be read
    while ((UCSR1A & (1<<RXC1)))
{         
    // monitors if DORn bit is 1 or zero

// first if check if DORn bit is 0 ...if so then proceed , everything is fine
      if((UCSR1A & (1<<DOR1))==0)
        {
            value=UDR1;
            str[i]=value;
            value= '\0';        
            UDR1='\0';         //making the buffer register to null so that it becomes free and empty
    
            UART_TxChar0(str[i]);
        
           
         }
         else
    {  
    // Now DORn bit is set to 1 ..means error is encxountered
            while((UCSR1A & (1<<DOR1)))
           { 

           // read untill UDR1 is read 
            value=UDR1;
            str[i]=dvalue;
            dvalue='\0';
            UDR1='\0';

               UART_TxChar0(dvalue);

           }
            
       }
   
  i++  
}
return i;
}

 So is this right?????

one more thing in which i am not sure is that whether i am making the buffer register empty or not in the code marked as green ???

 

please do provide the suggestions ..or if anybody can help me from source code if they have done similiar thing like this so that i can get idea.... 

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kunalgupta wrote:
Data over run error occurs (DORn=1) when The receive buffer is full (that is, not read) and there is character already present in UDRn buffer

No.

 

Again, UDR is the data buffer.

 

So 'overrun' occurs when UDR is already full (ie, has 2 bytes) and another complete byte has been received into the shift register.

 

Have you forgotten how to properly post source code already?

 

See Tip #1 again!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
char UART_at1(char *str)
{   
    int i=0;
    char value,dvalue;
    
// if RXC bit is 1 then go inside the while loop and it means their is data present to be read
    while ((UCSR1A & (1<<RXC1)))
{         
    // monitors if DORn bit is 1 or zero

// first if check if DORn bit is 0 ...if so then proceed , everything is fine
      if((UCSR1A & (1<<DOR1))==0)
        {
            value=UDR1;
            str[i]=value;
            value= '\0';        
            UDR1='\0';         //making the buffer register to null so that it becomes free and empty
    
            UART_TxChar0(str[i]);
        
           
         }
         else
    {  
    // Now DORn bit is set to 1 ..means error is encxountered
            while((UCSR1A & (1<<DOR1)))
           { 

           // read untill UDR1 is read 
            value=UDR1;
            str[i]=dvalue;
            dvalue='\0';
            UDR1='\0';

               UART_TxChar0(dvalue);

           }
            
       }
   
  i++  
}
return i;
}

here is the code... 

awneil wrote:

So 'overrun' occurs when UDR is already full (ie, has 2 bytes) and another complete byte has been received into the shift register.

 

 

yeah that is what i exactly mean ..and that is why only i am receiving only AT in response from esp8266 as receive buffer is full and it has to be emptied to get new data

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Kunalgupta wrote:

            UDR1='\0';         //making the buffer register to null so that it becomes free and empty

No, it doesn't work like that

 

Take another look at the diagram: when you write to UDR, you are writing to the transmit buffer:

 

 

The hardware knows when you read from UDR - that is what "clears" the byte from the buffer.

 

EDIT

 

Pleas keep your code tidy - adopt a consistent indentation style, and stick to it. Your indentation is currently all over the place.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Jun 4, 2020 - 07:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You seem to have forgotten:

Way back in #26, Kartman wrote:
Find some code that gives you a standard interrupt usart receive with a circular buffet. Standard solution to a common problem.

 

And don't forget that UDR can hold two bytes - so your ISR must allow for that ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

You seem to have forgotten:

Way back in #26, Kartman wrote:
Find some code that gives you a standard interrupt usart receive with a circular buffet. Standard solution to a common problem.

>

Okay ...i thought same thing will happen in interrupt also as thier also only on setting of rxc bit it will go inside the Interrupt vector.

awneil wrote:

 

And don't forget that UDR can hold two bytes - so your ISR must allow for that ...

So that after reading two bytes should i empty the udrn register by flushing it( as shown in datasheet ny equating null== udrn) or read it untill it becomes free

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kunalgupta wrote:
i thought same thing will happen in interrupt

This is true, but in an ISR you just have the very simple task of taking the byte (or bytes) out of UDR, and putting it (them) into your ring buffer.

 

This is very simple, and can be done very quickly. Which is why, as  Kartman  said, it is the standard solution.

 

So that after reading two bytes

I haven't studied the datasheet in great detail, but I didn't see any way to know if there's 1 or 2 bytes in UDR.

 

So it seems you'd have to read UDR once, then check UDRE RXC to see if there's still another byte.  <-- Oops, no: UDRE is for the transmit buffer; RXC is for the receive buffer.

 

should i empty the udrn register by flushing it

"Flushing" means throwing away any data that you're not interested in.

 

But you are interested in the data - so don't flush it!

 

EDIT

 

typo

 

EDIT 2

 

Note that none of this has anything specifically to do with AT commands - this is all just the basic mechanics of getting serial data reception working on the AVR

 

EDIT 3

 

UDRE is for TX - not RX

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jun 5, 2020 - 09:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

I haven't studied the datasheet in great detail, but I didn't see any way to know if there's 1 or 2 bytes in UDR.

 

 

 

 

Here in the datasheet u can see.

 

 

 

Also other thing is ..in the datasheet it is written during normal operation , if error occurs then i should read UDRn so that it becomes empty  till RXCn is cleared.

 

 

 

 

 

 

 

 

 

 

 

Now I am getting OUTPUT like this using Interrupts ...which is same when i am not using interrupts. 

 

 

 

 

 

 

Here u can see as that after i read the UDRE for the second character MY UCSRAn register is 1110100--- meaning that their is more data to come ( as RXCn bit is 1) and aslo DATA OVER RUN is encountered after reading the 2 character (as DORn bit is 1)and in the next instruction cycle i make the character print ...that is here T is printed .

Now as DORn error has been encountered so all the data between the last frame received (that is T ) and next frame which is transfered in buffer register ( which is new line /A ...i checked this by printing output in hexadecimel )  is lost  ...Thus when reading the UDREn after the second character is 01000000, RXCn bit is also getting cleared as  it has directly come to the last character ( which is new line) and data which is in between is lost and thus DORn bit is also cleared.

 

So now What should i do after reading the UDRE for second character so that My UDRE buffer becomes empty and free for reading the next character.... is their any way by which i can make UDREn buffer NULL after receiving two characters ...so that DORn bit is not set to 1.

 

 

 

awneil wrote:

 

But you are interested in the data - so don't flush it!

 

So what should i do ..... how should i empty the buffer  when DOR is detected

 

 

 

CODE...is ... ( and yes i have tried without printing anything from the receiver routine too ...but same thing is happening only 2 characters ----AT is printed )


#include <uarts.h>
#include <avr/delay.h>
#include <avr/interrupt.h>
  char buff[100], huss[100];
  char str[30];
  int m=0;
ISR(USART0_RX_vect)
{  

	char data;
	data=UDR0;

	if(data!='>')
	{
		str[m]=data;
		UART_TxChar0(str[m]);
		m++;

	}    else
	{
		str[m]='\0';
		printString0(str);
		m=0;
	}

}
ISR(USART1_RX_vect)
{   //_delay_ms(100);
	printString0("\nvalue of uscra before reading UDRE \n ");
	bit0(UCSR1A);
	char data;
	data=UDR1;
	printString0(" \nvalue of uscra after reading UDRE \n ");
	bit0(UCSR1A);
	printString0("\n");
	if(data!='>')
	{
		str[m]=data;
		UART_TxChar0(str[m]);
		m++;

	}    else
	{
		str[m]='\0';
		printString0(str);
		m=0;
	}

}
int main(void)
{
	UART_Init0();
	//UART_Init3();		//for printing on serial monitor
UART_Init1();       ///for esp bauddrate is selected 115200
 printString0("******************hellow*****************");
 printString0("\n");
 printString0("receiving  response \n");
sei();
while(1)
	{    

	printString1("AT\r\n");   //sending command to esp8266

 //UART_at1(str);            /* function to receive at commands response*/

//printString0(str);         /* function to print string */
//rxstring0(buff);        /* function to receive string */

	}
}

char UART_at1(char *str)
{   //char x=2;
	int i=0;
	char value;
	while ((UCSR1A & (1<<RXC1)))
  {
    if((UCSR1A & (1<<DOR1))==0)
		{
			value=UDR1;
	        str[i]=value;
			UART_TxChar0(value);
			i++;
		}
		 else
    {
        while((UCSR1A & (1<<DOR1)))
		   {
			   i++;
			   NULL==UDR1;
			   value=UDR1;
			   str[i]=value;
			   UART_TxChar0(value);

		   }

	   }
	}
return i;
}

 

Kunal Gupta

github.com/gkunalupta

Last Edited: Fri. Jun 5, 2020 - 02:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

What on earth has happened in post #40? It is almost entirely unreadable with that huge font !

 

BTW one thing I can see are printstring()s from ISR()s. That is a complete no-no !!

Last Edited: Fri. Jun 5, 2020 - 01:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
post #40? It is almost entirely unreadable with that huge font !

It certainly is!!

 

surprise

 

But note that DOR does not tell you how many bytes are currently in the FIFO - it just tells you that a byte was lost because there was no room for it at the time it arrived.

 

Please see Tip #1 for how to do a screenshot - not as a photo! - and please crop it to only the relevant parts

(this might be what messed-up your post)

 

edit

 

and your indentation is still all over the place.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jun 5, 2020 - 01:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the code did its job properly, then there would be no overruns, thus looking at DOR would not be necessary.
Understand the real time nature of the problem - a character takes a finite amount of time to send. You must be able to process that character before the next one arrives. Calculate how much time between characters. Ensure your code can meet that deadline.
Or just use Arduino and be happy that it does the right thing for you then concentrate on the actual problem you want to solve.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
If the code did its job properly, then there would be no overruns

Indeed - an overrun is an error condition!

 

Because there's been an error, you might want to flush the FIFO - because the data might not be useful.

 

But you don't flush the FIFO in the normal course of events.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i   have edited the font my mistake the size was so clumpsy.

 

well i have tried all the things  and i want to do this project using embedded c only dont want to go for arduino builtin libraries ... so please  can anyone of u put their suggestions in the form of code about what should i do ..or someone can send code on how to handle DATA OVER RUN error.

 

OR just tell in the form of code that how should i code so that DATA over run does not occur.

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

surprise

 

But note that DOR does not tell you how many bytes are currently in the FIFO - it just tells you that a byte was lost because there was no room for it at the time it arrived.

i know that ...this is what i have explained in the above reply and

i just want to know that how should i empty the UDRn register once i come to know about DORn error in such a way that no data is lost and So that my RXCn bit remains 1 if more data is coming.

plss if someone can edit my code with their suggestions ..it will be very greatfull

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Ensure your code can meet that deadline. Or just use Arduino and be happy that it does the right thing for you then concentrate on the actual problem you want to solve.

Any idea u can give that how should i do this.

Kunal Gupta

github.com/gkunalupta

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kunalgupta wrote:
this is what i have explained in the above reply

As noted, that reply is (almost) unreadable - so don't be surprised when people haven't (quite) understood it!

 

how should i empty the UDRn register once i come to know about DORn error in such a way that no data is lost

You can't!

 

DOR is telling you that data has been lost!

 

That's what an overrun means!

 

That data is lost & gone forever.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jun 5, 2020 - 02:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So what should i do ..... Is their no solution for solving this error

Kunal Gupta

github.com/gkunalupta

Last Edited: Fri. Jun 5, 2020 - 02:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

See #26

 

Repeated in #37

 

Your first port of call in that search would be the Application Notes provided by Microchip:

 

https://www.avrfreaks.net/commen...

 

https://www.avrfreaks.net/commen...

 

OR:

 

In #43, Kartman wrote:
Or just use Arduino and be happy that it does the right thing for you then concentrate on the actual problem you want to solve.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jun 5, 2020 - 03:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

something like this

 


ISR(USART0_RX_vect)
{
   char rx_byte;

   // We only ever get here when an RXC interrupt has occurred;
   // Therefore, we know that there must be at least 1 byte in UDR 

   // get the 1st byte
   rx_byte = UDR0;

   // put it into the ring buffer

   // there *might* be a 2nd byte

   if( UCSR0A & (1<<RXC0) )
   {
      // There is a 2nd byte!

      // get the 2nd byte
      rx_byte = UDR0;

      // put it into the ring buffer

   }

   // That's all, folks!
}

 

You will need to do the "put it into the ring buffer"  parts

 

EDIT

 

register numbers!

 

edit 2

 

ATmega640/V-1280/V-1281/V-2560/V-2561/V datasheet wrote:

When interrupt-driven data reception is used, the receive complete routine must read the received data from UDRn in order to clear the RXCn Flag, otherwise a new interrupt will occur once the interrupt routine terminates.

 

So, if you didn't do the check for a 2nd byte in UDR, the interrupt would just repeat - and you'd get that 2nd byte anyhow.

 

I guess it may be a bit more efficient to do the test than to repeat the ISR epilogue & prologue ... ?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jun 5, 2020 - 04:44 PM

Pages