cpu/stm32f1: reworked UART driver #4952
Conversation
haukepetersen
added
Type: enhancement
haukepetersen
force-pushed
the
opt_f1_uart
branch
from
fd218cf to
25086ae
Compare
|
rebased @PeterKietzmann: ping |
| while (!(dev->SR & USART_SR_TXE)) {} | ||
| dev->DR = data[i]; | ||
| while(!(dev(uart)->SR & USART_SR_TXE)) { | ||
| cpu_sleep_until_event(); |
There was a problem hiding this comment.
Is an event generated when the byte is transmitted?
There was a problem hiding this comment.
Can this be affected by #5085?
There was a problem hiding this comment.
It should not be affected apart from working correctly :)
@lebrush Yes an event is generated because the TXE and UE interrupts are enabled. :)
|
The code looks good to me 👍 |
| @@ -39,6 +39,9 @@ extern "C" { | |||
| #define CLOCK_AHB_DIV RCC_CFGR_HPRE_DIV1 /* AHB clock -> 72MHz */ | |||
| #define CLOCK_APB2_DIV RCC_CFGR_PPRE2_DIV1 /* APB2 clock -> 72MHz */ | |||
| #define CLOCK_APB1_DIV RCC_CFGR_PPRE1_DIV2 /* APB1 clock -> 36MHz */ | |||
| /* resulting bus clocks */ | |||
| #define CLOCK_APB1 (CLOCK_CORECLOCK / 2) | |||
There was a problem hiding this comment.
If I see it correctly, macros in l39-41 aren't used anywhere thus can be removedas well. Having a note for the division by two (like resulting clock frequencies som lines above) should fit.
There was a problem hiding this comment.
not correct -> have a look at the cpu/stm32f1/cpu.c...
|
Besides minor comments the PR looks fine. I just tested on an iotlalb node with UART_0. Don't have other (relevant) hardware available |
haukepetersen
force-pushed
the
opt_f1_uart
branch
from
25086ae to
b75ca57
Compare
haukepetersen
force-pushed
the
opt_f1_uart
branch
from
b75ca57 to
b0606a7
Compare
haukepetersen
added
the
CI: ready for build
|
Rebased and took out the timer fixes (will open another PR for them). But when re-testing, the UART did not work anymore after #5085 was merged. So for now, I removed the call to |
|
Maybe the pending status must be cleared of TXE and UE. |
|
I still don't have a full overview of the difference between events and interrupts... but might it be because the |
|
@lebrush Yup that must be it =) |
|
that would make sense. I thought that the TX interrupt event (without the TXIE bit actually set) would already count as an event, but this seems not to be true. So maybe this local sleep concept does not work as easily as I thought... |
|
Looks fine for me. UART_0 still works on iotlab-m3, surprise... Would be nice if someone could check if fox or/and the nucleo board still work. Otherwise green lights from my side. |
|
AFAIK what hardware events that set the SEV event flag is completely up to the CPU vendor to choose, so if it works in one way on nrf5x it won't necessarily be the same concept on stm32. |
|
@haukepetersen The event interface is only available in the ARM interrupt controller and sleep manager. So for an event to be generated an interrupt line to the NVIC/interrupt controller must set it's pending state. Edit: The interrupt source in the peripheral must be enabled but the interrupt doesn't have to be enabled in the NVIC. :) |
|
@DipSwitch: that makes actually very much sense. @PeterKietzmann: I have also no other board than the iotlab here. I think for the |
|
How about something like this? |
|
@DipSwitch: I think it would work, but then it would make more sense to use DMA right away... I tend to leave it as is for this PR and then we can open a new one improving it. |
|
ACK
|
|
ALL CIs are happy -> and go. |
cpu/stm32f1: reworked UART driver
now using a simple trick silently introduced with #4840 to put the CPU to sleep at least a little bit during transmission of bytes...