[RTEMS Project] #3310: zynq_uart_write_polled could produce a blocking scenario
RTEMS trac
trac at rtems.org
Wed Feb 21 10:10:54 UTC 2018
#3310: zynq_uart_write_polled could produce a blocking scenario
--------------------------+--------------------------
Reporter: fdpousa | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: bsps | Version: 5
Severity: normal | Keywords: zynq arm bsp
Blocked By: | Blocking:
--------------------------+--------------------------
The actual code for the zynq_uart_write_polled has a while loop inside.
What could happen if a hw fault occurs? If TX buffer is always full, lower
priority tasks may remain in a blocked state. The objective is to use the
UART communication directly by RS232/RS422 protocol without any console.
Why is this function codified different than zynq_uart_read_polled()? With
the zynq_uart_read_polled codification the blocking risks disappear if hw
fails and a byte is never put in RX Buffer. I suggest to apply the same if
struct to zynq_uart_write_polled.
--
Ticket URL: <http://devel.rtems.org/ticket/3310>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
More information about the bugs
mailing list