C code for interfacing ESP8266 with AVR mcu

Go To Last Post
140 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Im using AT90can128

Can someone post a complete C code or link to the C code for interfacing ESP8266 with AVR mcu using RS232 through UART..I need the codes for connecting the net and didn't find any example.. Please reply as soon as possible

 

Thanks.. :)

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

I'v wrote this simple code :

 

#include <avr/io.h>
#include "uart_noit_lib.h"
#include "config.h"

void main()
{
    
    uart_init(UART_BAUDRATE);		
    for(;;)
    {
        c_printf_uart("AT\r\n");
    }
}

the functions I use in the main (located in "uart_noit_lib.h") are :

//***************************************************************************
void uart_init(U32 speed)
    {
    UCSRB_N = 0 ;                     // Disable UART
    Uart_set_baudrate(speed);      //Setting the baud rate ,a macro in "uart_no_int_lib.h"
    UCSRA_N = (1<<UDRE_N);
    UCSRC_N = (1<<USBS_N) | (1<<UCSZ1_N) | (1<<UCSZ0_N); //Setting frame format
    UCSRB_N = (1<<RXEN_N) | (1<<TXEN_N);  // then, (re)enable UART. Enabling the Transmitter&Receiver
    }

//***************************************************************************
//  @fn put_char_uart
//!
//! Put character on TX UART. If TxReady, the character to send on TX UART.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param Character to send
//!
//! @return (none)
//!
//***************************************************************************
void put_char_uart (U8 char_2_send)
    {
    while ( !(UCSRA_N & (1<<UDRE_N)) ); // wait for empty transmit buffer 
    UDR_N = char_2_send;
    }

//***************************************************************************
//  @fn c_printf_uart
//!
//! Put a code-string on TX UART. The code-string is send up to null
//! character is found.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param Pointer on U8 code-string
//!
//! @return (none)
//***************************************************************************
//void c_printf_uart (const U8 *c_string)
void c_printf_uart (U8 *c_string)
    {
    while(*c_string) 
        put_char_uart (*c_string++);
    }
//*********************************************************************

But I encountered a problem that even though I see pulses in the scope when I sample the tx pin while sending "AT" , I can't see nothing in the I/O view -->UDR1.

the BAUDRATE is 115200

Why's that ?!

Last Edited: Sun. Sep 13, 2015 - 02:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kobidon wrote:

Im using AT90can128

Can someone post a complete C code or link to the C code for interfacing ESP8266 with AVR mcu using RS232 through UART..I need the codes for connecting the net and didn't find any example.. Please reply as soon as possible

 

Thanks.. :)

I know there might be a language barrier in play here but you can't type 'ESP8266" into google and not find dozens of examples of all sorts, complete projects, forums and entire web sites dedicated to using the ESP8266.

Last Edited: Sun. Sep 13, 2015 - 08:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

 

What about my question ?

 

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

Last Edited: Mon. Sep 14, 2015 - 08:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

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

Arduino *is* AVR.

 

Anyway I just type "ESP8266 AVR" into Google and it saud:

 

http://www.avrfreaks.net/forum/m...

http://tomeko.net/other/ESP8266/

http://hackaday.com/2014/09/17/a...

http://chris-stubbs.co.uk/wp/?p=563

(and other results)

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

JohanEkdahl wrote:

 

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

 

 

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

 

JohanEkdahl wrote:

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.

 

Im using Atmel studio IDE and Im observing it through debug-->window --> I/O view where there I can watch all the ports and registers.

 

JohanEkdahl wrote:

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?

 

I knew you would write it but I put break points right before and after the assignment of the chars (as part of the string I send) inside the put_char function. Even though I can't see nothing written into this register, even not for instance!. 

In addition, I want to get a response from the ESP8266 module like "OK" after parsing "AT\r\n" so I'v wrote this command :

c=get_char_uart();

right after the string parsing. 

The c variable is empty!

 

JohanEkdahl wrote:

What is the original problem you are trying to solve?

 

Im trying to communicate with this module throught uart, i.e : 

1. parsing it "AT\r\n" and waiting for a "OK" reply

2. config it as both an sta and ap point using "AT+CWMODE\r\n" command

3. join access point (my network) using "AT+ CWJAP =<ssid>,< pwd >" command

 

thanks!

Last Edited: Mon. Sep 14, 2015 - 09:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Im using Atmel studio IDE and Im observing it through debug-->window --> I/O view where there I can watch all the ports and registers.

And you have an actual debugger (a piece of hardware) attached? If you're trying to debug UART code with the Simulator in Studio you will not be running the code on the actual chip and hence can observe no actual hardware registers.

 

Have you tried observing the Rx signal with the scope? This might help you determine if the ESP module is not responding, or if it is and there is a problem with reception in the AVR.

 

What does your receive code look like?

 

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Sep 14, 2015 - 09:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

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

JohanEkdahl wrote:

 

And you have an actual debugger (a piece of hardware) attached? If you're trying to debug UART code with the Simulator in Studio you will not be running the code on the actual chip and hence can observe no actual hardware registers.

 

 

Yes, I use this debugger : http://uk.farnell.com/atmel/atjt...

 

JohanEkdahl wrote:

 

Have you tried observing the Rx signal with the scope? This might help you determine if the ESP module is not responding, or if it is and there is a problem with reception in the AVR.

 

 

Yes, I'm sampling the Rx pin with the scope and I actually see pulses, so I guess the ESP is responding. 

 

JohanEkdahl wrote:

 

What does your receive code look like?

 

 

For the first step I want to receive just a single char from the OK string , like 'O' or 'K', so I'v wrote this code line :

 

c=get_char_uart();

 

note that c is variable of type U8 and get_char_uart is this function :

 

//***************************************************************************
//  @fn get_char_uart
//!
//! Get byte from RX UART. If UART has received a character, this character
//! is returned, if no character has been received, 0x00 is returned.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param (none)
//!
//! @return Character from RX UART or 0x00 if nothing received
//!
//***************************************************************************
U8 get_char_uart (void)
    {
    U8  temp;
		
    if (!(UCSRA_N & (1<<RXC_N)))
        {
        temp = FALSE;
        }
        else
            {
            temp = UDR_N;
            }
    return temp;
    }

 

but unfortunately when I run the code step by step nothing is written into the c variable...

 

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

clawson wrote:

Anyway I just type "ESP8266 AVR" into Google and it saud:

You are using a AT90can128 and are having problems using the UART. Search for "AT90can128 C code UART", you will find half a dozen hits.

 

You have three unknowns you are working with: The AT90 code and setup itself, the ESP8266 itself and the problem of using a debugger. That gives 7 possible combinations of things that can be wrong. Test them one at a time.

 

Remove the '8266 from the circuit and test the AT90 serial communication with a terminal program on a PC. Skip the single step debugging.

 

Hook the '8266 to a PC and type the AT commands directly to a terminal program or even write test code to get it working at a higher level. Never done that before? I use processing [https://processing.org/] just because I know it works. Here is a tutorial, skip the Arduino side: https://learn.sparkfun.com/tutor...

 

Now you have two problems which you can solve separately instead of seven possible combinations.

 

 

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

For the first step I want to receive just a single char from the OK string , like 'O' or 'K', so I'v wrote this code line :

 

c=get_char_uart();

 

This is like pulling out ones own teeth...

 

Could you PLEASE show us how you call that function too. And not just a new one-liner. Show the code that sends the AT command and the waits for the answer, i.e. "OK" (if the module has been configured for verbose answers).

 

With the information you have given we can not even determine e.g. if you are calling the receive function so early so that the 'O' has not even arrived yet, or perhaps so late so that several chars have arrived (and thus have put the UART in a "data overrun" error state.

 

Everyone here is a mere human, we can't see what you aren't showing. When you pose a question, before posting it read it through while you put yourself in our situation. What do we need to know? Have you actually told that? Go back, rework, repeat..

 

The burden is on you - everyone here can walk away at any moment if getting tired on doing guesswork. If you want good answers, then work HARD to pose good questions (i.e. give pertinent info etc).

 

-----

 

If you have never written code for UART communication before then Someguy22's advice is the way to go. First get in control by removing devices with unknown behavior from your setup. The AVR and a PC with a serial port running a simple terminal program is probably a good start. When you have that working - BOTH WAYS - but only then, you move on to your module with unknown behavior. Every time you encounter a new strange situation you return to the known and simple setup to try to analyze it.

 

This might seem tough, but that is the way most every professional wrestles down a problem. Reduce, as few unknowns as possible, test every link of the chain separately etc. Divide and conquer.

 

-----

 

Now might also be the time to show a schematic or sketch that is true to what you have on your bench.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Sep 14, 2015 - 11:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

For the first step I want to receive just a single char from the OK string , like 'O' or 'K', so I'v wrote this code line :

 

c=get_char_uart();

 

This is like pulling out ones own teeth...

 

Could you PLEASE show us how you call that function too. And not just a new one-liner. Show the code that sends the AT command and the waits for the answer, i.e. "OK" (if the module has been configured for verbose answers).

 

With the information you have given we can not even determine e.g. if you are calling the receive function so early so that the 'O' has not even arrived yet, or perhaps so late so that several chars have arrived (and thus have put the UART in a "data overrun" error state.

 

Everyone here is a mere human, we can't see what you aren't showing. When you pose a question, before posting it read it through while you put yourself in our situation. What do we need to know? Have you actually told that? Go back, rework, repeat..

 

The burden is on you - everyone here can walk away at any moment if getting tired on doing guesswork. If you want good answers, then work HARD to pose good questions (i.e. give pertinent info etc).

 

you'r right,my mistake, that's why I will put here all the code : 

#include <avr/io.h>
#include "uart_noit_lib.h"
#include "config.h"
#include <string.h>
#include <util/delay.h>

void main()
{
	int i;
	U8 rxstr[50]={};
	
	uart_init(UART_BAUDRATE);		
	while(1)
	{
		c_printf_uart("AT\r\n");
		readString(rxstr);
		if (strcmp(rxstr,"OK")==0)
		{
			for (i=0;i<5;i++) //if ESP response is OK, led blinking 5 times (for debugging)
			{
				DDRC=0xFF;
				PORTC=0x00;
				_delay_ms(1000);
				PORTC=0xFF;
				_delay_ms(1000);

			}
		}
		
	 }
}

and here is the uart.noit.lib.c Im using :

 

//***************************************************************************
//! @file $RCSfile: uart_noit_lib.c,v $
//!
//! Copyright (c) 2005 Atmel.
//!
//! Please read file license.txt for copyright notice.
//!
//! @brief Low level routines for UARTs running without interrupt.
//!
//! These routines need some #define's of "board.h" file.
//!
//! @version $Revision: 2.00 $ $Name: jtellier $ 
//!
//! @todo
//! @bug
//***************************************************************************
//-----------------------------------------------------------------------
// Exemple of "x_printf_uart" using
// ================================
//
// #define FOSC          8000        // in KHz
// #define BAUDRATE      9600        // in K bit/s
// #define USE_UART         0        // only UART-0 will be used !
//
// U8 s_printf[80];  // 80 elements max for UART buffer
//
// uart_init(); // Setup UART at BAUDRATE (9600) Baud
//
// c_printf_uart("Counting from 0 to 9: ");
//
// for (i=0; i<10; i++) s_printf[i]=0x30+i;    // Init UART buffer
// s_printf[i++]=0x0D;            // "\r" - carriage return
// s_printf[i++]=0x0A;            // "\n" - new line or line feed
// s_printf[i++]=0x00;            // Null - End of string
// d_printf_uart(s_printf);
// 
//------------------------------------------------------------------------

//_____  I N C L U D E S ___________________________________________________

#include <stdio.h>
#include "config.h"
#include "uart_noit_lib.h"

//_____ M A C R O S ________________________________________________________

//_____ D E F I N I T I O N S ______________________________________________

//_____ D E C L A R A T I O N S ____________________________________________


//***************************************************************************
//  @fn uart_init
//!
//! UART initialization. Initialize the UART reffered by USE_UART definition
//! to BAUDRATE speed. 
//! Initialization details: 8-bit, no parity, 2 stop-bit & no interrupt.     
//!
//! @warning Set definition for BAUDRATE
//!
//! @param (none)
//!
//! @return (none)
//!
//***************************************************************************
void uart_init(U32 speed)
    {
    UCSRB_N = 0 ;                     // Disable UART
    Uart_set_baudrate(speed);      //Setting the baud rate ,a macro in "uart_no_int_lib.h"
    UCSRA_N = (1<<UDRE_N);
    UCSRC_N = (1<<USBS_N) | (1<<UCSZ1_N) | (1<<UCSZ0_N); //Setting frame format
    UCSRB_N = (1<<RXEN_N) | (1<<TXEN_N);  // then, (re)enable UART. Enabling the Transmitter&Receiver
	}
	
//***************************************************************************
//  @fn get_char_uart
//!
//! Get byte from RX UART. If UART has received a character, this character
//! is returned, if no character has been received, 0x00 is returned.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param (none)
//!
//! @return Character from RX UART or 0x00 if nothing received
//!
//***************************************************************************
U8 get_char_uart (void)
    {
    U8  temp;
		
    if (!(UCSRA_N & (1<<RXC_N)))
        {
        temp = FALSE;
        }
        else
            {
            temp = UDR_N;
            }
    return temp;
    }

//***************************************************************************
//  @fn c_get_string_uart
//!
//! Put a code-string on RX UART. 
//!
//! @warning "uart_init()" must be performed before
//!
//! @param Pointer on U8 code-string
//!
//! @return (none)
//***************************************************************************
//void readString(U8 *rxstr)

void readString(U8 *rxstr)
{

	while((*rxstr = get_char_uart()) != '\n')
		++rxstr;
}

//***************************************************************************
//  @fn put_char_uart
//!
//! Put character on TX UART. If TxReady, the character to send on TX UART.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param Character to send
//!
//! @return (none)
//!
//***************************************************************************
void put_char_uart (U8 char_2_send)
    {
    while ( !(UCSRA_N & (1<<UDRE_N)) ); // wait for empty transmit buffer 
    UDR_N = char_2_send;
    }

//***************************************************************************
//  @fn c_printf_uart
//!
//! Put a code-string on TX UART. The code-string is send up to null
//! character is found.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param Pointer on U8 code-string
//!
//! @return (none)
//***************************************************************************
//void c_printf_uart (const U8 *c_string)
void c_printf_uart (U8 *c_string)
    {
    while(*c_string) 
		put_char_uart (*c_string++);
	}


and the config.h Im using :

//**************************************************************************
//! @file $RCSfile: config.h,v $
//!
//! Copyright (c) 2005 Atmel.
//!
//! Please read file license.txt for copyright notice.
//!
//! @brief Configuration file for this project.
//!
//! @version $Revision: 2.00 $ $Name: jtellier $
//!
//! @todo
//! @bug
//**************************************************************************

#ifndef _CONFIG_H_
#define _CONFIG_H_

//_____ I N C L U D E S ____________________________________________________

// Please declare _IAR_AVR_ in Compiler options if IAR Compiler is used,
//     or declare _IMC_AVR_ in Compiler options if ImageCraft Compiler is used.

#   include "compiler.h"

#ifndef _AVR_IO_H_
#define _IMC_AVR_

#include "mcu.h"
#endif

//_____ M A C R O S _________________________________________________________

//_____ D E F I N I T I O N S _______________________________________________

    // -------------- MCU LIB CONFIGURATION
#define FOSC           8000        // 8 MHz External cristal
#define USE_UART		1
#define UART_BAUDRATE      115200        // in bps

 

-----

JohanEkdahl wrote:

If you have never written code for UART communication before then Someguy22's advice is the way to go. First get in control by removing devices with unknown behavior from your setup. The AVR and a PC with a serial port running a simple terminal program is probably a good start. When you have that working - BOTH WAYS - but only then, you move on to your module with unknown behavior. Every time you encounter a new strange situation you return to the known and simple setup to try to analyze it.

 

This might seem tough, but that is the way most every professional wrestles down a problem. Reduce, as few unknowns as possible, test every link of the chain separately etc. Divide and conquer.

 

 

I'v never written code for UART communication (It's my first steps) but I connected the ESP to the computer through ftdi and I checked its communication with termite terminal. Everything worked fine! 

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

I connected the ESP to the computer through ftdi and I checked its communication with termite terminal. Everything worked fine! 

And...? As I see it this indicates one of two "major suspects":

 

- A wiring fault. Or something similar, like a signal level mismatch.

 

- A fault in the UAR receiving code. For this, cut the ESP out of the picture for now, connect your AVR to a serial port or UART on the PC and use a terminal program to send characters to the AVR. You now have absolute control of the "lab situation" and can send just one character and see what happens at the AVR side. As you have a true hardware debugger, you should be able to poke around in the reception status bits for the UART and see if there is a character received, or if there is a reception error.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Sep 14, 2015 - 02:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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'.)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:

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?

 

The get_char_uart() function come out of a library but the read_string() didn't come - I'v wrote it by myself. 

I addition, I upgraded it to :

 

void readString(U8 *rxstr)
{
	U8 *head=rxstr;
	
	while(1) 
	{
		if ((*rxstr = get_char_uart()) == FALSE) // if there is nothing waiting in the Rx pin, continue wait
			continue;
		
		if (*rxstr == '\n')
		{
			break;
		}
		rxstr++;
	}
		
	*rxstr='\0';
	rxstr=head;
}

JohanEkdahl wrote:

 

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'm not sure what do you mean by "echoing". Can you please explain me by giving me an example ?

 

JohanEkdahl wrote:

 

BTW, if the ESP 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'.)

 

Note that before connecting the ESP to the AVR I'v checked it by connecting it directly to the computer using FTDI( ttl to usb) and communicating with it through the terminal. 

The terminal called termite and it gaves me the option to append CR-LF to the transmitted message. So I'v tested it with \r\n, that's why I'm actually sending this message without any fear of hurting the device (see the attached picture).

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

The bottom line is that now I receive characters through the Rx pin in the mcu but I'm not receiving the right "OK" message Im expecting to while sending "AT\r\n".

I receive that message :

97 in asci (=a)

116 in asci (=t)

10 in asci (=line feed)

 

and that's it! without any OK after that!

I tried to change the if statement (in the read_string() function I'v write) to : 

if (*rxstr == 'k') 

expecting just the 'O' letter but nothing!

 

really appreciate any help. 

thanks!

 

 

Last Edited: Tue. Sep 15, 2015 - 05:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How long do you wait for the response?
Wire up your serial->usb to sniff the comms from the esp to the avr to see what is really happening.

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

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.

 

 

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Is there an echo in here? Or was this website running slow?

 

[duplicate post removed - Cliff]

Last Edited: Wed. Sep 16, 2015 - 10:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Maybe the sysop has echo turned on in the forum software.

 

Imagecraft compiler user

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

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

Ross McKenzie ValuSoft Melbourne Australia

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

Hi again,

 

I turned off the echo by connecting directly the ESP via FTDI usb to ttl to the PC giving its "ATE0" command, the reply was OK.

so mission 1 succeeded !

 

Now my code looks like :

 

#include <avr/io.h>
#include "uart_noit_lib.h"
#include "config.h"
#include <string.h>
#include <util/delay.h>

void main()
{
    int i;
    U8 rxstr[30]={};
    
    uart_init(UART_BAUDRATE);		
    while(1)
    {
        c_printf_uart("AT\r\n");
        readString(rxstr);
    }
    
 //***************************************************************************
//! @file $RCSfile: uart_noit_lib.c,v $
//!
//! Copyright (c) 2005 Atmel.
//!
//! Please read file license.txt for copyright notice.
//!
//! @brief Low level routines for UARTs running without interrupt.
//!
//! These routines need some #define's of "board.h" file.
//!
//! @version $Revision: 2.00 $ $Name: jtellier $ 
//!
//! @todo
//! @bug
//***************************************************************************
//-----------------------------------------------------------------------
// Exemple of "x_printf_uart" using
// ================================
//
// #define FOSC          8000        // in KHz
// #define BAUDRATE      9600        // in K bit/s
// #define USE_UART         0        // only UART-0 will be used !
//
// U8 s_printf[80];  // 80 elements max for UART buffer
//
// uart_init(); // Setup UART at BAUDRATE (9600) Baud
//
// c_printf_uart("Counting from 0 to 9: ");
//
// for (i=0; i<10; i++) s_printf[i]=0x30+i;    // Init UART buffer
// s_printf[i++]=0x0D;            // "\r" - carriage return
// s_printf[i++]=0x0A;            // "\n" - new line or line feed
// s_printf[i++]=0x00;            // Null - End of string
// d_printf_uart(s_printf);
// 
//------------------------------------------------------------------------

//_____  I N C L U D E S ___________________________________________________

#include <stdio.h>
#include "config.h"
#include "uart_noit_lib.h"

//_____ M A C R O S ________________________________________________________

//_____ D E F I N I T I O N S ______________________________________________

//_____ D E C L A R A T I O N S ____________________________________________


//***************************************************************************
//  @fn uart_init
//!
//! UART initialization. Initialize the UART reffered by USE_UART definition
//! to BAUDRATE speed. 
//! Initialization details: 8-bit, no parity, 2 stop-bit & no interrupt.     
//!
//! @warning Set definition for BAUDRATE
//!
//! @param (none)
//!
//! @return (none)
//!
//***************************************************************************
void uart_init(U32 speed)
    {
    UCSRB_N = 0 ;                     // Disable UART
    Uart_set_baudrate(speed);      //Setting the baud rate ,a macro in "uart_no_int_lib.h"
    UCSRA_N = (1<<UDRE_N);
    UCSRC_N = (1<<USBS_N) | (1<<UCSZ1_N) | (1<<UCSZ0_N); //Setting frame format
    UCSRB_N = (1<<RXEN_N) | (1<<TXEN_N);  // then, (re)enable UART. Enabling the Transmitter&Receiver
	}
	
//***************************************************************************
//  @fn get_char_uart
//!
//! Get byte from RX UART. If UART has received a character, this character
//! is returned, if no character has been received, 0x00 is returned.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param (none)
//!
//! @return Character from RX UART or 0x00 if nothing received
//!
//***************************************************************************
U8 get_char_uart (void)
{
	U8 temp;
	
    if (!(UCSRA_N & (1<<RXC_N)))
		// Do nothing cause there is no any data on the Rx pin
		temp=FALSE;
	else
		//Now USART has got data from host
		//and is available is buffer
		temp = UDR_N;
    return temp;
    }

//***************************************************************************
//  @fn c_get_string_uart
//!
//! Put a code-string on RX UART. 
//!
//! @warning "uart_init()" must be performed before
//!
//! @param Pointer on U8 code-string
//!
//! @return (none)
//***************************************************************************
//void readString(U8 *rxstr)

void readString(U8 *rxstr)
{
	U8 *head=rxstr;
	
	while(1)
	{
		*rxstr = get_char_uart();
		if (*rxstr == FALSE) // if there is nothing waiting in the Rx pin, continue sample
			continue;
		if (*rxstr == '\n')
			{
				rxstr++;
				break;
			}
		rxstr++;
	}	
	
	*rxstr='\0';
	rxstr=head;
}

//***************************************************************************
//  @fn put_char_uart
//!
//! Put character on TX UART. If TxReady, the character to send on TX UART.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param Character to send
//!
//! @return (none)
//!
//***************************************************************************
void put_char_uart (U8 char_2_send)
    {
    while ( !(UCSRA_N & (1<<UDRE_N)) ); // wait for empty transmit buffer 
    UDR_N = char_2_send;
    }

//***************************************************************************
//  @fn c_printf_uart
//!
//! Put a code-string on TX UART. The code-string is send up to null
//! character is found.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param Pointer on U8 code-string
//!
//! @return (none)
//***************************************************************************
//void c_printf_uart (const U8 *c_string)
void c_printf_uart (U8 *c_string)
    {
    while(*c_string) 
		put_char_uart (*c_string++);
	}

but unfortunately after debugging step by step (with breakpoints) I get:

'97' (in the rxstr string) which in ASCII equals the letter 'A'

then

116 which in ASCII equals the letter 'T'

finally 10 which in ASCII equals the '\0' .

 

Just to have a feeling how things work with my ESP (in BLUE - the AT command I send and in GREEN - the response) :

 

 

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

also, I'm not quite sure about the correctness of that line (in the readstring() function) : 

if (*rxstr == '\n')
	break;

can someone have an Idea how does it should look like ?

 

any help will be really appreciated!

Last Edited: Wed. Sep 16, 2015 - 02:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Wed. Sep 16, 2015 - 08:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The point is that I'm currently implementing a ring buffer (rxstr) in my code (see the changes (highlighted with a yellow color) in the main and in the read_string()) :

#include <avr/io.h>
#include "uart_noit_lib.h"
#include "config.h"
#include <string.h>
#include <util/delay.h>

void main()
{
	int i;
	U8 rxstr[30]={};
	
	uart_init(UART_BAUDRATE);	
	c_printf_uart("AT\r\n");	
	while(1)
	{
		readString(rxstr);
		if (strcmp(rxstr,"OK")==0)
		{
			for (i=0;i<5;i++) //led blinking 5 times
			{
				DDRC=0xFF;
				PORTC=0x00;
				_delay_ms(1000);
				PORTC=0xFF;
				_delay_ms(1000);
                                break;
			}
		}
                memset(rxstr,0,sizeof(rxstr));
	 }
}

//***************************************************************************
//! @file $RCSfile: uart_noit_lib.c,v $
//!
//! Copyright (c) 2005 Atmel.
//!
//! Please read file license.txt for copyright notice.
//!
//! @brief Low level routines for UARTs running without interrupt.
//!
//! These routines need some #define's of "board.h" file.
//!
//! @version $Revision: 2.00 $ $Name: jtellier $ 
//!
//! @todo
//! @bug
//***************************************************************************
//-----------------------------------------------------------------------
// Exemple of "x_printf_uart" using
// ================================
//
// #define FOSC          8000        // in KHz
// #define BAUDRATE      9600        // in K bit/s
// #define USE_UART         0        // only UART-0 will be used !
//
// U8 s_printf[80];  // 80 elements max for UART buffer
//
// uart_init(); // Setup UART at BAUDRATE (9600) Baud
//
// c_printf_uart("Counting from 0 to 9: ");
//
// for (i=0; i<10; i++) s_printf[i]=0x30+i;    // Init UART buffer
// s_printf[i++]=0x0D;            // "\r" - carriage return
// s_printf[i++]=0x0A;            // "\n" - new line or line feed
// s_printf[i++]=0x00;            // Null - End of string
// d_printf_uart(s_printf);
// 
//------------------------------------------------------------------------

//_____  I N C L U D E S ___________________________________________________

#include <stdio.h>
#include "config.h"
#include "uart_noit_lib.h"

//_____ M A C R O S ________________________________________________________

//_____ D E F I N I T I O N S ______________________________________________

//_____ D E C L A R A T I O N S ____________________________________________


//***************************************************************************
//  @fn uart_init
//!
//! UART initialization. Initialize the UART reffered by USE_UART definition
//! to BAUDRATE speed. 
//! Initialization details: 8-bit, no parity, 2 stop-bit & no interrupt.     
//!
//! @warning Set definition for BAUDRATE
//!
//! @param (none)
//!
//! @return (none)
//!
//***************************************************************************
void uart_init(U32 speed)
    {
    UCSRB_N = 0 ;                     // Disable UART
    Uart_set_baudrate(speed);      //Setting the baud rate ,a macro in "uart_no_int_lib.h"
    UCSRA_N = (1<<UDRE_N);
    UCSRC_N = (1<<USBS_N) | (1<<UCSZ1_N) | (1<<UCSZ0_N); //Setting frame format
    UCSRB_N = (1<<RXEN_N) | (1<<TXEN_N);  // then, (re)enable UART. Enabling the Transmitter&Receiver
	}
	
//***************************************************************************
//  @fn get_char_uart
//!
//! Get byte from RX UART. If UART has received a character, this character
//! is returned, if no character has been received, 0x00 is returned.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param (none)
//!
//! @return Character from RX UART or 0x00 if nothing received
//!
//***************************************************************************
U8 get_char_uart (void)
{
	U8 temp;
	
    if (!(UCSRA_N & (1<<RXC_N)))
		// Do nothing cause there is no any data on the Rx pin
		temp=FALSE;
	else
		//Now USART has got data from host
		//and is available is buffer
		temp = UDR_N;
    return temp;
    }

//***************************************************************************
//  @fn c_get_string_uart
//!
//! Put a code-string on RX UART. 
//!
//! @warning "uart_init()" must be performed before
//!
//! @param Pointer on U8 code-string
//!
//! @return (none)
//***************************************************************************
//void readString(U8 *rxstr)

void readString(U8 *rxstr)
{
	U8 *head=rxstr;
	
	while(1)
	{
		*rxstr = get_char_uart();
		if (*rxstr == FALSE) // if there is nothing waiting in the Rx pin, continue sample
			continue;
		if (*rxstr == '\n')
			{
				rxstr++;
				break;
			}
		rxstr++;
	}	
	
	*rxstr='\0';
	rxstr=head;
}

//***************************************************************************
//  @fn put_char_uart
//!
//! Put character on TX UART. If TxReady, the character to send on TX UART.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param Character to send
//!
//! @return (none)
//!
//***************************************************************************
void put_char_uart (U8 char_2_send)
    {
    while ( !(UCSRA_N & (1<<UDRE_N)) ); // wait for empty transmit buffer 
    UDR_N = char_2_send;
    }

//***************************************************************************
//  @fn c_printf_uart
//!
//! Put a code-string on TX UART. The code-string is send up to null
//! character is found.
//!
//! @warning "uart_init()" must be performed before
//!
//! @param Pointer on U8 code-string
//!
//! @return (none)
//***************************************************************************
//void c_printf_uart (const U8 *c_string)
void c_printf_uart (U8 *c_string)
    {
    while(*c_string) 
		put_char_uart (*c_string++);
	}

You can see that I'm sampling the Rx pin char by char and inserting it into a buffer (rxstr) untill a '\n' character is reached (as expected upon the protocol). Then I'm checking the string in the buffer and comparing it to 'OK'. If it's not equals 'OK' then I'm cleaning the rxstr buffer and getting back to sample the Rx pin waiting for a characters to arrive in order to insert it into the rxstr buffer but I'm getting nothing (!!!!) after the echo (if it's really an echo).

Upon the protocol I'm expecting to get :

echo (of what I send) - I get it (see the attached photo)

\n

\n

OK\n

 

I'm stuck in that Im not getting any 'OK' (and actually nothing after the echo)  just that echo and I don't understand why... (even though I continue to run after the breakpoint, still waiting for a characters to arrive).

Last Edited: Thu. Sep 17, 2015 - 06:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. Sep 17, 2015 - 07:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Know what ? 

 

Now, I'm not sure I really writing into the device , i.e not sure I really succeeded sending the msg to the avr pin and I will explain what expreriment I did :

1. I connected the ESP to the PC and sent a command message 'AT+CWMODE=2' for configuring its mode as 2 (STA=1,AP=2,BOTH=3). The response was 'AT+CWMODE=2' then 'OK'.

2. I connected the ESP to the MCU and I sent a command "AT+CWMODE=1" through the mcu into the device (expecting to change its mode from 2 to 1).

3. Then, in order to see if the configuration succeeded, I connected the ESP back to the PC and sent a query message AT+CWMODE? and the response was unfortunately 2.

 

So, in conclusion, I have a problem with the sending and that's why (guess) I'm not receiving anything back.

What's strange in all this story is that in the scope I see pulses as if something flows in the tx pin of the mcu...

 

If anyone have an idea why I will be glad to hear ...

 

thanks!

Last Edited: Thu. Sep 17, 2015 - 07:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like you've wired rx and tx backwards or you still have the interface to the PC wired.

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

I thought it was but I checked it for a 1000 times and the wiring is OK  :(

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

How have you proved this? What evidence do you have?
I'd be using an oscilloscope to check both the levels and the timing. No 'scope? Use your PC's sound card.
Have you determined the baud rate error?
Have you sniffed the data?

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

So, in conclusion, I have a problem with the sending and that's why (guess) I'm not receiving anything back.

Don't jump to conclusions. You have previously said that you receive the "AT..." line. That is the echo thaty the ESP module sends back to the AVR. So you are, or at least where, receiving.

 

I repeat what I tried to express eralier: The settings you do might very well be lost every time you power-cycle the ESP module. That is why you still see an echo, i.e. every time the module is power cycled the ATE0 that you've sent is forgotten and the module is back to the E1 setting that is the power-up default.

 

Now, go to the ESP data sheet and check out what the default is for the +CWMODE setting, and also try to figure out if it is volatile or preserved between power-cycles. AND do this simple experiment:

1. Connect the ESP to your PC 

2. Power-cycle the ESP

3. Send AT+CWMODE=2

4. Check that it it  actually happened by sending AT+CWMODE?

5. Power-cycle the ESP again

6. Send AT+CWMODE?

 

Then draw your conclusions. You might be correct above, but you base it on very weak circumstantial evidence.

 

I see from most all of the above that you're not taking in much of what I'm typing. Every time I try to explain (based on many years here, and uncountable serial comms threads) what is your core problem(s) you bounce off into a different direction. That's OK - in the end it is you who decides how to attack the problem. Nevertheless, since my advice has little (close to none at all) impact I'll stop for now. It is not worth it for me spending the time reading, analyzing and writing responses when they are not considered. Still, I wish you good luck!

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. Sep 17, 2015 - 08:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear Johan,

I'm really sorry to hear that you'r thinking like that. I really appreciate your efforts to guide me, taking your advises seriously and Its really help me. Please stay.

I'm actually trying to implement what you advised me to - using a receive interrupt and a circular/ring buffer for the receiving. 

In addittion , I did the experiment you advised me to (see the attached photo) and the conclusion is that it's not a volatile after Power-cycle

One can see that I Power-cycled the ESP by the gibberish line  (which occuered when taking it out and connecting it again) and the CWMODE stayed 3 after it as configured before.

 

Last Edited: Thu. Sep 17, 2015 - 09:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I'll do the searches for you. What is unavoidable is that it is you who must do the reading.

 

Interrupt driven serial communications tutorial: http://www.avrfreaks.net/forum/t...

 

Perhaps read this first: Basics of UART communication tutorial: http://www.avrfreaks.net/forum/t...

 

Note that for both those the author Dean Camera says he has updated version on his own web site.

 

Generic explanation of what a circular buffer is and how it works: https://en.wikipedia.org/wiki/Ci...

 

A lightweight ring buffer implementation, written by the same Dean Camera that wrote the two tutorials above: http://www.fourwalledcubicle.com... . You will likely want to modify the size of the buffer, ad you will need to complement it with the functions to "peek" into the buffer to see if there is a complete line waiting.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Thanks a lot !

I'll start reading it now.

Last Edited: Thu. Sep 17, 2015 - 10:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So if I understand right, the ISR should replace the call for get_char() and ReadString() functions.In case that when a string will suddenly appear in the Rx pin the interrupt will begin immediately. 

Am I right ?

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

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.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

What would happen if one detects the EOL char in the interrupt?

ie, instad of (taken from http://www.pobot.org/IMG/html/us... )

SIGNAL (SIG_UART_RECV) { 
    // lecture du caractère reçu
    char c = UDR ; // c has just been received

    // si buffer pas plein, on le stocke
    if (rxdesc.nbchars < rxdesc.size) {
        // stockage du caractère
        rxbuff[rxdesc.head] = c ;
        // avance du pointeur de tête avec gestion du rebouclage
        if (++rxdesc.head == rxdesc.size) rxdesc.head = 0 ;
        // actualisation du nombre de caractères en attente
        rxdesc.nbchars++ ;
    }
}

There were a global variable  EolnDetected main can set to zero and ISR sets to 1 (say)

ISR (USART_RXC_vect ) { // new ISR
    // lecture du caractère reçu
    char c = UDR ;

    // si buffer pas plein, on le stocke
    if (rxdesc.nbchars < rxdesc.size) { // if buffer is not full, stores received char
        // stockage du caractère
        rxbuff[rxdesc.head] = c ;
        // avance du pointeur de tête avec gestion du rebouclage
        if (++rxdesc.head == rxdesc.size) rxdesc.head = 0 ; // head pointer is increased %% size -circular buffer-
        // actualisation du nombre de caractères en attente
        rxdesc.nbchars++ ; // 
    }
    if (c == EOL) {EolnDetected = 1;} // untested
}
Last Edited: Tue. Sep 22, 2015 - 04:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

Imagecraft compiler user

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

What would happen if one detects the EOL char in the interrupt?

That is also a possibility. As long as the analysis/parsing of the received data does not go into the ISR, I would probably be OK with that alternative. Apart from this: Looking for a complete line is something that belongs to the ring buffer per se. Eventually you might want to break the ring-buffer code out to a separate file and then you'd want to take the function peeking into the buffer with you to that file.

 

Dean's ring buffer (linked to above) has it's code in a .h file, which is OK as long as you make all functions static inline (and don't allocate any data), and the "peeker" could/should go there (also static inline, of-course).

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Wed. Sep 23, 2015 - 06:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

 

kobidon wrote : 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.

 

 

I have a uart.c library which handles the uart , I ponder where to place the ISR in my code :

 
1.  Replacing the get_char() with the ISR inside the uart.c library.

2. leaving the get_char() and placing the ISR in the main.

 

what is your advice ?

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

1.  Replacing the get_char() with the ISR inside the uart.c library.

2. leaving the get_char() and placing the ISR in the main.

This two discussions at once!

 

a. Whether to replace or leave get_char()

b. where to place an ISR

 

Re a. I'm fairly sure I've described what I think is the perfect structure for these kinds of problems. An ISR runs on reception on thhe USART and inserts the received data into the ring buffer. Other functions take stuff out of the ring buffer.

 

Whether you need a function that gets a single received character I don't know. IF you do, then it should get it out of the ring buffer and you might name it get_char().

 

Re b. I seem to recall that there was a problem with placing ISRs in source files other than the one holding main(). I'm sure that problem is long gone.

 

I would place the ISR in the same source file that holds the definition (NOT necessarily the declaration) of the ring buffer. No, wait.. In same file the file that has the USART init code. No wait! In the same file as main! Ahwww... It is not critical, and you can change it if you eventually change you mind. (And really, I would place it in the file with the USART init code.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Tue. Oct 6, 2015 - 02:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK then, I followed your instructions and I coded something initially (using a ring buffer and implemented the ISR i.e interrupt driven) that meant to read a string from the rx pin by ISR (without dealing with edge cases, for the first steps, like checking EOL) but it seems not to work and I don't know why. 

 

my code is :

 

#include <avr/io.h>
#include <avr/interrupt.h> // ISR handling.
#include "uart_noit_lib.h" // routines for UART comms.
#include "config.h"

#define BUFFER_SIZE 100 // size of Rx ring buffer.

/*
 Global Variables:
 Variables appearing in both ISR/Main are defined as 'volatile'.
*/
volatile int rxn=0; // buffer 'element' counter.
volatile U8 rxstr[BUFFER_SIZE]; // buffer of 'char'.
volatile uint8_t rxFlag = 0; //entire byte wasted for using a single bit


//Interrupt Service Routine (ISR) - only serviced whenever the USART hardware module receives a byte of data in the rx pin
ISR(USART1_RX_vect)
{
	while ( !(UCSRA_N & (1<<RXC_N)) ); // Do nothing cause there is no any data on the Rx pin
	if (rxn == BUFFER_SIZE) // if BUFFER_SIZE is reached, reset to start of buffer.
		rxn=0;
	rxstr[rxn++] = UDR_N; // increment rxn and return new value.
	rxFlag=1; //  Interrupt 'flag' being reset to notify main() of receipt of data (the byte held in the register 'UDR' is read)
}

void main()
{	
	int i;

	uart_init(UART_BAUDRATE);
	UCSRB_N |= (1<<RXCIE1); // Enable the USART Receive complete interrupt (USART_RXC)
	sei(); // Enable the Global Interrupt Enable flag so that interrupts can be processed
	c_printf_uart("AT\r\n");
	
	while (1) 
	{
	if (rxFlag==1)
		{
			for (i=0;i<rxn;i++)
				put_char_uart(rxstr[i]);
			rxFlag=0;
			put_char_uart("'\n'");
		}
	}
}

 

what my program is doing right now is echoing back what it receive.

So I checked the transmit (by connecting the MCU to the PC [through a ttl to usb converter) with the same baudrate as my module has] and I get AT on the screen, i.e sending AT commands succeeded.

I also wanted to check the implementation of the ISR by also sampling the tx pin (also by connecting the MCU to the PC [through a ttl to usb converter) with the same baudrate as my module has]) but I didn't get OK response transmitted back.

 

Where am I wrong :/ ?  

any help will be very appreciated

Last Edited: Thu. Oct 8, 2015 - 07:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Excuse me, but you should look the way a circular ringbuffer works :

they all have two indexes/ pointers,

 

one showing the place one last read  -it is incremented *after* reading- deans camera/abcminiuser calls it Buffer->Out;

 

the other showing the placce one last wrote , incremented *before* inserting -called Buffer-> In in http://www.fourwalledcubicle.com...

 

Having two indexes/ pointers allows to write, say, at the 3rd byte while being allowed to read from the 250th to the 2nd byte.

From your code I see only One index....

 

abcminiueser adds a function to tell whether buffer is empty RingBuffer_IsEmpty, which should be tested ** before ** getting a char from the buffer (arduino, when induly invoking  its "getchar", returns -1 -which is a forbidden value-. You should invoke this function before reading... it suspends interrupts -with atomic blocks- before computing -very fast- whether chars are avalaible for reading...., then restors them...

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

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.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Wait wait, I want to go step by step and understand why it's not working. 

 

I'v got a weird warning by the compiler in this line : ISR(USART1_RXC_vect)

 

the warning is : Warning    7    'USART1_RXC_vect' appears to be a misspelled signal handler [enabled by default]

 

when I switch it to ISR(USART1_RX_vect) i don't get any error.

I'v looked in the data sheet of the at90can128 (page 61), the vector number is 33 and it's match my mcu header :

#define    USART1_RXC_vect      33

 

why's that waning ?? 

 

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

JohanEkdahl wrote:

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.

 

I'v read all you gave me to read but I also searched in this forum for TUT and I found this :

http://www.avrfreaks.net/forum/tutsoft-interrupt-driven-uart-receive-ring-fifo-buffer?skey=ring%20buffer

 

so I thought maybe there is another way to implement it (I noticed there isn't any head and tail in the implementation in the ringbuffer )

 

Last Edited: Mon. Oct 12, 2015 - 01:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wonder how can i debug ESP8266 with AVR 328p? I have ESP8266 and it works fine with my adurino as adurino has softserial lib, so I can easily debug with esp8266 through different serial comport. But when I move to AVR, it doesnt have this lib, I dont know how to debug ? I made Uart working, so I can talk to AT 328p through serial port. BUt how should i make AT 328p talk to ESP 8266(send AT commands) and to my PC (display the staffs receive from ESP8266) at same time, so I can debug? Is that possible?

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

You can use the Arduino code with a virgin mega328. Otherwise, use the Arduino softserial library code.

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

Hi,

 

I'm trying to connect to my ESP8266 via my arduino MEGA 2560. I am not using Arduino App, but working with Atmel Studio, and I have programed USART before. But I just can't understand how to work with the ESP8266. Is there someone who can help me, or just send me at copy of Atmel C-code, that I can test with and learn form to write my own..?

 

Best Regards

Ragnar Hentze

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

I can help but first you need to give me further details :

1. What exactly you want to do with it

2. In what stage with the ESP are you in (newbie ?) ?

3. Did you succeeded communicating with the PC through USART ?

 

My advice for you is start reading that manual :

https://acrobotic.com/downloads/ESP8266_at_commands.pdf

 

also to download and read this document :

4B-ESP8266__AT Command Examples__EN_v1.3

 

 

 

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

1. I want to connect it to my router at home and send commands with my phone to the esp/arduino. I want to program my arduino, not to use the mcu on the esp, only the wifi.
2.ESP modul i am a newbie. I have read many articals og seen many videos, but can't figur it out.
3. I have used usart to many things before, but not worked to "talk" with the esp.

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

Most of the esp modules come with the AT command code already loaded. There's lots of examples on how to connect it to Arduino on the web.

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

Yeah with the Arduino App, but I want to use Atmel studio and start from bottom..:)

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

Hentze90 wrote:

Yeah with the Arduino App, but I want to use Atmel studio and start from bottom..:)

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

 

Quebracho seems to be the hardest wood.

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

I know, but I want to use the ESP to tell my MEGA2560 what to do via USART.

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

You want to start from the bottom, but yet have no idea how to do it but yet there's many working examples. You've got a mega2560, so why not try the Arduino solution first, then try converting the code away from Arduino. You don't even need an Arduino board - the tools generate a file you can flash directly.

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

Ok I have read many commands, and I want to use them, but I only have an mega2560 so to execute an command to the i have to get the esp and mega connected via usart, and i will use the commands pre defined. But i can't get any thing from the esp.
The esp constantly have at red LED turnd on is that ok?

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

What ESP module do you have?
http://www.allaboutcircuits.com/projects/breadboard-and-program-an-esp-01-circuit-with-the-arduino-ide/

Tells me the red led is the power led. At least you have power.

Note that the Arduino mega is just a mega2560 on a pcb with some connectors, crystal and a usb to serial converter - there is no magic. You can look at the schematic to find out what pins on the connectors go to pins on the mega2560. You will need a crystal on your mega2560.
All your questions are answered by Google.

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

Hi Kobidon,

 

Use baudrate 9600, it will work.

Maulik

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

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

 

Soul

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

hello friends , i stucked at some place while working with Atmega32A and ESP8266-01.

I made a program and it send 3 commands

AT

AT+CIPMUX=1

AT+CWSAP="SSID","PASS"

And i m using Serial monitor to analyse the ESP response Towards send commands, so what i am receiving is

AT

OK

 

 

thats it it stucked there.....

 

i m giving them delay of 200 ms 

but when i remove delay it shows

AT

AT+CIPMUX=1

AT+CWSAP="SSID","PASS"

busyp...

OK 

 

which means it respond to 1st command only rest were untouched i guess not even read by esp.

Please help.

Manish verma

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

staring.net@gmail.com wrote:
And i m using Serial monitor to analyse the ESP response Towards send commands, so what i am receiving is

AT

OK

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 

Last Edited: Thu. Oct 26, 2017 - 12:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

staring.net@gmail.com wrote:
i m giving them delay of 200 ms 

 

Noooooooooooo!!!!

 

Do not use "blind" delays: http://www.avrfreaks.net/comment/2139451#comment-2139451

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

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

Manish verma

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

See: http://www.avrfreaks.net/comment... and read through to the end of the thread.

 

See also: http://www.avrfreaks.net/comment... and read through to the end of the thread, where you will find links to some AT Command Libraries - including one specifically for the ESP8266

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

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

 

Manish verma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
while(received_data!="ok"

How is that going to work? C won't do a string compare for you - you need to do this using the likes of strcmp().

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

Kartman wrote:

while(received_data!="ok"

How is that going to work? C won't do a string compare for you - you need to do this using the likes of strcmp().

And besides:

staring.net@gmail.com wrote:

unsigned char receive_data; //variable to store received data

 

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 ...

 

 

Last Edited: Fri. Oct 27, 2017 - 08:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note also, for plain, readable text, you should use plain char:

 

In another thread, only the other day, clawson wrote:
There are three types of "char":  

  1. char
  2. unsigned char
  3. signed char  

 

The latter two are more usually referred to as uin8_t and int8_t.

 

  • If you are using the 1 byte storage to hold 0..255 then use uint8_t,
  • if you are using it for -128 .. +127 then use int8_t
  • if you are using it to hold characters like 'h','i' then use char. Don't use char otherwise.

 

See: http://www.avrfreaks.net/comment... also #14 in that thread

 

#ThreeTypesOfChar

 

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

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 

Manish verma

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

awneil wrote:
As is so often said here, you need to stop just flinging code into your editor and design your program.
Sage advice. I'd follow it if i were you. You need a clear plan of how the micro is going to interact with the peripheral. Specify the expected operation and then implement it in as modular a way as possible. Try to test the function of each module in isolation then when you put it all together you should have strong confidence that all the bits work and the only bit that remains to be debugged/developed is the "glue" that connects all the pieces (in fact Arudino programming is very like this!).

 

Just sitting in a C editor and adding lines that keep trying to "patch up this problem that I face right now" might work for something simple like flashing an LED when a button is pushed but you need a more methodical design approach for more complex projects. It would be an utter miracle if it all "just worked" at the initial attempt.

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

 

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 TeraTermhttps://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.

 

 

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

awneil wrote:
Use the debugger to confirm that you are correctly receiving the string

This, of course, requires that you do not disable the JTAG.

 

Disabling JTAG - certainly at this stage in the project - is (IMO) stupid: you are deliberately tying your hands behind your back when it comes to debugging your code!

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

awneil wrote:
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.
He has "switched" the threads (hijacked this one) yesterday.

Here is the other one:

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

 

Stefan Ernst

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

I did this because u were not there and I found this thread useful as well so I shared my problem here as well. Hope it's not against the rules. If it is then sorry... I'll make sure next time this Aint gonna happen....

Manish verma

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

staring.net@gmail.com wrote:
u were not there

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.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Fri. Oct 27, 2017 - 02:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sternst wrote:
He has "switched" the threads (hijacked this one) yesterday

Ah - thanks!

 

Strange I did use both the search here and a google with site:avrfreaks.net and I didn't see it on either.

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

staring.net@gmail.com wrote:
u were not there

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

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

staring.net@gmail.com wrote:
u were not there
You need to realize that the various posters on this website are volunteers and do have "real" lives apart from AVRFreaks. As Johan said, "plan for waiting for at least 24 hours before crying out for attention."

David (aka frog_jr)

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

Ok let me clear myself.

This time i'll try to be more clear.

1. 

awneil wrote:

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.

  

 

Here yes I did this,

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

 

2. 

awneil wrote:

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

 

  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.
  

 

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 

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

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.

JohanEkdahl wrote:

staring.net@gmail.com wrote:
u were not there

Your level of patience in that thread was ridiculous.

 

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.

 

 

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.

Manish verma

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

staring.net@gmail.com wrote:
sir John I was not losing my patience

Rubbish. You submitted one post at

Posted : Thu. Oct 26, 2017 - 12:44 PM

and then 12 minutes later your next post was

Posted : Thu. Oct 26, 2017 - 12:56 PM

 

Please reply...

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

can't expain more, Hope you understand.

Manish verma

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

staring.net@gmail.com wrote:
Esp Stops responding after receiving any delay

So, to be clear:

 

  1. You can manually send a sequence of command to the ESP from a terminal, and you 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?
     
  3. But when you connect your AVR with this code to the ESP, it "Stops responding" ?

 

 

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

 

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

 

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

 

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

 

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

 

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

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

 

  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 http://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


 

Manish verma

Last Edited: Fri. Oct 27, 2017 - 04:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

staring.net@gmail.com wrote:
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]
 

Your answer bears absolutely no relation to the question I asked!

 

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

 

 

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

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

Manish verma

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

Please show the commands that you send, and the responses you receive using the same format that I did in #63 - ie, each character sent and each character received in sequence.

 

You will need to use the Forum's Code editor - as for posting source code.

 

Hint: it's easier to type it in Notepad first, then paste it into the Forum's Code editor.

 

Also show the actual code that you are currently using - taking care that it is well-formatted before you post it.

Be sure to build & test the code before you copy & paste it into the forum.

 

Your build should be "clean" - ie, no errors and no warnings.

 

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

staring.net@gmail.com wrote:
Control characters like /r/n ?

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!

Last Edited: Fri. Oct 27, 2017 - 05:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry actually I am typing through mobile right now so got confused,yes it is \r\n..... it's really late here...mid night 23:00.
You can see my code at #67 I've used 8MHz external crystal,and configured fuse bits for that.
But I'll post my codes and response as per your requirement it'll need some time.

Manish verma

Last Edited: Fri. Oct 27, 2017 - 05:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

staring.net@gmail.com wrote:
Sorry actually I am typing through mobile right now so got confused, it's really late here...mid night 23:00.

So stop, then!!!

 

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

 

staring.net@gmail.com wrote:
code at #67

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.

 

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

staring.net@gmail.com wrote:
You can see my code at #67
An empty receive interrupt is quite harmful. No wonder nothing works as expected after the ESP has sent the first response.

Stefan Ernst

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

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.

Manish verma

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

staring.net@gmail.com wrote:
I will update here tomorrow early morning.

Again, it is important that you get good rest to be able to think clearly.

 

It is the weekend.

 

It can wait.

 

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

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!devil

 

Quebracho seems to be the hardest wood.

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

surprise blush  laugh

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

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.

Manish verma

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

staring.net@gmail.com wrote:
I don't understand how to read characters of usart receive and then use them accordingly.

Go on.

 

That is just basic UART usage - people have been doing this stuff since the first microcontrollers appeared.

 

Any book on embedded microcontrollers would cover this.

 

There must be plenty of tutorials on the interwebs ...

 

Have you checked-out the Tutorials section of this site?

 

EDIT

 

http://www.lmgtfy.com?q=AVR+UART+Tutorial

 

One of the first few hits is: http://www.avrfreaks.net/forum/tut-soft-using-usart-serial-communications

Last Edited: Mon. Oct 30, 2017 - 10:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.\

 

Manish verma

Last Edited: Mon. Oct 30, 2017 - 10:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Read #72 again.

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

I just want like this.

ATE1
OK    ---after receiving this ok go further else wait for ok

AT
OK     ---after receiving this ok go further else wait for ok

AT+CIPMUX=1
OK      ---after receiving this ok go further else wait for ok

AT+CWSAP="SSID","PASSWORD",3,4
OK       ---after receiving this ok go further else wait for ok

Just this.

Manish verma

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

So remember:

  • A UART (or USART) sends/receives just one character at a time.
  • The control characters matter.

 

 

So re-draw that sequence as I showed you in #63 - including the control characters.

 

You now appear to be running in Proteus - so you can step through your code, line-by-line, and examine your variables as you go.

 

Do that! and see that using the data from your sequence - drawn as in #63

 

 

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

staring.net@gmail.com wrote:

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

Don't you think it would make more sense to ensure that UDR is empty before you put something into it?

 

Please take care with your code layout - it's so much easier to read when nicely laid-out:

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

 

Note that using TAB characters is not reliable; therefore, do not use TAB characters - use only spaces.  This will ensure that your layout is preserved whatever it is viewed on.

 

Any decent code editor will have an option so that it will insert the appropriate number of spaces when you press the TAB button on your keyboard.

 

 

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

you only read the uart once -

 data=usart_rx();             //--- send the received data back

but yet you want to respond to multiple uart inputs. According to your code, once you hit 'k' it will send "AT" then drop into the while(1) loop and do nothing. You wrote the code and it does exactly what you asked it to do.

 

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

In #72, clawson wrote:

awneil wrote:

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

Sage advice. I'd follow it if i were you. You need a clear plan of how the micro is going to interact with the peripheral. Specify the expected operation and then implement it in as modular a way as possible. Try to test the function of each module in isolation then when you put it all together you should have strong confidence that all the bits work and the only bit that remains to be debugged/developed is the "glue" that connects all the pieces (in fact Arudino programming is very like this!).

 

Just sitting in a C editor and adding lines that keep trying to "patch up this problem that I face right now" might work for something simple like flashing an LED when a button is pushed but you need a more methodical design approach for more complex projects. It would be an utter miracle if it all "just worked" at the initial attempt.

In #69, I wrote:
eg, draw a flowchart 

Perhaps this will help: http://www.bbc.co.uk/schools/gcsebitesize/design/resistantmaterials/processystemsrev3.shtml

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

Kartman wrote:

you only read the uart once -

 data=usart_rx();             //--- send the received data back

Stepping in the simulator (or a debugger) would immediately have shown you that!

 

In fact, just stepping through the code manually with pencil & paper would have shown you that!

 

It should also have been obvious from a flowchart.

 

Note also that your comment here is a lie.

 

 

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

Manish verma

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

Go on -you could have rotated it.

 

A flowchart, as the linked site explained, is supposed to show a sequence of steps - so what is the top "send a command" box supposed to mean?

 

And, as the linked site mentioned, the different shaped boxes have specific meanings.

 

Note that the linked site is aimed at 16-year-old school children - this is not rocket science!

 

Now you need to break it down into handling character-by-character.

 

In particular, you need to think about how you will identify when a response is complete ...

 

Again, writing your sequence as shown in #63 will help.

 

EDIT

 

https://en.wikipedia.org/wiki/Flowchart

 

"Flowcharts" have been around since (at least) the 1920s - it's not like this is something new or obscure.

 

Any basic programming book should cover it - it's not related to any particular language.

 

Last Edited: Mon. Oct 30, 2017 - 12:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Manish verma

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

Again, note that the command terminator is just \r - not \r\n.

 

You have missed the terminator from AT+CPMUX

 

You still haven't shown the process detail of receiving & recognising the "OK" response - which is the part you are struggling with!!

 

In #107, you send ATE1. This will turn the echo on - is that what you really want? If it is, you will need to adjust your process accordingly

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

Manish verma

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

sorry - I can't read what it says in your first decision box

 

sad

 

EDIT

 

and the "If no / if yes" question in the 2nd decision box makes no sense.

 

A decision box should contain a question to which the answer is Yes or No (or equivalent) - and it has exit lines correspondingly labelled "Yes" and "No".

 

https://en.wikipedia.org/wiki/Flowchart#Common_symbols

 

 

Last Edited: Mon. Oct 30, 2017 - 01:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
I can't read what it says in your first decision box

If I zoom in, all I see is:

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

Sorry I was not aware of it...." Check response"
If yes then print ok ,if no then print error.

Manish verma

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

But that makes no sense in that position - does it?

 

At that point, you have not yet received anything - have you?

 

EDIT

 

and what about the echo?

Last Edited: Mon. Oct 30, 2017 - 05:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Awneil please help me out to make receive buffer,

All i want is to make a function which receives character by character like 'M','N','O','\r','\n'.

and they all stored in some array. like receive_data[],

And after that how can i compare that

receive_data=="MNO\r\n.

please help.

Manish verma

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

This is getting painful for all concerned.

Manish - you are pleading with us to spoon feed you, is this what you want? Or would you like to further your education? Currently you have access to the World's largest store of information ever known to man, and you're struggling with a problem that has been solved a zillion times and half them have published example code.

 

I'd guess collectively we've given you all the answers you need, but you have not taken the initiative to research and understand them. If you want to read a number of characters terminated by a line ending, the standard solution is scanf(). Google AVR stdio

For comparing strings, the function is strcmp(). You can Google these and find out way more than I can describe in the few minutes I'll allocate for you.

For general handling of AT commands for a gsm module - there's plenty of Arduino examples - note these are in C/C++. The main thing though is they show you the technique that can be used in a variety of computer languages.

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

Kartman sir i am not pleading with you to spoon feed me.

I was about to share my codes so you can help me over it,

I need help to improve them, Not to just give me the desired codes.

I really understand that i am wasting your time and feel sorry for that but i really want to further my education but not in wrong direction thats why i ask you every single doubt.Hope you understand.

And sorry if i irritated you any how.

Manish verma

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

staring.net@gmail.com wrote:
Kartman sir i am not pleading with you to spoon feed me.

I'm sorry, but yes - you are.

 

Just look at #116 for a prime example.

 

You're starting to get the idea of flowcharts - so why don't you carry on

 

Kartman is right - this is all basic stuff, which has been covered in countless books before the internet was even invented.

And now, with the internet, you have access to it all form the comfort of your desk at the touch of a button.

See http://www.avrfreaks.net/comment...

 

As already noted, there are hundreds of projects already published on line specifically using an AVR and an ESP - and there must be thousands that show generally how to have a microcontroller communicate with a device using AT Commands.

It is not new.

It is not rocket science.

 

Your problem is that you are trying to leap into stuff without having first laid the basic foundations of how to create a program.

 

You really need to go back to basics, start from scratch, and work through a good book or tutorial on programming.

 

Better still, join a class and/or get some personal tuition.

 

There's a booklist included here: http://blog.antronics.co.uk/2011...

 

EDIT

 

typo

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

Fundamental to any form of programming is the ability to analyze a problem, and break it down into the steps needed to complete the task.

 

The standard example when starting learning programming is to describe some "simple" everyday task; eg, boiling the kettle to make a cup of tea:

Flowchart - Boiling the kettle to make a cup of tea

 

EDIT

 

Think how filling a kettle with water is analogous to filling a  buffer with characters ...

 

 

 

Last Edited: Tue. Oct 31, 2017 - 09:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please have a look over here.

#include<avr/io.h>              
#include<avr/interrupt.h>
#include<string.h>
void usart_init();  
unsigned char usart_rx();
void usart_tx(unsigned char send_data);
void usart_tx_string(unsigned char send_string_tx[]);
unsigned char rx_usart[30];
unsigned char receive_data;
int main()
{ 
   unsigned char AT[]="AT\r\n";
   unsigned char CIPMUX[]="AT+CIPMUX\r\n";
   usart_init();
   sei();
   usart_tx_string(AT);
   usart_rx();
   while(receive_data!='\r')
   {
   usart_rx();
   usart_tx(receive_data);
   }
   usart_tx_string(CIPMUX);
   while(1)
   {
      
   }
}
void usart_init()
{
    UBRRL = 51;                       //--- 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(unsigned char send_data)
{
   UDR=send_data;
   while(!(UCSRA&(1<<UDRE))); 
}
void usart_tx_string(unsigned char send_string_tx[])
{
   unsigned char i=0;
   while(send_string_tx[i]!='\0')
   {
      usart_tx(send_string_tx[i]);
      i++;
   }
}
unsigned char usart_rx()
{ 
   while(!(UCSRA&(1<<RXC)));
       receive_data=UDR; 
      return receive_data;

please have a look on it, i just made a simple program in which AT prints, then waits for receving character '\r',

once it receive it , it shows next command.

Manish verma

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

You're not listening, are you?

 

How many times has it been said already: 

 

Do NOT just jump in and start throwing 'C' code into your editor !!

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

staring.net@gmail.com wrote:
please have a look on it

No.

 

Before asking others to "have a look on it", you test it.

 

For a simple piece of code like this, you can simply step through it on paper with a pencil.

 

Or step through it in a simulator or debugger - see #106.

 

This would immediately show you a couple of basic flaws.

 

And you still haven't paid attention to the correct command termination - have you?

 

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

I am listening, i was just completing my codes to show you.

Now i am reading what you ask me to until then give me some time because i takes some time.

Manish verma

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

staring.net@gmail.com wrote:
I am listening

No, you clearly are not.

 

i was just completing my codes

Which is what you have specifically been told not to do!!

 

How, then, can you say you are listening?!

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

But this is the code i learnt after reading what you ask me too so before going further i thought lets try it once.

Manish verma

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

Nobody asked you to write any code.

 

You haven't showed any design yet.

 

eg, a flowchart of how you intend to collect the incoming characters.

 

Bart Simpsons Chalkboard

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

awneil wrote:
Nobody asked you to write any code.

In fact, the suggestion was that you should set this whole project aside for a while to concentrate on getting your basic programming foundations laid.

 

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

ok Sorry !! first i make flow chart then i'll go further.

Manish verma

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

Another thing that has been repeatedly suggested to you - and you still haven't done - is to write out a detailed, character-by-character analysis of what gets sent between the AVR and the ESP.

 

I showed you an example in #63.

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

Noted.

Be back as soon as possible after completing what you said.

Thanks.

Manish verma

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

No need to rush.

 

Take your time.

 

Think carefully; review everything.

 

 

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

I think you missed your vocation, awneil. You would have made a fine programming instructor, maybe in a Jesuit programming school.

Quebracho seems to be the hardest wood.

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

^awneil

 

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

John_A_Brown wrote:
maybe in a Jesuit programming school
People often says "LOL" but don't really mean they laughed out loud. I just did. Priceless !!!

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

OK, for once it wasn't me that started OTing, so there! Still...

clawson wrote:
People often says "LOL" but don't really mean they laughed out loud. I just did. Priceless !!!

https://youtu.be/8h0LLD_N9ds?lis...

 

By all means, do watch the whole episode! It is one of the most hilarious episodes out there. I just had to locate it because of the "LOL" and watched it all again. I've been LOL'ing (actually) and tears have been flowing... Bill Bailey as a total wreck at 24:35 is priceless. And Mr Fry, who normally can keep a constant stone face when needed, just barely keeps from breaking at 25:55-16:05. And there's a lot more..

 

But don't cherry-pick - there's lots of "back references" so spend the half hour of bandwidth. Worth it. Unless you're easily offended by foul language and insinuations, in which case you should stay off completely..

 

The Brits sure are excellent at televised humor!

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Wed. Nov 1, 2017 - 03:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This video contains content from Fremantle International, who has blocked it in your country on copyright grounds.

sad

 

But it's an Epidsode of QI.

 

laugh

 

Bill Bailley also has a section on this in one of his own shows - I always think of "ROFLYSSST" = Rolling On the Floor Laughing Yet Somehow, Strangely, Still Typing ...

 

laugh

 

EDIT

 

https://www.youtube.com/watch?v=...

 

Thank you, Google!

 

Last Edited: Wed. Nov 1, 2017 - 04:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello friends i am back with good news finally i've acheived what i wanted.

Thanks to all and specially Awneil for all your support and intimidation.

so happy !!

 

My micro sending some data to esp and esp send that data to another esp using wifi and then another micro receives and work according to receive data.

Thanks a ton.

Love you Awneil as a BROTHER !! :)

I'll post my codes after commenting all strings so anyone can understand them easily.

Manish verma

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

"Thanks to all and specially Awneil for all your support and intimidation."

 

Brilliant!

 

"Love you Awneil as a BROTHER !! :)"

 

https://en.wikipedia.org/wiki/Je...

 

Joking aside, well done to "staring" for persevering, and to awneil for his intimidation patience.

Quebracho seems to be the hardest wood.

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

heartThanks. heheh

Manish verma