More v0.6.3 backports #249
Conversation
On ARMv7-M, bits 31:1 of the value read from STIMx are reserved, so comparing them against zero is a bad idea. On ARMv8-M, bit 1 has been repurposed to indicate DISABLED. This means that the is_fifo_ready impl hangs forever when ITM is disabled on a Cortex-M33 (for example). Changed to test only the FIFOREADY bit.
I think it's only non-exhaustive on master, not 0.6.x (if not, did I accidentally backport that breaking change?) |
|
Aha, no, I merged the clippy fix ( |
On ARMv7-M, bits 31:1 of the value read from STIMx are reserved, so comparing them against zero is a bad idea. On ARMv8-M, bit 1 has been repurposed to indicate DISABLED. This means that the is_fifo_ready impl hangs forever when ITM is disabled on a Cortex-M33 (for example). Changed to test only the FIFOREADY bit on ARMv7-M, and to test either FIFOREADY or DISABLED on ARMv8-M.
See #232, which this partially fixes -- there's still the question of taking an interrupt in the midst of these sequences.
This removes the duplication of the look-up table and enforces some safety checks with the match statement. Signed-off-by: Hugues de Valon <[email protected]>
adamgreig
force-pushed
the
more-v6-backports
branch
from
c6800fb to
6717d4b
Compare
|
bors r+ |
|
👎 Rejected by too few approved reviews |
|
Looks like the -Dwarnings in CI is causing all nightlies to fail due to a clippy lint? here. |
|
Build succeeded: |
I wonder why it's not failing on stable, too. |
|
The lint doesn't seem quite right, either, I don't think it's understood what we're doing. I guess let's not worry about it for 0.6.x and solve it in master which presumably has the same issue? |
|
It can't see through the We have that in a few HAL impls, too: If you have a |
249: Ignore a doctest again r=adamgreig a=jonas-schievink I accidentally typoed `no_run`, but compiling the test fails since the `device.x` path is wrong. I don't think this can be fixed, so ignore the test instead. The effect is the same as before but now the block gets highlighted again. Co-authored-by: Jonas Schievink <[email protected]>
I think this includes the remainder of the non-breaking changes since v0.6.2, with a couple of exceptions:
I did include #226 which adds a new field toPeripherals, but as I understand it that should be a non-breaking change since it's non-exhaustive.I've updated the CHANGELOG with all the changes from this PR and the previous #248.