27 Jan 2023 |
dirbaio | opt-level=3 tends to generate bigger code, which is not the right tradeoff with the tiny flash caches in mcus | 22:48:17 |
dirbaio | oh and of course enable the flash cache | 22:49:12 |
dirbaio | something like
pac::FLASH.acr().modify(|w| {
w.set_dcen(true);
w.set_icen(true);
w.set_prften(true);
});
| 22:49:22 |
dirbaio | (assuming the f0 has one) | 22:49:35 |
dirbaio | overflow checks sounds like it's not inlining something that would allow optimizing it away. Perhaps we're missing some #[inline] in embassy-stm32. Try building with LTO, which should allow inlining regardless. | 22:50:44 |
| Slushee joined the room. | 23:02:35 |
Josh Mcguigan | Thanks for the tips! I've noted them down and I'll give them a shot this weekend sometime. In the meantime, I am successfully/smoothly controlling the brushless motor based on back emf now! | 23:21:57 |
dirbaio | it'd be cool if RCC default was "as fast as possible" | 23:23:03 |
dirbaio | instead of some silly default like 8mhz... | 23:23:08 |
Josh Mcguigan | yeah agreed, is there some technical reason that is hard to do ? | 23:23:23 |
dirbaio | * instead of some silly slow freq like 8mhz... | 23:23:26 |
dirbaio | it's just hard, the limits and what config to use to reach them vary a lot between chips | 23:23:54 |
dirbaio | and I think sometimes HSE is mandatory to go fast? or to have good precision for stuff like USB | 23:24:46 |
dirbaio | and you don't know which HSE is fitted on the board if any, so guessing will cause things to not work at all | 23:25:13 |
Josh Mcguigan | what actually happens when I configure rcc to use 48mhz rather than 8? does the controller just start looking at a different clock source, or does it physically/electrically modify a clock source to meet the configured speed, or something else? | 23:29:02 |
dirbaio | a lot of stuff 😅 | 23:29:34 |
dirbaio | read the RCC chapter of the reference manual for the full stuff | 23:30:11 |
dirbaio | the tldr is:
- the hardware has a few clock sources (HSI = on-chip oscillator, typically 8mhz or 16mhz. HSE = external quartz crystal, frequency is whatever you mount on the PCB)
- it can multiply/divide using some black magic (the PLL) to get faster clocks
- it can then choose one of these for several clocks (system clock, periphral clocks...)
| 23:32:42 |
dirbaio | rcc defaults to HSI unless you set rcc.hse=Some(..) | 23:33:10 |
dirbaio | so that's doing something like grabbing HSI then configuring the PLL to multiply by 6, then use that as sysclk | 23:33:43 |
Josh Mcguigan | cool, I've gotta run for now, but thanks again for the help! | 23:35:55 |
dirbaio | that's what I do when I have to do RCC stuff as well | 23:36:26 |
dirbaio | run | 23:36:27 |
dirbaio | 😂 | 23:36:28 |
dirbaio | run away | 23:36:50 |
iot49 | Is is possible to run the embassy-executor in a standard *nix (I use macos) enveronment? Would be mostly for developing stuff that does not do chip-level io. | 23:47:17 |
dirbaio | yup! https://github.com/embassy-rs/embassy/tree/master/examples/std/src/bin | 23:48:05 |
28 Jan 2023 |
iot49 | Thanks, this worked. But upon going back to my nrf52840 repo (in a different directory), I suddenly get tons of compiler errors about std , even though my main includes #![no_std] as the first line (I also have not changed it since compiling another app for x86).
error[E0463]: can't find crate for `std`
|
= note: the `thumbv7em-none-eabihf` target may not support the standard library
= note: `std` is required by `critical_section` because it does not declare `#![no_std]`
= help: consider building the standard library from source with `cargo build -Zbuild-std`
I feel like an idiot. But this is really weird.
| 02:20:35 |
iot49 | I did find the issue. | 02:46:34 |
9names | what was it? | 02:48:42 |