AVR Freaks

while (c != ('\r' || '\n'));

('\r' || '\n') is the same as (1)

so you end up with-

while( c != (1) );

and will probably be a long time before that is not true

this is probably want you wanted-

while( c != '\r' && c != '\n' );

First- figure out what you are expecting to receive. When sending, you use '\r' as termination. When receiving, your code is looking for either \r\n or \n\n. If all you receive is a '\r',  then  you will be stuck waiting for a \n that will never show up.

Here is a modification of your original code, for an attiny416 nano board-

#define F_CPU 3333333

#include <xc.h>
#include <util/delay.h>
#include <stdbool.h>

#define USART0_BAUD_RATE(BAUD_RATE) ((float)(3333333 * 64 / (16 * (float)BAUD_RATE)) + 0.5)

void USART_0_write(const uint8_t data) {
    while (!(USART0.STATUS & USART_DREIF_bm));
    USART0.TXDATAL = data;
    //clear txcif any time writing data so can always
    //check this flag anytime to see if data is done
    //transmitting
    USART0.STATUS = USART_TXCIF_bm;
}

//return value = -1 = timeout or error
//return value >=0 = good data
//using a simple timeout (65k loops in this case)
int16_t USART_0_read(){
    uint8_t Hrx, rx;
    for(uint16_t timeout = 0xFFFF;;){       //pick a number
        Hrx = USART0.RXDATAH;               //get RXCIF and errors
        if( Hrx & 0x80 ) break;             //RXCIF set, have data
        if( timeout-- == 0 ) return -1;     //timeout error
    }
    rx = USART0.RXDATAL;                    //get data from rx buffer
    if( Hrx & 0x46 ) return -1;             //some error?, return -1
    return rx;                              //8 bit data (bit 9 is in Hrx if needed)
}

//just read rx 3 times to flush
//2 level buffer + shift register
void USART_0_flushrx(){
    (void)USART0.RXDATAL;
    (void)USART0.RXDATAL;
    (void)USART0.RXDATAL;
}

void Send_AT_CMD(const char* str) {
    for( ; *str; ) USART_0_write(*str++);
    USART_0_write('\r');
    //don't want any previous data that somehow came in
    //like extra \r or \n or unexpected error messages
    //so flush whatever is in rx before checking reply
    USART_0_flushrx();
    //now wait for USART TX complete so do not
    //start to attempt receive until done sending
    while (!(USART0.STATUS & USART_TXCIF_bm));
}

//incoming data needs to match str
//then a \r or a \n
bool Read_AT(const char* str) {
    int16_t c = 0;
    for( ; *str; str++ ){       //until end of str
        c = USART_0_read();     //get char (if timeout or error, is -1)
        if( c != *str ) break;  //not a match, no more checking
    }
    c = USART_0_read();         //try to get terminator
    //if last char was a terminator char, and *str is 0, then
    //the match is true, else is false
    return ( c == '\r' || c == '\n' ) && *str == 0;
}

//blink led n times
//at416 nano board
void tiny416nano_ledblink(uint8_t n){
    for( ; n--; ){
        VPORTB.OUT &= ~PIN5_bm; //on
        _delay_ms(50);
        VPORTB.OUT |= PIN5_bm; //off
        _delay_ms(50);
    }
}

int main() {
    //VPORTA.DIR |= PIN6_bm; // Configure USART TX pin as output pin 2 (ATtiny202)
    //VPORTA.DIR &= ~PIN7_bm; // Configure USART RX pin as input pin 3

//  (ATtiny416)
VPORTA.DIR |= PIN1_bm;
VPORTA.DIR &= ~PIN2_bm;
PORTMUX.CTRLB |= 1; //alt pins

    USART0.BAUD = (uint16_t) USART0_BAUD_RATE(9600);

    USART0.CTRLB |= USART_TXEN_bm; // Enable Transmitter
    USART0.CTRLB |= USART_RXEN_bm; // Enable Reciever

USART0.DBGCTRL = 1;
//tiny416 nano board led
VPORTB.OUT |= PIN5_bm; //high=off
VPORTB.DIR |= PIN5_bm; //output

    while (1) {
        Send_AT_CMD("AT");
        if( Read_AT("OK") ){
            tiny416nano_ledblink(5);
        } else {
            tiny416nano_ledblink(1);
            _delay_ms(400);
        }
        _delay_ms(1000);
    }
}

this was compiled/debugged on a tiny416 nano board, and the AT\r command was being received on the pc, and the pc was sending OK\r to the board and the led lights indicated the OK was a match.

There may be ideas in there that you can use if wanted. Some notes-

-when dealing with 0 terminated strings, there is usually no need to be concerned with size as you have the 0 to mark the end of the string

-a usart receive with some method to deal with errors and timeouts (when polling) is not too hard to do, so may as well do it

 you can also move the timeout out of the read() function and let the caller deal with it (just return -1 if no data available)

 what you don't want, is waiting around (blocking) for something that never shows up or will never show up for any number of reasons

-clear the txcif flag anytime you write to tx, so this flag can be checked anytime and always be valid (with one exception, if no data was ever tx)

-the Read_AT function will try to match a passed in string from the rx data, I think its correct (and did work when tested with "OK"), but you can

 work out what is happening- anything other than an exact match of the string followed by a \r or \n will return false- and also leave any other

 incoming chars in the rx buffer(s), which will get flushed later (I don't know what the incoming terminator char is, but will work with any combo of \r and \n)

-you may have to play around with the timeout values in USART_0_read(), or just use _delay_us() in the loop, or something else, I think

 65k loops of that code at 3.3MHz will be over 150ms but using a _delay_us() in there may be better as you then know what you are getting

>Otherwise, my (working) code looks just like yours.

RXCIF is also in the rx data H byte, so you can save yourself one lds by eliminating the need to also read status. Not that important, but its there so may as well use it.

>As I said in #7 life is a lot easier if you just connect stdout/stin/stderr to a UART stream:

You just filled up 97% of the flash in his tiny202 with your example and have not yet begun to use scanf. Eliminating var arguments to printf in your example cuts that down quite a bit (so then no purpose to it), but bring in any scanf variants and you are over 2k again.

This is also glossed over-

https://www.avrfreaks.net/commen...

He is trying to 'flush' a \n that may or may not ever be seen.

I think this is his modem, and its at commands-

https://github.com/Thinxtra/Xkit-Sample/blob/master/Document/Wisol_ATCommands_and_Datasheets/WISOL_WSSFM10R_AT%20command_SFM10R_Rev.00_1.pdf

not much info about CR/LF usage, or even if there is any error messages (I doubt it- seems to be OK for responses without data, or response with data, or no reply if error?)

all examples use \r for sending commands, so maybe the device replies with only \r also, and a \n is never seen (which would be one reason he is stuck in his loop)

There seems to be enough info in this thread, it just needs to be read.

>The use of CR and LF is part of the Hayes standard - now formalised as V.250:

Somehow, I doubt that the maker of the wireless device is too concerned with following any kind of standard. Like most of these devices they just copy the general idea of the AT command set. If they send a \r only, that is what you get and waiting around for \n that will never show up will keep you waiting until your batteries die-

   do
        c = USART_0_read(); // Flush '\n'
    while (c != '\n');

Its certainly easy enough to figure out what is being sent and code accordingly.