The constructors themselves are not strictly unsafe. Interactions with DMA can be generally unsafe if a future is dropped, but that's a separate issue. It is important that we use the `unsafe` keyword diligently as it can lead to confusion otherwise.
- Scary pointer math is now contained in the tasks and events
- ppi now sets the tasks and events immediately and the struct is now zero-sized
- StaticToOne is renamed to ZeroToOne
- Used DPPI tasks and events now panic when enabled twice
- Removed ConfigurableChannel and added capacity numbers to the channels
- Replaced the PPI api with a new one using the DPPI terminology (publish & subscribe)
- Updated all tasks and event registers for DPPI
- It disturbs other stuff that uses WFE/SEV in the system. I ran into
issues with this.
- It needs the irq handler to check for RXTO/TXSTOPPED errors, which makes
it slower.
Add type UarteWithIdle that implements Read, Write and ReadUntilIdle
traits. The type uses a timer + 2 PPI channels internally, triggered on
RTXSTARTED event.
Since introducing the ctx pointer, the handler is now two words, so setting it can
race with the interrupt firing. On race it's possible for the new handler to be
alled with the old ctx pointer or viceversa.
Rather than documenting this, it's better to split the function in two to make it
obvious to the user that it's not atomic. The user can use a critical section, or
disable/enable the interrupt to avoid races if this is a concern.
The `interrupt` package previously tried to be drop-in compatible with the
`interrupt` package from PACs. THis meant that there was both a PAC-style enum
value `UARTE0` and an embassy-style owned `UARTE0Interrupt` type. This made
things VERY confusing.
This drops compatibility with the PAC, improving the names for embassy interrupts.
Prevents a panic in the case of:
1. Abort a receive future
2. Free Uarte::free()
3. Uarte::new()
-> panicked at 'assertion failed: uarte.enable.read().enable().is_disabled()'
The PS does not specify how many cycles it takes for a STARTXX task to
generate a XXSTARTED event. I think it is instantaneous but let’s be on
the safe side for the following sequence:
1. poll() starttx
2. drop() txstarted not yet set, but future gets dropped
3. txstarted set by hardware, peripheral enabled after it was dropped
