Skip to content

STM32: serial: use proper macro to check interrupt #4707

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 13, 2017

Conversation

LMESTM
Copy link
Contributor

@LMESTM LMESTM commented Jul 5, 2017

Description

Depending on families, different HAL macros are defined to check the
state of serial interrupts. In several cases, we can find only 1 macro:
__HAL_UART_GET_IT_SOURCE
Checks whether the specified UART interrupt has occurred or not

But in F0, F3, F7, L0, L4 there are 2 different macros
__HAL_UART_GET_IT
Checks whether the specified UART interrupt has occurred or not
__HAL_UART_GET_IT_SOURCE
Checks whether the specified UART interrupt source is enabled.

In the later case, __HAL_UART_GET_IT_SOURCE was being used so far,
but actually needs to be replaced by __HAL_UART_GET_IT. Using the right
macro, we also check the proper flags accordingly.

This PR solves issue #3452

Status

READY

Test

Tested with simple test that produce an overrun condition, and making sure the board won't freeze.
Test code below, with a wire on RX/TX of the 2nd serial named (uart):

#include "mbed.h"

RawSerial pc(USBTX, USBRX);
RawSerial uart(D8, D2);
DigitalOut led1(LED1);

// This function is called when a character goes into the RX buffer.
void rxCallback(void) {
    led1 = !led1;
    pc.putc(uart.getc());
}

void pcrxCallback(void) {
    uart.putc(pc.getc());
}

int main() {
    // Use a deliberatly slow baud to fill up the TX buffer,
    // and get overrun conditions
    uart.baud(1200);
    uart.attach(&rxCallback, Serial::RxIrq);
    pc.attach(&pcrxCallback, Serial::RxIrq);

    printf("Starting test loop:\n");
    wait(1);

    while (true) {
        wait(1);
    }
}

@LMESTM
Copy link
Contributor Author

LMESTM commented Jul 6, 2017

Found a side effect for part of this change: so just updated ..

@LMESTM LMESTM force-pushed the stm32_serial_it_source branch from 4678a61 to 0a6d36b Compare July 6, 2017 07:30
@theotherjimmy
Copy link
Contributor

@0xc0170 Could you find someone to review this?

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 11, 2017

One note, first line of teh commit message should be maximum 50 characters (you can see the wrapping here), can you update that please?

Depending on families, different HAL macros are defined to check the
state of serial interrupts. In several cases, we can find only 1 macro:
__HAL_UART_GET_IT_SOURCE
Checks whether the specified UART interrupt has occurred or not

But in F0, F3, F7, L0, L4 there are 2 different macros
__HAL_UART_GET_IT
Checks whether the specified UART interrupt has occurred or not
__HAL_UART_GET_IT_SOURCE
Checks whether the specified UART interrupt source is enabled.

In the later case, __HAL_UART_GET_IT_SOURCE was being used so far,
but actually needs to be replaced by __HAL_UART_GET_IT. Using the right
macro, we also check the proper flags accordingly.
@LMESTM LMESTM force-pushed the stm32_serial_it_source branch from 0a6d36b to be8024d Compare July 11, 2017 15:23
@LMESTM
Copy link
Contributor Author

LMESTM commented Jul 11, 2017

@0xc0170 Ok update done - do you want me to also update the PR title ?

@LMESTM LMESTM changed the title STM32: serial: use proper macro to check which interrupt occured STM32: serial: use proper macro to check interrupt Jul 11, 2017
@0xc0170
Copy link
Contributor

0xc0170 commented Jul 11, 2017

@0xc0170 Ok update done - do you want me to also update the PR title ?

Yes, please

@LMESTM
Copy link
Contributor Author

LMESTM commented Jul 11, 2017

done as well

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 11, 2017

/morph test

@mbed-bot
Copy link

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 788

All builds and test passed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants