Connect ESP8266 to ATmega16 problems.

Go To Last Post
66 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.

Pages