Connect ESP8266 to ATmega16 problems.

Go To Last Post
90 posts / 0 new

Pages

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

You need to go back and re-read the comments made above.

 

The USART baud rate needs to have an error of less than 2%, or you can easily have serial communications problems, which include wrong data, or no data.

 

The App   AVRCalc by Jack Tidwell is an easy tool for checking Xtal frequencies, baud rates, and error rates (%).

The data sheets often have tables with this information as well.

 

115200 Baud with either an 8 or a 16 MHz Xtal gives a 7.8 % baud rate error.

That simply won't work.

 

An 11.0592 MHz Xtal gives a 0 % error for 115.2K Baud.

 

The PC to ESP connection works because both have an accurate baud rate.

 

The micro to ESP fails because the baud rate is not accurate with your 16 MHz Xtal.

 

Get out your soldering iron and change crystal on the board.

 

JC

 

Edit: Typo

 

 

Last Edited: Thu. Mar 14, 2019 - 10:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No I did not. I typed I switch to 16MHz extermal crystal but nothig changed.

 

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

Darien wrote:
I can't send char 'A' from ATmega16 by USART to USB-USART PL2303 module and view it on Termite terminal prog.

 

Have you changed the baud rate on that configuration to 9600, like Kartman suggested, to rule out the baud rate as the problem?

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

I switch to 16MHz external and set settings to 115.2K by set 2.1%.

But I alse set 

USART_Init(16);	

...with U2X=1 error is 2.1%

 

But I also set baud rate to 2400 on ATmega16 by 

USART_Init(832);	

and Termite -> with U2X=1 error is 0.0%

Transfer failed.

Last Edited: Thu. Mar 14, 2019 - 10:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess some problem in USART_Init func but I can't find any)

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

And you changed the denominator in speed calculation back to 16?  

 

I dont know how defines work but if you define something after you use it in a defined calculation does the calculation know what it is? 

 

I don't think I can help any more.  Best luck.

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

Finally)))Problem was not correct FUSE config on ATmega16. I set LOW Fuse Resister on 0xFF and Termite start to receive correct data) BUT I STRONGLY RECOMMENDED TO READ MANUAL TWICE BEFORE SET FUSES Not correct fuses set may cause microcontroller failed permanently.

I guess ATmega16 will work with 8MHz as well, I will tested it.

Last Edited: Thu. Mar 14, 2019 - 11:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tanks all for help. Some good ideas I will use like 'Circular Buffer ')

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

There's an Arduino Core for the mega16. This implements things like a circular buffer and a system tick which come as part of the Arduino infrastructure. There's plenty of Arduino/esp8266 examples, so this should smooth the path a little.

https://github.com/MCUdude/Might...

 

Last Edited: Fri. Mar 15, 2019 - 12:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
void EEPROM_Write(unsigned int uiAddress, unsigned char ucData) {
	while(EECR & (1<<EEWE)) { }
	EEAR = uiAddress;
	EEDR = ucData;
	
	EECR |= (1<<EEMWE);
	EECR |= (1<<EEWE);
}

If you are using avr-gcc why on earth are you doing this? It already comes with a whole suite of eeprom  access functions:

 

https://www.nongnu.org/avr-libc/...

 

You are just reinventing eeprom_write_byte() in the above. Also note that it's not a good idea to use eeprom_write_byte() (or your function) anyway. If you keep calling the function for the same location with the same data it will write it anyway. Each write eats away at the 100,000 cycle life of the eeprom location. Better is to use eeprom_update_byte() this does a (fast) read before write check and if the location already holds the value to be written it doesn't do it. This can save major amounts of EEPROM wear!

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

Yes, I know but this is for beter understanding how to work with EEPROM.

I also have some func to work with external EEPROM.

Currently I use EEPROM for the test only to view result data (without LCD).

I don't know how else view data if USART is not available.

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

