C code for interfacing ESP8266 with AVR mcu

Go To Last Post
140 posts / 0 new

Pages

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

 

 

 

Pages