Serial error interrupt #2566
Serial error interrupt #2566
Conversation
|
/morph test |
|
@mbed-bot: TEST HOST_OSES=ALL |
|
[Build 858] |
Result: FAILUREYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 737 Test failed! |
|
@c1728p9 The failure was caused by the Windows failure we saw earlier. Feel free to restart when you're ready |
|
/morph test |
Result: FAILUREYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 740 Test Prep failed! |
| TxIrq, | ||
| ErIrq, | ||
|
|
||
| IrqCnt |
There was a problem hiding this comment.
Add IrqCnt to other drivers
There was a problem hiding this comment.
Add IrqCnt to other drivers
Serial or others?
Edit:I see the CAN, so that's what you meant.
|
/morph test |
Result: ABORTEDYour command has finished executing! Here's what you wrote!
|
|
This is a new feature (adding new serial error interrupt handler), shall we move this from master to its own feature branch, to add implementation for the rest of the platforms prior landing to master? I would say yes. This error IRQ would be useful, I recall this similar change was to be added in mbed 3. Here's the change proposed: https://github.com/ARMmbed/mbed-hal/pull/70/files. It's not documented here what is expected to be reported (if error happens, what a user should do ? all error flags are cleared, and it's just a report callback ?). Do a user get a function to retrieve an error (what was proposed in the link I referenced) ? |
|
@0xc0170, my expectation of this function is an overrun or some other error occurred. If the device/protocol is fault tolerant then whichever operation it performed should be retried. If not, an error should be triggered. This change might not require a feature branch, since nothing bad will happen for targets which don't implement this error interrupt. Applications just won't get that event. In the future when we want to start enforcing that all targets support this, a test could easily be added which causes an overrun and asserts that this interrupt occurs. What do you think @0xc0170. Also, @sg-, any thoughts on this? |
|
/morph test |
Rather than hard coding the size of the callback array for irqs, instead set the size to IrqCnt which is defined by the irq enumeration.
Add an error interrupt option to serial_api.h and SerialBase.h in addition to the transmit and receive options. This allows serial driver to report error conditions that could indicate a dropped byte or other loss of data.
Update the K64F to call the serial error interrupt handler when an overrun occurs. Prior to this overrun errors were ignored.
c1728p9
force-pushed
the
serial_error_interrupt
branch
from
02bec3a to
03367f9
Compare
|
This PR is on top of #2584 |
|
/morph test |
Result: FAILUREYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 751 Test failed! |
|
/morph test |
Result: FAILUREYour command has finished executing! Here's what you wrote!
Outputmbed Build Number: 754 Test failed! |
This should be documented? A user should know when an error is invoked and what happens with those errors (any serial error triggers ErIRQ callback, error clearance is handled by HAL). Same description for HAL, the implementation should conform. It might be sufficient to add this description to the enum.
It's implemented for really small subset of targets. There's no defined timeline where it should be implemented for the rest. If this goes to a release, we are releasing a new feature for just 1,3 or targets. I would like to avoid that. I'll discuss this with you guys, as we should have a clear definition how to extend HAL - that's my main concern. For instance, my proposal could be:
Feature branch provides time for design, review, test and integration. |
|
Moving to a feature branch at the request of @0xc0170. |
Extend the serial API to add error interrupts.