Cliff, are the reads and writes for 16 bit words all little endian in the gcc functions?  Little endian seems so wrong.  The bits are out of order.

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

MarkThomas wrote:

Cliff, are the reads and writes for 16 bit words all little endian in the gcc functions?  Little endian seems so wrong.  The bits are out of order.

typical code here..
.
http://svn.savannah.gnu.org/viewvc/avr-libc/trunk/avr-libc/libc/misc/eewr_word.S?revision=1979&view=markup

This requires some knowledge of the avr-gcc ABI but basically the first parm (addr) will be in R25:R24 the the second parm (16 bit value to write) will be in R23:R22. The first call will write R22 (low byte) then second writes R23 (high) but what I don't see is the EEAR increment but the must be implied by the write_r18 routine. The whole of avr-gcc does things little endian. I doubt the EEPROM routines would be any different.
.
Hope you are having a good day by the way ;-)

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

I will have to be careful where I have written ints big endian using the code examples in the data sheet for reading and writing to EEPROM when I switch over to the gcc functions.  The update function is nice, even though my use of EEPROM will probably take 10,000 years to get to 100,000 writes.

 

clawson wrote:
Hope you are having a good day by the way ;-)

 

Thanks for that.  Doing much better.  Hope your day is one of the better ones too.

 

mark

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

Actually, more like 500 years to get to 100,000 writes with what I am currently doing.  I hope to not live that long.

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

I'm a little late to the party, so my apologies if the following has been answered already:

 

Is the OP absolutely sure they are running the AVR off of a 16MHz EXTERNAL crystal?  Were the fuses set for a High Frequency crystal/full swing crystal?

 

The best you can get on a 16MHz crystal with X2 programmed is 57600.  Anything higher is out of spec.  As already mentioned you can go with a baud friendly crystal, or tailor your application to what reliable speeds can be achieved. 

 

Before moving forward, create a very simple application that echos back to your terminal program what the AVR receives from your terminal program.  Once you have that running then you can add the SP module.

 

Jim

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I'm allready create simple prog for testing only. On  terminal I read info transfered from ATmega16. But there is some problems with transfer info from terminal prog to Atmega16. (Between ESP8266 module and terminal no problems to transfering on 115.2K baud rate). So what cristal value I should use to get 115.2K baud rate between Atmega16 and terminal prog??

Last Edited: Mon. Apr 1, 2019 - 02:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any "magic crystal" (ie multiple of 300Hz)

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

Darien wrote:
So what cristal value I should use to get 115.2K baud rate between Atmega16 and terminal prog??

 

Teh Datasheet provides plenty of information on this.  The one I use is 11.052Mhz, as it gives 0% error.

 

Darien wrote:
But there is some problems with transfer info from terminal prog to Atmega16.

That can be your crystal frequency, or your code, or both.

 

Have you programmed the fuses in the AVR for an external crystal?  I am thinking yes, but I have nothing to confirm this.

 

I am not at my PC today with time to write code, but I would suggest you write a simple loopback program that does the following(based on a 16MHz crystal)

 


USART RX ISR
{
    uint8_t data;  //local variable
    data = UDR0;  //get teh data from UDR0
    UDR0 = data;  //send the received data back to the terminal
}

void main(void)
{
    //init the usart
    Configure the USART for 8-N-1
    Set Baud to 57600 - you will need the x2 enabled for this
    Enable the RX interrupt
    Enable the RX and TX

    sei();

    while(1)
    {
        //hang out here and do nothing until data comes in
    }
}

57600 is the fastest the USART can go within error specs for a 16MHz crystal.  If everything is in order, anything you type on the terminal should be echoed back to it.

 

 

JIm

 

EDIT:

Heres the config:

void main(void)
{
    // USART initialization
// Communication Parameters: 8 Data, 1 Stop, No Parity
// USART Receiver: On
// USART Transmitter: On
// USART Mode: Asynchronous
// USART Baud Rate: 57600 (Double Speed Mode)
UCSRA=(0<<RXC) | (0<<TXC) | (0<<UDRE) | (0<<FE) | (0<<DOR) | (0<<UPE) | (1<<U2X) | (0<<MPCM);
UCSRB=(1<<RXCIE) | (0<<TXCIE) | (0<<UDRIE) | (1<<RXEN) | (1<<TXEN) | (0<<UCSZ2) | (0<<RXB8) | (0<<TXB8);
UCSRC=(1<<URSEL) | (0<<UMSEL) | (0<<UPM1) | (0<<UPM0) | (0<<USBS) | (1<<UCSZ1) | (1<<UCSZ0) | (0<<UCPOL);
UBRRH=0x00;
UBRRL=0x22;

sei();

   while(1)
   {
       //do nothing and wait
   }
}

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Mon. Apr 1, 2019 - 02:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I set LOW fuses as 0xFF.

Last Edited: Mon. Apr 1, 2019 - 02:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Darien wrote:

I set LOW fuses as 0xFF.

 

Yup, thats the proper setting for external crystal.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I also don't understand why ISR(USART_RXC_vect) is run when I send from ATmega16 to Terminal data. FUSES can be issue to it?

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

Darien wrote:

I also don't understand why ISR(USART_RXC_vect) is run when I send from ATmega16 to Terminal data. FUSES can be issue to it?

 

Fuses have nothing to do with it.  And how do you know that the Interrupt fired when you send data?  The TX and RX pins are separate entities.  Unless your terminal program is sending data at the same time they do not interact with one another.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
ISR(USART_RXC_vect) {
    LED_PORT |= (1<<LED_PIN0);  
}
ISR(USART_TXC_vect) {
    LED_PORT |= (1<<LED_PIN1);
}

int main(void) {

    USART_Init(51);
   
    
    PORTA = 0x00;
    DDRA = 0xFF;
    
    sei();        
    while (1) {
        LED_PORT &= ~(1<<LED_PIN0);
        LED_PORT &= ~(1<<LED_PIN1);
        LED_PORT &= ~(1<<LED_PIN2);
        LED_PORT &= ~(1<<LED_PIN3);
        LED_PORT &= ~(1<<LED_PIN4);
        LED_PORT &= ~(1<<LED_PIN5);
        LED_PORT &= ~(1<<LED_PIN6);
        LED_PORT &= ~(1<<LED_PIN7);
    }

}

I light LED in USART_TXC_vect and USART_RXC_vect. When I send from ATmega16 LED0 in ON (LED_PIN0).

Last Edited: Mon. Apr 1, 2019 - 04:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Darien wrote:

  USART_Init(51);

What crystal is this number for?

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

jgmdesign wrote:

Darien wrote:

  USART_Init(51);

What crystal is this number for?

 

JIm

16MHz -> 38.4K baud rate (I set lover speed)  UBRR(dec)=51U2Xn = 1

Last Edited: Mon. Apr 1, 2019 - 04:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Darien wrote:
When I send from ATmega16 LED0 in ON (LED_PIN0).
As written - because you are repeatedly setting all bis of LED_PORT back to 0 in the while(1) then even if RXC fires it should only be momentary but will then be turned off almost immediately anyway. However this is what the mega16 datasheet says about the RXC interrupt flag:

 

So your code needs to be:

ISR(USART_RXC_vect) {
    uint8_t dummy;
    LED_PORT |= (1<<LED_PIN0);  
    dummy = UDR;
}

so the read of UDR clears the RXC flag. Otherwise as soon as one interrupt condition occurs it will never clear and the ISR() will simply run over and over again.

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

clawson wrote:

Darien wrote:
When I send from ATmega16 LED0 in ON (LED_PIN0).
As written - because you are repeatedly setting all bis of LED_PORT back to 0 in the while(1) then even if RXC fires it should only be momentary but will then be turned off almost immediately anyway. However this is what the mega16 datasheet says about the RXC interrupt flag:

 

