Uart semantics and proofs (cont'd)#888
Conversation
Specification & proofs has been added for the following functions: - bitfield_field32_write - bitfield_bit32_write The postcondition just states that the return value is basically what is computed in the function body, which might be not very useful for its callers. We will add or modify the postcondition later if needed.
jadephilipoom
left a comment
There was a problem hiding this comment.
The UART proofs look good, great work! However, I want to resolve the point about IncrementWait before merging.
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
|
@googlebot I signed it! |
|
It seems that @jadephilipoom's as well as my requested changes have been addressed, or turned into new issues, so I'm going to merge this now, so that I can make my next PR on top of it. |
|
Thanks @dayeol for dealing with all my nitpicks 😉 |
This completes the spec & proof of the following functions (#889)
uart_putcharuart_tx_fullThe function has 2 while loops: at the beginning to make sure the tx FIFO is not full, and at the end to ensure the device is back to IDLE state.
For now, it has been proven with the precondition where the device state is always IDLE when we enter the function.
This makes the first loop iterate exactly once.
It makes sense in a single-threaded environment because the only way to make the device busy is via
uart_putchar,but the function waits the device to be IDLE state before it returns.
However, we could also generalize it by relaxing the precondition to be
execution tr sfor any states,and it would be pretty straightforward to prove that too --
scan be destructed, and ifsisIDLEwe just do the same thing, and ifsisBUSYthen we can prove that at some point the loop should break leaving the device inIDLEstate.