this is only really useful for runtime *re*configuration, which we don't
currently support. even runtime reconfig probably won't need it, unless
we keep taking the sledgehammer approach of reconfiguring everything all
the time.
1459: rp/multicore: fix undefined behavior in multicore spawn. r=Dirbaio a=Dirbaio
It is UB to pass `entry` to core1 as `&mut`, because core0 keeps an aliasing pointer to that memory region, and actually writes to it (when `spawn_core1` returns, the stack frame gets deallocated and the memory gets reused). This violates noalias requirements.
Added the fence just in case, een though it works without.
bors r+
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
It is UB to pass `entry` to core1 as `&mut`, because core0 keeps
an aliasing pointer to that memory region, and actually writes to
it (when `spawn_core1` returns, the stack frame gets deallocated and the memory
gets reused). This violates noalias requirements.
Added the fence just in case, een though it works without.
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 <github@quasiparticle.net>
1456: net: do not use smoltcp Instant/Duration in public API, docs. r=Dirbaio a=Dirbaio
bors r+
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
1451: Work around xtensa deadlock, take 2 r=Dirbaio a=bugadani
This PR is another go at trying to do something with #1449. The commit was part of the previous attempt but mistakenly discarded as I still experienced lockups. However, after further testing, it looks like that lockup is caused by something else.
This is a manual, "cpu-local" critical section impl that should be good enough on dual-core CPUs, although the implementation still contains `SIGNAL_WORK_THREAD_MODE` which is absolutely not correct on dual-core. This approach was chosen because:
- not taking the global lock technically allows the second core to run
- wrapping the signal read and the sleep in a critical section prevents a race condition that would cause the CPU to sleep longer than ideal if an interrupt hits after reading, but before sleeping.
Co-authored-by: Dániel Buga <bugadani@gmail.com>
1454: stm32f0 flash implementation r=Dirbaio a=jp99
i've copied and modified the f3 implementation and it seems to be working.
Co-authored-by: Jaap Prickartz <jaap@tetra.nl>
1453: stm32 uart: Fix error flag handling for blocking operations r=Dirbaio a=timokroeger
Clear and report the error flags one by one and pop the data byte only after all error flags were handled.
For v1/v2 we emulate the v3/v4 behaviour by buffering the status register because a read to the data register clears all flags at once which means we might loose all but the first error.
Only tested on stm32f3 discovery board with loopback. Let‘s see what CI says for the other families.
Fixes#1452
Co-authored-by: Timo Kröger <timokroeger93@gmail.com>
Clear and report the error flags one by one and pop the data byte only
after all error flags were handled.
For v1/v2 we emulate the v3/v4 behaviour by buffering the status
register because a read to the data register clears all flags at once
which means we might loose all but the first error.
Mode was being set to 2 (PM2_POWERSAVE_MODE), should be
0 (NO_POWERSAVE_MODE). Setting None mode failed with a panic:
85.707099 DEBUG set pm2_sleep_ret = [00, 00, 00, 00]
└─ cyw43::control::{impl#0}::set_iovar_v::{async_fn#0} @ cyw43/src/fmt.rs:127
85.710469 ERROR panicked at 'IOCTL error -29'
1448: rp: don't use SetConfig trait in PWM and PIO. r=Dirbaio a=Dirbaio
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.
bors r+
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
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.
1447: rp/watchdog: fix overflow if period is longer than 4294 seconds. r=Dirbaio a=Dirbaio
bors r+
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
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 <ghaith.oueslati@habemus.com>
Co-authored-by: Ghaith Oueslati <73850124+OueslatiGhaith@users.noreply.github.com>
Co-authored-by: xoviat <xoviat@users.noreply.github.com>
1436: rp: Clock configuration r=CBJamo a=CBJamo
Draft of a more complete clock config for the 2040.
I also extended and made public the clk_<name>_freq functions. I know at least the ws2812 pio example would like to get the sys clock at runtime rather than just using a constant. I suspect most pio-based peripherals will want access to the clocks.
Open questions:
1. Best way to handle the 3 external clock frequencies. I think the XIN (aka crystal) freq should just be set by the init function then never changed, though if it's an external clock that could change? I'm not sure anyone would ever want to do that but maybe it should be handled just in case? The other two should probably be set by the application.
2. Better estimation of ROSC frequency. Right now it's really just a lookup table of the speed from the single sample I did this testing on, and only uses the frequency range and div, drive strength is ignored.
3. Probably some kind of warning should be generated if the random bit from the rosc won't be useful, not sure how to do that.
4. Should clocks only be allowed to be configured at init, or should they be modifiable at runtime? For example, switching the RTC to a clock in pin when a pps source is available.
Bonus feature to support clock output. I only implemented the bare minimum, and only for gpout0. I'm sure there's a clean way with macros to impl all 4 without just copy/paste, but I haven't learned macros yet.
Co-authored-by: Caleb Jamison <caleb@cbjamo.com>