So your code needs to be:

ISR(USART_RXC_vect) {
    uint8_t dummy;
    LED_PORT |= (1<<LED_PIN0);  
    dummy = UDR;
}

so the read of UDR clears the RXC flag. Otherwise as soon as one interrupt condition occurs it will never clear and the ISR() will simply run over and over again.

I miss that in datasheet. I try...it won't help. LED fires up and then momentary turned off...but it is enough time to see blink. I assume ISR(USART_RXC_vect) run when I receive data not send. So when I send data LED_PIN1 must be ON not LED_PIN0.

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

Darien,

Try this:

/*
 * Mega16 USART.c
 *
 * Created: 4/1/2019 12:18:14 PM
 * Author : jgmDESIGNS
 */ 

#define F_CPU 16000000ul
#include <avr/io.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include <string.h>
#include <avr/pgmspace.h>
#include <avr/eeprom.h>


ISR (USART_RXC_vect )
{
	uint8_t data;
	data = UDR;
	UDR = data;
}

void avr_init(void)
{
	// USART0 initialization
	// Communication Parameters: 8 Data, 1 Stop, No Parity
	// USART0 Receiver: On
	// USART0 Transmitter: On
	// USART0 Mode: Asynchronous
	// USART0 Baud Rate: 57600 (Double Speed Mode)
	UCSRA=(0<<RXC) | (0<<TXC) | (0<<UDRE) | (0<<FE) | (0<<DOR) | (0<<PE) | (1<<U2X) | (0<<MPCM);
	UCSRB=(1<<RXCIE) | (0<<TXCIE) | (0<<UDRIE) | (1<<RXEN) | (1<<TXEN) | (0<<UCSZ2) | (0<<RXB8) | (0<<TXB8);
	UCSRC=(1<<URSEL) | (0<<UMSEL) | (0<<UPM1) | (0<<UPM0) | (0<<USBS) | (1<<UCSZ1) | (1<<UCSZ0) | (0<<UCPOL);
	UBRRL=0x22;
}

int main(void)
{
	
	avr_init();
	
	sei();
		
	
    /* Replace with your application code */
    while (1) 
    {
		//just hang out here.  THe interrupt does the work
		
    }
}

Use a 16MHz crystal.  Baud rate is set for 57600.  In your terminal whatever you type will be echoed back.

 

Forget about your LED's etc as we have no idea how your custom board works.  Get the AVR to talk to your terminal program.  THEN we can move on.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

post a link to the USB/RS232 adapter you are using and a schematic of how you are connecting all of this up too.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

jgmdesign wrote:

Darien,

Try this:

/*
 * Mega16 USART.c
 *
 * Created: 4/1/2019 12:18:14 PM
 * Author : jgmDESIGNS
 */ 

#define F_CPU 16000000ul
#include <avr/io.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include <string.h>
#include <avr/pgmspace.h>
#include <avr/eeprom.h>

ISR (USART_RXC_vect )
{
	uint8_t data;
	data = UDR;
	UDR = data;
}

void avr_init(void)
{
	// USART0 initialization
	// Communication Parameters: 8 Data, 1 Stop, No Parity
	// USART0 Receiver: On
	// USART0 Transmitter: On
	// USART0 Mode: Asynchronous
	// USART0 Baud Rate: 57600 (Double Speed Mode)
	UCSRA=(0<<RXC) | (0<<TXC) | (0<<UDRE) | (0<<FE) | (0<<DOR) | (0<<PE) | (1<<U2X) | (0<<MPCM);
	UCSRB=(1<<RXCIE) | (0<<TXCIE) | (0<<UDRIE) | (1<<RXEN) | (1<<TXEN) | (0<<UCSZ2) | (0<<RXB8) | (0<<TXB8);
	UCSRC=(1<<URSEL) | (0<<UMSEL) | (0<<UPM1) | (0<<UPM0) | (0<<USBS) | (1<<UCSZ1) | (1<<UCSZ0) | (0<<UCPOL);
	UBRRL=0x22;
}

