aboutsummaryrefslogtreecommitdiff
path: root/examples
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | stm32/ipcc: fix hil testxoviat2023-05-211-1/+1
| | | | |
| * | | | stm32/ipcc: update docxoviat2023-05-212-0/+2
| | | | |
| * | | | tl_mbox read and writegoueslati2023-05-152-1/+101
| | | | |
* | | | | Switch to DMA, use new clocks, don't take ownership of pio commonCaleb Jamison2023-05-191-13/+31
| | | | |
* | | | | Pin fix, improve fifo handlingCaleb Jamison2023-05-191-1/+5
| | | | |
* | | | | Update Rust nightly.Dario Nieuwenhuis2023-05-194-4/+0
| | | | |
* | | | | Merge #1419bors[bot]2023-05-191-28/+3
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1419: stm32/pwm: improve dead-time api r=Dirbaio a=xoviat Co-authored-by: xoviat <[email protected]>
| * | | | | stm32/pwm: improve dead-time apixoviat2023-05-011-28/+3
| | | | | |
* | | | | | rp/clocks: don't expose unstable pac itemspennae2023-05-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | exposing pac items kind of undermines the unstable-pac feature. directly exposing register structure is also pretty inconvenient since the clock switching code takes care of the src/aux difference in behavior, so a user needn't really be forced to write down decomposed register values.
* | | | | | rp: Read flash unique id and jedec idkalkyl2023-05-161-0/+10
| | | | | |
* | | | | | Merge #1458bors[bot]2023-05-157-33/+52
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1458: rp: remove take!, add bind_interrupts! r=Dirbaio a=pennae both of the uart interrupts now check a flag that only the dma rx path ever sets (and now unsets again on drop) to return early if it's not as they expect. this is ... not our preferred solution, but if bind_interrupts *must* allow mutiple handlers to be specified then this is the only way we can think of that doesn't break uarts. Co-authored-by: pennae <[email protected]>
| * | | | | | rp: remove take!, add bind_interrupts!pennae2023-05-157-33/+52
| | | | | | |
* | | | | | | net: reexport UDP PacketMetadata under the udp module.Dario Nieuwenhuis2023-05-151-2/+2
| | | | | | |
* | | | | | | net: do not use smoltcp Instant/Duration in public API.Dario Nieuwenhuis2023-05-158-8/+9
|/ / / / / /
* | / / / / rp: don't use SetConfig trait in PWM and PIO.Dario Nieuwenhuis2023-05-135-5/+0
| |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | It was intended to allow changing baudrate on shared spi/i2c. There's no advantage in using it for PWM or PIO, and makes it less usable because you have to have `embassy-embedded-hal` as a dep to use it.
* | | | | Merge #1424bors[bot]2023-05-114-21/+84
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1424: add TL maibox for stm32wb r=xoviat a=OueslatiGhaith Hello, This pull request is related to #1397 and #1401, inspired by #24, build upon the work done in #1405, and was tested on an stm32wb55rg. This pull request aims to add the transport layer mailbox for stm32wb microcontrollers. For now it's only capable of initializing it and getting the firmware information Co-authored-by: goueslati <[email protected]> Co-authored-by: Ghaith Oueslati <[email protected]> Co-authored-by: xoviat <[email protected]>
| * | | | | fix memory.xxoviat2023-05-111-4/+4
| | | | | |
| * | | | | rustfmtxoviat2023-05-111-3/+3
| | | | | |
| * | | | | stm32/ble: fix tests and add instructions to run examplexoviat2023-05-113-5/+40
| | | | | |
| * | | | | removed hardcoded addresses in memory.xgoueslati2023-05-043-20/+6
| | | | | |
| * | | | | rustfmtxoviat2023-05-031-1/+0
| | | | | |
| * | | | | stm32/tests: add hil test for blexoviat2023-05-031-1/+0
| | | | | |
| * | | | | added TL Mailbox initialization for STM32WBgoueslati2023-05-021-0/+44
| | | | | |
* | | | | | Merge branch 'master' into masterCaleb Jamison2023-05-0915-16/+168
|\ \ \ \ \ \
| * | | | | | Fix some typosDirk Stolle2023-05-0813-15/+15
| | | | | | |
| * | | | | | Merge #1435bors[bot]2023-05-082-1/+153
| |\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1435: Added example for multi priority executors rp2040 r=Dirbaio a=fakusb I added an example for multiple priorities of tasks on rp2040 by adjusting [examples/nrf52840/src/bin/multiprio.rs](https://github.com/embassy-rs/embassy/blob/master/examples/nrf52840/src/bin/multiprio.rs) . This needs https://github.com/embassy-rs/rp-pac/pull/2 , and this commit also adds the 6 new interrupt handlers for software interrupts to embassy-rs. We might need to change the git path for rp-pac in [embassy-rp/Cargo.toml](https://github.com/embassy-rs/embassy/compare/master...fakusb:rp2040-multiprio-executor?expand=1#diff-47463ea358745927ecdb686f52feab816fde5d402a9628a136c116f34a802ab0) Closes #1413 Co-authored-by: Fabian Kunze <[email protected]>
| | * | | | | | added example multi priority executors rp2040Fabian Kunze2023-05-072-1/+153
| | | | | | | |
* | | | | | | | Dirbaio comments round 2Caleb Jamison2023-05-091-5/+5
| | | | | | | |
* | | | | | | | Remove patches, bump rp-pac versionCaleb Jamison2023-05-091-3/+0
| | | | | | | |
* | | | | | | | Improve gpout example, clk_gpout_freqCaleb Jamison2023-05-092-6/+22
| | | | | | | |
* | | | | | | | Add missing functions, Cleanup, Gpout exampleCaleb Jamison2023-05-081-0/+21
|/ / / / / / /
* | | | | | | rp/pio: allow wrap-around program loadingpennae2023-05-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | execution wraps around after the end of instruction memory and wrapping works with this, so we may as well allow program loading across this boundary. could be useful for reusing chunks of instruction memory.
* | | | | | | rp/pio: configure state machines with Config structpennae2023-05-065-64/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the many individual sets aren't very efficient, and almost no checks were done to ensure that the configuration written to the hardware was actually valid. this adresses both of these.
* | | | | | | rp/pio: add set-pin-{values,dirs} convenience functionspennae2023-05-061-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | these are needed a lot during state machine setup, it makes sense to provide convenience functions for them.
* | | | | | | rp/pio: add load_program, use_programpennae2023-05-064-48/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | programs contain information we could pull from them directly and use to validate other configuration of the state machine instead of asking the user to pull them out and hand them to us bit by bit. unfortunately programs do not specify how many in or out bits they use, so we can only handle side-set and wrapping jumps like this. it's still something though.
* | | | | | | rp/pio: drop Pio prefix from almost all namespennae2023-05-053-14/+14
|/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | it's only any good for PioPin because there it follows a pattern of gpio pin alternate functions being named like that, everything else can just as well be referred to as `pio::Thing`
* | | | | | Merge #1429bors[bot]2023-05-044-44/+44
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1429: rp pio, √9 r=Dirbaio a=pennae another mix of refactoring and soundness issues. most notably pio pins are now checked for being actually accessible to the pio blocks, are constructible from not just the owned peripherals but refs as well, and have their registrations to the pio block reverted once all state machines and the common block has been dropped. state machines are now also stopped when dropped, and concurrent rx+tx using dma can finally be done in a sound manner. previously it was possible to do, but allowed users to start two concurrent transfers to the same fifo using different dma channels, which obviously would not have the expected results on average. Co-authored-by: pennae <[email protected]>
| * | | | | | rp/pio: wrap sm rx, tx in structs and allow splittingpennae2023-05-034-13/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this *finally* allows sound implementions of bidirectional transfers without blocking. the futures previously allowed only a single direction to be active at any given time, and the dma transfers didn't take a mutable reference and were thus unsound.
| * | | | | | rp/pio: split irqs from state machinespennae2023-05-032-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | we can only have one active waiter for any given irq at any given time. allowing waits for irqs on state machines bypasses this limitation and causes lost events for all but the latest waiter for a given irq. splitting this out also allows us to signal from state machines to other parts of the application without monopolizing state machine access for the irq wait, as would be necessary to make irq waiting sound.
| * | | | | | rp/pio: remove PioStateMachineInstancepennae2023-05-034-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | move all methods into PioStateMachine instead. the huge trait wasn't object-safe and thus didn't have any benefits whatsoever except for making it *slightly* easier to write bounds for passing around state machines. that would be much better solved with generics-less instances.
| * | | | | | rp/pio: PioStateMachine{Instance, => ,Instance}pennae2023-05-034-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | next step: get rid of the insance trait entirely
| * | | | | | rp/pio: add PioPin traitpennae2023-05-033-17/+14
| | |_|/ / / | |/| | | | | | | | | | | | | | | | | | | | | | pio can only access pins in bank 0, so it doesn't make sense to even allow wrapping of other banks' pins.
* | | | | | Simplify SUBGHZSPI configuration.ceekdee2023-05-043-12/+3
| | | | | |
* | | | | | Merge branch 'embassy-rs:master' into masterChuck Davis2023-05-034-26/+276
|\| | | | |
| * | | | | Merge #1425bors[bot]2023-05-024-26/+276
| |\ \ \ \ \ | | |/ / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1425: rp pio, round 2 r=Dirbaio a=pennae another round of bugfixes for pio, and some refactoring. in the end we'd like to make pio look like all the other modules and not expose traits that provide all the methods of a type, but put them onto the type itself. traits only make much sense, even if we added an AnyPio and merged the types for the member state machines (at the cost of at least a u8 per member of Pio). Co-authored-by: pennae <[email protected]>
| | * | | | rp/pio: drop SmInstance{,Base}pennae2023-05-023-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | these are just overly convoluted ways of writing down numbers.
| | * | | | rp/pio: make PioCommon a structpennae2023-05-024-17/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the PioCommon trait does not serve much of a purpose; there can be only two implementations and they only differ in a few associated constants.
| | * | | | rp/pio: PioInstance::split -> Pio::newpennae2023-05-024-23/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | not requiring a PioInstance for splitting lets us split from a PeripheralRef or borrowed PIO as well, mirroring every other peripheral in embassy_rp. pio pins still have to be constructed from owned pin instances for now.
| | * | | | rp/pio: remove PioPeripheralpennae2023-05-024-14/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | merge into PioInstance instead. PioPeripheral was mostly a wrapper around PioInstance anyway, and the way the wrapping was done required PioInstanceBase<N> types where PIO{N} could've been used instead.
| | * | | | rp/pio: add hd44780 examplepennae2023-05-021-0/+244
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | add an hd44780 example for pio. hd44780 with busy polling is a pretty complicated protocol if the busy polling is to be done by the peripheral, and this example exercises many pio features that we don't have good examples for yet.