<M9names[m]>
Please share your code. It's going to be hard to troubleshoot your issues without knowing what you're doing.
cinemaSundays has joined #rust-embedded
<JamesMunns[m]>
Fwiw, the f030 has a tiny amount of RAM iirc, could be a stack overflow
<M9names[m]>
if you're running with an attached debugger and linking with flip-link you should get a hardfault then, right?
danielb[m] has quit [Quit: Bridge terminating on SIGTERM]
diondokter[m] has quit [Quit: Bridge terminating on SIGTERM]
dirbaio[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
RyanSlawson[m] has quit [Quit: Bridge terminating on SIGTERM]
M9names[m] has quit [Quit: Bridge terminating on SIGTERM]
dngrs[m] has quit [Quit: Bridge terminating on SIGTERM]
JamesMunns[m] has quit [Quit: Bridge terminating on SIGTERM]
thejpster[m] has quit [Quit: Bridge terminating on SIGTERM]
jannic[m] has quit [Quit: Bridge terminating on SIGTERM]
Beregond[m] has quit [Quit: Bridge terminating on SIGTERM]
hjeldin__[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #rust-embedded
M9names[m] has joined #rust-embedded
<M9names[m]>
further advice: same as above. share your project, get better help.
<M9names[m]>
but since you posted enough of your code on discord, here's my build of your code. i used `cargo --doc` and searched for `exception`, and it gave an example usage that compiled just fine, with or without LTO:
<hjeldin__[m]>
it doesn't feel like a stack overflow, but i might be wrong.
<danielb[m]>
I guess embassy incorrectly assumes more comparators than the hardware has?
<danielb[m]>
there are waaaay too many stm32s so mistakes like that can happen
<hjeldin__[m]>
i assume the comparators are declared in _generated.rs?
<danielb[m]>
I'll admit I have no idea about specifics
<hjeldin__[m]>
on the bright side i just realized i didn't need to specify a waveform, i only needed to enable the channel to drive the pwm output. so my issue is fixed now, thank you very much!
<bogdan[m]>
I'm also keeping each clock's frequency in the type system, whic I'm not convinced is a great idea :)
<bogdan[m]>
s/whic/which/
<bogdan[m]>
* I'm also keeping each clock's frequency in the type system, which I'm not convinced is a great idea, but it's necessary when the HfClk is sourced by an External Oscillator (Xo), and so the HAL user needs to declare somehow what frequency the oscillator is providing
<bogdan[m]>
I'd like to add more features to this API, but I need some way of representing it so that I can reason about it, otherwise it will become too complex for me to think about. Any recommendations on how to do that? Have you run into this problem?
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
I know it's probably not what you want to hear, but my recommendation is to not use typestates and const generics 😅
<bogdan[m]>
All opinios are welcomed :)
<dirbaio[m]>
It comes with a few downsides. it makes rustdoc much harder to read, it doesn't allow changing settings based on a condition only known at runtime
<bogdan[m]>
dirbaio[m]: I agree, I've looked at a couple of HALs, and could not -- for the life of me -- figure out what they were doing in some places (where they were using generic types -- GPIO pins, etc)
<bogdan[m]>
So my conclusion was that I should try using them myself to get the hang of it :)
<bogdan[m]>
And maybe find some way of documenting them that makes it easier on people using the HAL
<bogdan[m]>
Related to changes at runtime, I suspect it's possible to handle some of them in the type system as long as the condition has only a few possibilities, otherwise it's not practical
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
<bogdan[m]> "I agree, I've looked at a couple..." <- That could also be considered evidence that those HALs should be simplified a bit 😅
<bogdan[m]>
Yes, but there's also the problem of over-simplifying, where the hardware can do wonderful things but the HAL stops you from doing them because they are too complicated and the developers wanted to "keep it simple"
<bogdan[m]>
Also, Rust usually offers a bunch of safety guarantees but if you simplify the HAL, you're no better than writing it in C/C++
<dirbaio[m]>
You can keep it simple while supporting all hardware features. For example make a plain old clock config struct, then check at runtime that the config makes sense.
<dirbaio[m]>
The typestate/const generics stuff "just" allows you to move this checking from runtime to compile time
<GrantM11235[m]>
As a concrete example, compare the way embassy-stm32 handles gpio vs stm32f1xx_hal
<GrantM11235[m]>
embassy-stm32 is just as useful and safe, but it is a lot more simple
<dirbaio[m]>
For the clock config, you typically set it once at boot time, so runtime errors due to bad config aren't that bad, you fix it and once you got a good config you know for sure that you won't get an error again.
<bogdan[m]>
The reason I'd like the clock constraints encoded in the type system is because you could probably brick a controller if you disable the oscillator that sources the High Frequency Clock. I'd be nice if my HAL could prevent the user from accidentally doing that
<dirbaio[m]>
You can still check it, just at runtime.
<bogdan[m]>
Thant's the backup plan :)
<bogdan[m]>
s/Thant/That/
Makarov has quit [Ping timeout: 240 seconds]
Makarov has joined #rust-embedded
Makarov32 has joined #rust-embedded
Makarov has quit [Ping timeout: 240 seconds]
Makarov32 has quit [Ping timeout: 240 seconds]
Makarov32 has joined #rust-embedded
Makarov32 has quit [Ping timeout: 240 seconds]
Makarov32 has joined #rust-embedded
Makarov32 has quit [Quit: Client closed]
Makarov32 has joined #rust-embedded
<bogdan[m]>
Ok, I'm tempted to agree with dirbaio in that it's better to pay the penalty of runtime checks than to use the type system to ensure correct initialization of peripherals. The const generics tend to creep into everything and make code _really_ hard to read
<bogdan[m]>
* correct initialization/configuration of
<bogdan[m]>
* correct initialization/configuration of, * and make the code _really_
<bogdan[m]>
* correct initialization/configuration of, * and make the code _really_, * to read and verbose
<dirbaio[m]>
keep in mind the compiler is pretty good at inlining things and then removing the runtime checks because they can't be hit, so often there's no cost :)
Makarov32 has quit [Ping timeout: 240 seconds]
<bogdan[m]>
also, when they are hit, the error messages can be more informative than type state compile errors