int main(void)
{

	avr_init();

	sei();

    /* Replace with your application code */
    while (1)
    {
		//just hang out here.  THe interrupt does the work

    }
}

Use a 16MHz crystal.  Baud rate is set for 57600.  In your terminal whatever you type will be echoed back.

 

Forget about your LED's etc as we have no idea how your custom board works.  Get the AVR to talk to your terminal program.  THEN we can move on.

 

JIm

Terminal is out off memory. To meny data to recieve and Terminal shuts down. LED_PIN0 in permanently ON.

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

Darien wrote:
Terminal is out off memory. To meny data to recieve and Terminal shuts down.

 

You have bigger problems then, and they have nothing to do with the AVR.  I ran that code and it works on RealTerm, and Termite3.4.

 

At this point the world is spinning its wheels.  Please try and make up a very basic connection from your PC to your AVR.  Make sure all VCC/AVcc pins are connected together and all GND pins are connected together.  Bypass caps on all power pins and a .1uf cap on Vref.

 

Run the AVR at 5v

 

Connect nothing else to the AVR other than your USB/USART adapter.

 

I would like to see a link to the USB/USART adapter you are using.  I hope you are not connecting RS232 levels to your AVR as that will certainly damage it.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

jgmdesign wrote:
Terminal is out off memory. To meny data to recieve and Terminal shuts down. LED_PIN0 in permanently ON.

 

When I try to send data from Atmega16 to Terminal (by func) ->  Terminal is out off memory. To meny data to recieve and Terminal shuts down. LED_PIN0 in permanently ON.

When I try to send data from Terminal to Atmega16 -> nothing happens.

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

Did you set the AVR up like I described in #83?  Can you post a link to the USART/USB adapter you are using?

 

Remember I tried the code I posted with the same terminal program you are using and had no issues, so you may have a problem with your software.

 

Did you create a new, fresh project with the application I posted above?  If yes, can you ZIP it up and attach it here so we can see if there is something wrong?

 

The fact that your Terminal program is shutting down is a red flag that you have something wrong with your PC software.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I am using PL2303

I create new exetutable C project. My ATmega16 powered by 5V external power supply (not battery). To my AVR connected Atmel-ICE promater (SPI).

Attachment(s): 

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

Ok, that USB adapter is a USB to TTL USART device so no issues there.

 

Did you connect the AVR the way I explained in #85, and if you did, does the code work properly?

 

I looked at your ZIP and removed all of your other code, and the project builds.  Load this into the AVR and test.  Report back what your results are.

 

JIm

Attachment(s): 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

All check... exept:  .1uf cap on Vref.

But code still not working as expected.

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

Darien wrote:
But code still not working as expected.

 

That tells us NOTHING!  WHat are you getting?  What are you expecting?  As I said, the code was tested on real hardware.  Including the same terminal program you are using.

 

JIm

 

EDIT:

Use a 16MHz crystal.  Baud rate is set for 57600.  In your terminal whatever you type will be echoed back.

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Last Edited: Tue. Apr 2, 2019 - 01:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I find out that when I try to get an echoe Terminal shust down -> permanenly get data:

ISR (USART_RXC_vect )
{
	uint8_t data;
	data = UDR;
	// UDR = data; - becouse of this code line. It starts infinite loop for data transfering..I don't know how.
}

And more friendlly to USART use this:

char str[60] = {0};
sprintf(str, "TEST\r\n");
USART_SendString((uint8_t*)str);

instead of this:

USART_SendString("TEST");

Bot I still don't know why my LED_PIN0 is blinking when I send data from ATmega16 to Terminal. 

I tested all code on real hardwere: different testing boards + different ATmega16 chips.

Last Edited: Tue. Apr 2, 2019 - 04:19 PM

Pages