UART line idle handling.

Discussions and support about ChibiOS/HAL, the MCU Hardware Abstraction Layer.
User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Been thanked: 7 times

Re: UART line idle handling.

Post by barthess »

1) User have to explicitly set appropriate flags in CRx registers to get timeout interrupt/callback. If user wants old (without timeout) behaviour than he just fill new fields in config structure to NULL/0 values. No other changes needed.
2) Added it. Any way I do not use synchronous API for UART and can not evaluate its convenience in appliance to timeout. Hope it will be useful.
User avatar
Giovanni
Site Admin
Posts: 14891
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: UART line idle handling.

Post by Giovanni »

Hi,

It looks good so far, thanks, it is a very useful feature.

Giovanni
User avatar
barthess
Posts: 861
Joined: Wed Dec 08, 2010 7:55 pm
Been thanked: 7 times

Re: UART line idle handling.

Post by barthess »

@Giovanni
Why this checks needed?

Code: Select all

(cr1 & USART_CR1_IDLEIE) (cr1 & USART_CR1_RTOIE)

They are redundant from my point of view. May be any errata notes I am missed?
User avatar
Giovanni
Site Admin
Posts: 14891
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: UART line idle handling.

Post by Giovanni »

We don't want to serve those interrupt flags if not explicitly enabled in CR1. Without those checks you could spuriously call the timeout callback when another kind of error triggers the ISR.

Giovanni
User avatar
kimmoli
Posts: 26
Joined: Sat Oct 01, 2016 8:02 pm
Has thanked: 11 times
Been thanked: 8 times

Re: UART line idle handling.

Post by kimmoli »

Noticed that IDLE interrupt mechanism is missing from USARTv1, altough atleast F4 USART has this functionality.

I think adding support would be a simple task (see below). We will test this on monday with DMA reception, but afaiu the callback definition (_uart_timeout_isr_code()) is in the include that is common for both.

https://github.com/kimmoli/ChibiOS/comm ... 89ca7707c7

Or am i missing something?

(apologies for necromancing an old thread)
User avatar
Giovanni
Site Admin
Posts: 14891
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: UART line idle handling.

Post by Giovanni »

It should work, it is just missing.

Giovanni
User avatar
kimmoli
Posts: 26
Joined: Sat Oct 01, 2016 8:02 pm
Has thanked: 11 times
Been thanked: 8 times

Re: UART line idle handling.

Post by kimmoli »

Although my changes had some errors... missing the timeout_cb from USARTConfig struct, and typo in USART_ISR_IDLE (Should be USART_SR_IDLE)

(https://github.com/kimmoli/ChibiOS/commits/usartv1_idle)
User avatar
Korken
Posts: 270
Joined: Wed Apr 02, 2014 4:09 pm
Has thanked: 5 times
Been thanked: 6 times

Re: UART line idle handling.

Post by Korken »

Hi Giovanni,
Will you add this? It does not seems to have been added to trunk.
michael_s
Posts: 4
Joined: Thu Dec 03, 2015 3:31 pm
Been thanked: 1 time

Re: UART line idle handling.

Post by michael_s »

Hello Giovanni,

I would like to upvote this feature also as we need free bus detection for our RS-485 implementation.

In addition to checking USART_SR_IDLE, it would be necessary to check the BUSY flag (bit 16)in USART_ISR register also, since USART_SR_IDLE is only set by hardware once an idle condition is present and not cleared in case the bus becomes busy in the meantime. So, I would propose:

Code: Select all

/* Timeout interrupt source is only checked if enabled in CR1 and if BUSY flag is not set.*/
if ((sr & USART_ISR_IDLE) && (cr1 & USART_CR1_IDLEIE) && (sr & 0x10000U) {
  _uart_timeout_isr_code(uartp);
}


BUSY flag is hardcoded (0x10000U) since CMSIS header does not provide it.
What do you think?
User avatar
Giovanni
Site Admin
Posts: 14891
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: UART line idle handling.

Post by Giovanni »

Hi,

Could you please post it in the "change requests" forum? it is hard to remember all posts.

"bug reports" and "change requests" are actively monitored.

Giovanni
Post Reply