UART only working correctly one way (ATmega328p)

Question

I got an Arduino Uno, which is driven by an ATmega328P. And I wanted to move away from its libraries and do everything on a lower level for learning purposes. However I cannot get the uart working correctly, it works now only when sending to the device. Receiving returns weird garbage wich the temrinal can't print.

#define BAUDRATE (((F_CPU / (BAUD * 16UL))) - 1)
void init_uart()
{
    UBRR0H = BAUDRATE >> 8; // set high baud
    UBRR0L = BAUDRATE; //set low baud
    UCSR0B = _BV(TXEN0) | _BV(RXEN0); //enable duplex
    UCSR0C = _BV(UCSZ00) | _BV(UCSZ01) | _BV(USBS0); //8-N-1
}

void putchar_uart(char c, FILE* stream)
{
    loop_until_bit_is_set(UCSR0A, UDRE0);   //wait till prev char is read
    UDR0 = c;
}

char getchar_uart(FILE* stream)
{
    loop_until_bit_is_set(UCSR0A, RXC0);    //wait if there is data
    return UDR0;
}

//^ actually is in a seperate file which gets linked

int main()
{
    DDRD |= PIN_LED;
    PORTD |= PIN_LED;

    stdout = &mystdout;
    stdin = &mystdin;

    char buf[0xFF];

    init_uart();
    while (1)
    {
        char c = getchar_uart(NULL);
        if (c == 'a')
        {
            PIND = PIN_LED;
            printf("%s\n", "Hallo");
        }
    }
}

I'm running Ubuntu 14.04 LTS and using minicom for the communication. Which is setup as: 115200 8N1 (with the correct serial device of course.)

It gets compiled as:

avr-gcc -Wall -Os -mmcu=atmega328p -DF_CPU=16000000UL -DBAUD=115200 -std=c99 -L/home/joel/avr-libs/lib -I/home/joel/avr-libs/inc -o firmware.o main.c  -luart

So how do I know that one way works? Because of the led only toggles when typing in an 'a'. But the response are invalid characters. In hex:

c8 e1 ec ec ef 8a

Answer 1

By setting the USBS bit you are commanding a second stop bit.

This appears to lead your computer to mistakenly believe that the MSB (which is the last data bit) is set when it isn't causing your received data to be OR'd with 0x80.

While this will cause a framing error, it is probably not the cause of the wrong MSB. Your own answer about switching to 2x mode (and thus more accurately approximating the baud rate) is more key to the solution, though you should correct this too.