I have WiFi ESP8266 module:
I connect VCC to 3.3V, CH_EN to 3.3V, GND, Rx (module 7 pin) to ATmega16 TxD PD1, Tx (module 2 pin) to ATmega16 RxD PD0.
After I send by USART "AT" command I expect end up in ISR (USART_RXC_vect)... but nothing happend.
Did I make correct module connection?
There’s a number of things that might not be right. You need to work logically through the problem to solve it. This requires that you perform tests to prove/disprove things.
1. How do you know your esp8266 works?
2 how do you know your mega16 works?
I can tell you from experience that the esp8266 is very sensitive about its power supply. You need to ensure you have a good regulated 3.3V supply at around 500mA and very short wiring to the regulator.
I have USB-USART module based on PL2303 chip, so one WiFi ESP8266 I connected directly to it -> Try to send "AT" command -> I get responce from module - (41 F5) hex meggase.
Another WiFi ESP8266 I connect to ATmega16 -> Rx (module 7 pin) to ATmega16 TxD PD1, Tx (module 2 pin) to ATmega16 RxD PD0.
As power supply I use board (my own design) connected to 12V and lower down to 5V and 3.3V. I tested voltage from it to WiFi ESP8266 -> 3.2V
I connected USB-USART PL2303 module to my ATmega16 -> Try to send some symbols -> ISR (USART_RXC_vect) working.
Inside ISR (USART_RXC_vect) I make LED blink -> it does. And display symbols send on LED display -> it working. (some issue with ASCII code but it manageable).
I can't get any responce from module after I send from ATmega16 simmple "AT" command.
(some issue with ASCII code but it manageable).
Please explain that more.
What are you using for the clock source for the micro?
An external crystal, or the internal RC Oscillator?
If you flash an LED at 1 Hz, does it actually flash at 1 Hz?
What is the clock frequency and the baud rate you are using for your communications?
JC
My board:
ATmega16 with external crystal 8MHz.
I blink with LED by code:
#define LED_PORT PORTB
#define LED_DIR DDRB
#define LED_PIN 0
ISR (USART_RXC_vect) {
usartRxBuf = UDR;
LED_PORT |= (1<<LED_PIN);
_delay_ms(500);
LED_PORT &= ~(1<<LED_PIN);
_delay_ms(500);
LCD_SetCursor(3, 0); LCD_DisplaySymbol(usartRxBuf);
FlushBuf();
}
With USB-USART module based on PL2303 chip I use Terminal v1.9b -> not all ASCII display correct, for example RU simbols.
and the baud rate you are using for your communications?
JC
void USART_Init(unsigned int speed) {
UBRRH = (unsigned char)(speed>>8);
UBRRL = (unsigned char)speed;
UCSRB |= (1<<RXEN)|(1<<TXEN); // Enable USART
UCSRB |= (1<<RXCIE); // Enable ISR (USART_RXC_vect)
UCSRA |= (1<<U2X);// Double clock rate
UCSRC |= (1<<URSEL)|(1<<USBS)|(1<<UCSZ1)|(1<<UCSZ0); // Asinc (URSEL = 0), turn off parity (UPM1 = 0, UOM0 = 0), 2 stop bits (USBS = 1), package 8 bits (UCSZ1 = 1, UCSZ0 = 1)
}I use USART 115.2K speed:
int main(void) {
USART_Init(8);To hight speed for WiFi ESP8266? Should speed be lower or hight????
At 9600 baud each character takes around 1ms to send. Your code has a 500ms delay in it. That means you’ll ignore 500 characters. Even without that delay, the lcd functions are slow. How to solve? Look at how the Arduino core code manages the buffering of the serial data using a construct called a ‘circular buffer’.
I try to use Termite 3.4 (by CompuPhase).
I get module version:
AT version:1.1.0.0(May 11 2016 18:09:56) SDK version:1.5.4(baaeaebb) Ai-Thinker Technology Co. Ltd. Jun 13 2016 11:29:20
I don't know...need to upgrade to upper version???
Some of commands returns with ERROR message (AT+CWLAP for example).
Your baud rate is on the edge of working. Couple that with the baud rate error of the ESP8266, then there's a fair chance you'll have errors. Choose a lower baud rate - like 9600.
I calculated your baud rate is 111111 baud vs 115200. That's around 3.6% error. Why 2 stop bits? The usual is 1. That could be your problem right there.
I find issue -> I re-write USART send functions:
void USART_SendString(char * s) {
while(*(s)!='\0') {
USART_SendChar(*(s++));
}
}
void USART_SendChar(unsigned char symbol) {
while(!(UCSRA & (1<<UDRE)));
UDR = symbol;
}Use it like this:
void USART_Init(unsigned int speed) {
UBRRH = (unsigned char)(speed>>8);
UBRRL = (unsigned char)speed;
UCSRB |= (1<<RXEN)|(1<<TXEN);
UCSRB |= (1<<RXCIE);
UCSRA |= (1<<U2X);
UCSRC |= (1<<URSEL)|(1<<USBS)|(1<<UCSZ1)|(1<<UCSZ0);
}
void USART_SendString(char * s) {
while(*(s)!='\0') {
USART_SendChar(*(s++));
}
}
void USART_SendChar(unsigned char symbol) {
while(!(UCSRA & (1<<UDRE)));
UDR = symbol;
}
#define LED_PORT PORTB
#define LED_DIR DDRB
#define LED_PIN 0
#define SIZE_BUF 48
volatile unsigned char cycleBuf[SIZE_BUF];
volatile unsigned char tail = 0;
void FlushBuf(void) {
tail = 0;
cycleBuf[0] = 0;
}
ISR (USART_RXC_vect) {
usartRxBuf = UDR;
cycleBuf[tail] = usartRxBuf;
tail++;
LED_PORT |= (1<<LED_PIN);
_delay_ms(1000);
LED_PORT &= ~(1<<LED_PIN);
_delay_ms(1000);
LCD_SetCursor(3, 0);
LCD_DisplaySymbol(usartRxBuf);
}
int main(void) {
USART_Init(8);
...
USART_SendString("AT");
USART_SendChar(13);
_delay_ms(5000);
...
sei();
while(1) {
...
}
}I write code as simple as I can. Now I manage to blink LED inside ISR (USART_RXC_vect) -> signal of receiving data by USART.
But I don't understant format of data recieved from ESP8266 inside ISR (USART_RXC_vect).
It is not ASCII as I guess. So how I should properly transform data received from ESP8266???? to display on LCD or else were??? data format hex, dec or string from ESP8266???
void USART_Init(unsigned int speed) {
UBRRH = (unsigned char)(speed>>8);
UBRRL = (unsigned char)speed;
UCSRB |= (1<<RXEN)|(1<<TXEN);
UCSRB |= (1<<RXCIE);
UCSRA |= (1<<U2X);
UCSRC |= (1<<URSEL)|(1<<USBS)|(1<<UCSZ1)|(1<<UCSZ0);
}
void USART_SendString(char * s) {
while(*(s)!='\0') {
USART_SendChar(*(s++));
}
}
void USART_SendChar(unsigned char symbol) {
while(!(UCSRA & (1<<UDRE)));
UDR = symbol;
}
#define LED_PORT PORTB
#define LED_DIR DDRB
#define LED_PIN 0
#define SIZE_BUF 48
volatile unsigned char cycleBuf[SIZE_BUF];
volatile unsigned char tail = 0, head = 0;
void FlushBuf(void) {
tail = 0;
cycleBuf[0] = 0;
}
ISR (USART_RXC_vect) {
usartRxBuf = UDR;
cycleBuf[head] = usartRxBuf;
head++;
//what happens when you get more characters than SIZE_BUF?
if (head >= SIZE_BUF)
{
head = 0; //circular buffer - wrap around
}
// you can't have delays like this in your isr !
// at 115200 baud, each character takes 87us to send.
// here, you will simply miss characters
LED_PORT |= (1<<LED_PIN);
_delay_ms(1000);
LED_PORT &= ~(1<<LED_PIN);
_delay_ms(1000);
// again, you can't do this here - your lcd functions will most likely take
// more than 87us. You will miss characters
LCD_SetCursor(3, 0);
LCD_DisplaySymbol(usartRxBuf);
}
int main(void) {
USART_Init(8);
...
USART_SendString("AT");
USART_SendChar(13);
_delay_ms(5000);
...
sei();//you send the AT request, then wait 5 seconds then turn on the interrupts. What happens if the ESP8266 replies in less than 5 seconds?
while(1) {
...
}
}Why did you only half do the circular buffer?
You need to write a function to see if there is anything in the buffer and another to read the characters out.
You don't need to 'transform' the receive data. The ESP8266 sends ascii and you receive ascii. To form a string, you assemble characters until you find a value of 13 (EOL). You then have your string.
// you can't have delays like this in your isr ! // at 115200 baud, each character takes 87us to send. // here, you will simply miss characters LED_PORT |= (1<<LED_PIN); _delay_ms(1000); LED_PORT &= ~(1<<LED_PIN); _delay_ms(1000); // again, you can't do this here - your lcd functions will most likely take // more than 87us. You will miss characters LCD_SetCursor(3, 0); LCD_DisplaySymbol(usartRxBuf);
I will remove LCD display info and LED blink from ISR func -> it is for test only.
USART_SendString("AT");
USART_SendChar(13);
_delay_ms(5000);5 sec I remove also -> my issue, I miss that.
So I should form data from inside:
ISR (USART_RXC_vect)
...but use data from ESP8266 in some other point:
ISR(TIMER0_COMP_vect) or ISR(TIMER0_OVF_vect)
I will think this later.
void USART_SendString(char * s) {
while(*(s)!='\0') {
USART_SendChar(*(s++));
}
}could simply be:
void USART_SendString(char * s) {
while(*s) {
USART_SendChar(*s++);
}
}No point in over-complicating things!
Did you change the denominator in the UBRR calculation from 16 to 8 when you set
UCSRA |= (1<<U2X);
I just went through this at 115.2kBaud,
I continue trying to get proper respomce from WiFi module nd store it to EEPROM:
ISR (USART_RXC_vect) {
usartRxBuf = UDR;
cycleBuf[tail] = usartRxBuf;
EEPROM_WriteWord(tail, usartRxBuf);
tail++;
}
void EEPROM_WriteWord(unsigned int uiAddress, uint16_t ucData) {
EEPROM_Write(uiAddress, (unsigned char)ucData);
unsigned char dt = ucData>>8;
EEPROM_Write(uiAddress + 1, dt);
}
void EEPROM_WriteDWord(unsigned int uiAddress, uint32_t ucData) {
EEPROM_WriteWord(uiAddress, (uint16_t)ucData);
uint16_t dt = ucData>>16;
EEPROM_WriteWord(uiAddress + 2, dt);
}
void EEPROM_WriteString(unsigned int uiAddress, char str[]) {
wchar_t n;
for(n=0; str[n]!='\0'; n++) {
EEPROM_Write(uiAddress + n, str[n]);
}
}
void EEPROM_Write(unsigned int uiAddress, unsigned char ucData) {
while(EECR & (1<<EEWE)) { }
EEAR = uiAddress;
EEDR = ucData;
EECR |= (1<<EEMWE);
EECR |= (1<<EEWE);
}But I get not expected results by sending simple "AT" command:
:100000008CFF00FFFFFFFFFFFFFFFFFFFFFFFFFF72 :10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0 :10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
As I understand, I should get:
4f 4b 0d 0a
You didn't answer my question. Did you change the denominator from 16 to 8 in your calculation of "speed"? It should look like:
#define speed F_CPU/8/BAUD1-1
I played with that device and what worked was 8 data bits, 1 stop bit, 0 parity bits.
If you sent "AT" do you get an "OK" back?
Yes I did in main.h file:
#ifndef MAIN1_H_ #define MAIN1_H_ //#define F_CPU 8000000UL #define speed F_CPU/8/BAUD1-1 #include <avr/io.h> #include <avr/delay.h> #include <avr/interrupt.h> #include <stdio.h> #include <stdlib.h> #include <string.h>
Still not working.
I also set USART settings as 8 data bits, 1 stop bit, 0 parity bits. :
void USART_Init(unsigned int speed) {
UBRRH = (unsigned char)(speed>>8);
UBRRL = (unsigned char)speed;
UCSRB |= (1<<RXEN)|(1<<TXEN);
UCSRB |= (1<<RXCIE);
UCSRA |= (1<<U2X);
UCSRC |= (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);
}
What is your F_CPU?
External 8MHr. Already check from "Examples of UBRR Settings for Commonly Used Oscillator Frequencies" from ATmega16 Datasheet.
Fosc = 8.0000MHz, U2X = 1 => UBRR = 8, Error 3.5%, 115.2K Baud Rate (bps)
I think you might have real problems getting 115.2kBaud with 8MHz. I barely got it with a 16 MHz crystal and 2x. I couldn't get it without the 2x, which gives the same error rate as 8MHz with 2x. You might have to put in one of those weird crystal frequencies that give 0% error at all baud rates. Other people here know better than me, but I suspect that is your problem.
Edit: Or put in a 16 MHz crystal with 2x
Yes, you probably right. I connect ATmega16 to USB-USART PL2303 chip module and try to send/recieve data with Termite 3.4 (on Termite settings 115200 pbs, 8N1, no handshake) and transfer failed.
Will the ATmega16 go to 16 MHz?
Edit: I looked at Digi-Key and some go to 16, some go to 20. You could get a 14.7456MHz chip and be good to 230.4 kBaud
Edit again: I looked further and some only go to 8MHz. You could overclock it to 11.0592MHz and be good to 230.4 kBaud.
But datasheet stand for 115.2K with 8MHz external CPU. I do not understand problem?? why micro can't get 115.2K???
I explained in #10 why.
As well, writing to eeprom is slow, so doing this in your isr wont work.
For 8Mhz with 2x the error rate is -3.5%. For 16MHz no 2x, the error rate is -3.5% and it didn't work, but when I turned on 2x at 16 MHz the error rate drops to 2.1% from that table, and that improvement was enough to make it work. That was my experience.
I think it is kinda hard to change the baud rate if you cant talk to it.
Edit: I guess you could use a laptop and an FTDI USB-UART chip to talk to it and change the baud rate in PuTTY, or something like that.
OK, now I switch to external 16MHz.
settings USART:
void USART_Init(unsigned int speed) {
UBRRH = (unsigned char)(speed>>8);
UBRRL = (unsigned char)speed;
UCSRB |= (1<<RXEN)|(1<<TXEN);
UCSRB |= (1<<RXCIE);
UCSRA |= (1<<U2X);
UCSRC |= (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);
}
int main(void) {
USART_Init(16);And still not good results. I get incorrect data on Termite from Micro and from Termite on Micro I get incorrect data.
did you change F_CPU everywhere?
Yes, on top of main.c:
#define speed F_CPU/16/BAUD1-1 #define F_CPU 16000000UL
do you have to define F_CPU before speed?
OH, you are using 2x so denominator should be 8
I tested it. not working.
does sending "AT" return an "OK" ?
I have:
int main(void) {
PORTD = 0x00;
DDRD = 0xFF;without it no data transfer at all. Configure portD for output. Could it be issue???
Now I connect to Atmega16 my USB-USART PL2303 module -> and view results of transfer data in Termite terminal prog.
dont you want to send and receive with UART Rx and Tx? I dont know what pins they are. Are you redefining them by setting PORTD that way after init_UART?
OK, so it sounds like 115.2kBaud is working. Right? Kartman's comment about writing to EEPROM being slow means you have to deal with that timing issue. Someone suggested a circular buffer.
Yes, ATmega16 -> TxD PD1, RxD PD0.
So you dont want to redefine PORTD as output after init_UART.
EEPROM for view results of transfer only..allredy remove it from code.
int main(void) {
PORTD = 0x00;
DDRD = 0xFF;
USART_Init(16);
sei();
USART_SendChar(65);
USART_SendChar(84);
while(1) { And on Termite terminal prog I get incorect results of transfering data. So I guess USART not working or settings not good.
What are ASCII 65 and 84?
Why not send:
USART_SendChar('X');
USART_SendChar('Y');and see what you get.
65 decimal for 'A'
85 decimal for 'T'
...same as:
USART_SendChar('A');
USART_SendChar('T');I tested all variables. Nothing work.
you need to send a \r too at the end.
Edit: \r at the end
Wait, with that ESP8266 you need a \r\n at the end, I seem to remember.
I can't get a single char to transfer from Micro ATmega16 to Termite correct. Why I need to send \t after any char for proper transfering????
main.c:
#include "main.h"
ISR (USART_RXC_vect) {
}
int main(void) {
PORTD = 0x00;
DDRD = 0xFF;
USART_Init(16);
sei();
USART_SendChar('A');
USART_Transmit('B');
USART_SendChar('\t');
while (1) {
}
}main.h:
#ifndef MAIN1_H_ #define MAIN1_H_ #include <avr/io.h> #include <avr/delay.h> #include <avr/interrupt.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include "USART.h" #endif /* MAIN1_H_ */AIN_H_ */
USART.c:
#include "USART.h"
void USART_Init(unsigned int speed) {
UBRRH = (unsigned char)(speed>>8);
UBRRL = (unsigned char)speed;
UCSRB |= (1<<RXEN)|(1<<TXEN);
UCSRB |= (1<<RXCIE);
UCSRA |= (1<<U2X);
UCSRC |= (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);
}
void USART_Transmit(unsigned char data) {
while((UCSRA & (1<<UDRE))==1) {
UDR = data;
}
}
void USART_SendString(char * s) {
while(*(s)!='\0') {
USART_SendChar(*(s++));
}
}
void USART_SendChar(unsigned char symbol) {
while(!(UCSRA & (1<<UDRE)));
UDR = symbol;
}USART.h:
#ifndef USART_H_ #define USART_H_ #include "main.h" void USART_Init(unsigned int speed); void USART_Transmit(unsigned char data); void USART_SendString(char * s); void USART_SendChar(unsigned char symbol); #endif /* USART_H_ */
RxD USB-USART PL2303 module connected to TxD Atmega16 PD1
TxD USB-USART PL2303 module connected to RxD Atmega16 PD0
+ GND between USB-USART PL2303 module and Atmega16
I have no guess why can't sent one char 'A' from Atmega16 to USB-USART PL2303 module and view it on Termite terminal prog.
When I connect ESP8266 to USB-USART PL2303 module and send from Termite 'AT' command I get responce 'OK'. PROBLES is USART on ATmega16.
When I talked to it with an FDTI USB-UART and PuTTY i had to send "AT", then hit enter, and then do a cntl-j for new line and I would get an OK back. My PuTTY the implicit LF in every CR didn't seem to work. so it wants a \r\n to complete the command.
Sorry about the \t. a mistype.
Do you have Rx on the mega connected to Tx on the ESP?
Edit: I missed your post that you did.
Termite in settings 'Transmitted text' set 'Appent CR-LF' checkbox. Set it and all string in the end go with CR-LF. For ESP8266 that is standart setting.
BUT!!!! AS I typed probles is USART on ATMEGA16. I can't send char 'A' from ATmega16 by USART to USB-USART PL2303 module and view it on Termite terminal prog.
I thought you said you got UART 115.2kBaud working on the ATmega16.
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
No I did not. I typed I switch to 16MHz extermal crystal but nothig changed.
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?
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.
I guess some problem in USART_Init func but I can't find any)
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.
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.
Tanks all for help. Some good ideas I will use like 'Circular Buffer ')
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...
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!
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.
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.
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.
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 ;-)
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.
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
Actually, more like 500 years to get to 100,000 writes with what I am currently doing. I hope to not live that long.
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'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??
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.
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 set LOW fuses as 0xFF.
I set LOW fuses as 0xFF.
Yup, thats the proper setting for external crystal.
JIm
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?
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
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).
USART_Init(51);
What crystal is this number for?
JIm
Darien wrote:USART_Init(51);What crystal is this number for?
JIm
16MHz -> 38.4K baud rate (I set lover speed) UBRR(dec)=51, U2Xn = 1
When I send from ATmega16 LED0 in ON (LED_PIN0).
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.
Darien wrote: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:When I send from ATmega16 LED0 in ON (LED_PIN0).
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.
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
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
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.
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
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.
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
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
All check... exept: .1uf cap on Vref.
But code still not working as expected.
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 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.