5 years ago.

I see a couple problems. First rule for interrupts is Get in and get out ASAP. Do not call wait() inside of an ISR. Do not use printf in an interrupt. Normal printf is guarded with a mutex and mutexes are not allowed in ISR. The rawserial has a printf implemented without mutex. But it’s still a bad idea because printf is going to sit there and block the rest of your program while it slowly putc()’s characters out.

Put a wait statement in your main while loop – nearly any length will do. You want to release main to the scheduler to let other stuff run.

I would focus on getting the RX callback working first and not worry about TX. Do your TX printfs in main code. RX is always an issue because bytes could come in at any time. TX you control so there is less of a reason to do that via interrupt.

In RX interrupt what you want to do is the getc() and save the character. Getc() clears the interrupt flag. Then you want to signal another part of the program that there is a new char or message to handle. A bool flag in rx could work, be sure to use type volatile. If a char is received, set it and get out. Now in main(), which is not doing anything, you can rapidly check for the receive flag, and then handle the new char. Clear receive flag in main when you’re done with it.

It is common inside RX to push chars onto a buffer, and only signal when you have a complete message. A complete message could be as simple as ascii text that ends with a newline char. You seem to be using integers, so you can encode those as text so 123 becomes “123\n”.

Your main is free, so you can just put the lcd stuff in there and you are good to go. If main were busy with something else, a good pattern would be to put your lcd printf stuff in a new thread with a mailbox. Rxcallback then puts the new char or message into lcd thread. RX ISR then exists and the rtos will see the mail and call your lcd thread. This way you are deferring work out of ISR context back into the main program.

Have not tested, but something like this. This will only be able to handle single characters every so often because new_char is shared between ISR and main. When you start doing printf's in main it's a race to finish before a new char arrives in ISR. Packing into messages helps. Having request/response design with the sender helps.

include "mbed.h"
include "C12832.h"

UART6_RX = PA_12 
UART6_TX = PA_11 

C12832 lcd(D11,D13,D12,D7,D10); 
RawSerial usart6(PA_11,PA_12);

volatile bool received = false;
volatile char new_char = false;

void RXCallBack () { 
    new_char = usart6.getc(); 
    received = true;
}

int main() { 

    usart6.baud(115200); 
    usart6.attach(&RXCallBack, Serial::RxIrq); 

    lcd.printf("Test"); 

    char c = 0; 

    while (1) {
        if (received) {
            lcd.locate(0,2); 
            lcd.printf(" "); 
            lcd.locate(0,2); 
            lcd.printf("Receiving: %d", new_char);
            received = false;
        }
        usart6.putc(c); 
        c++;
        wait(0.01);
    }
}