<re_irc>
<@john_socha:matrix.org> As I understand, this implements the trait `Output<OpenDrain>`. How would I pass that to a function? I'm new to Rust, so not sure if this is lack of Rust knowledge, or if this is lack of hal knowledge.
<re_irc>
<@henrik_alser:matrix.org> john_socha: Do you mean what the function signature would look like?
<re_irc>
<@grantm11235:matrix.org> The `into_open_drain_output` function returns the *type* `stm32f1xx_hal::gpio::gpioc::PC7<Output<OpenDrain>>`, which implements the `embedded_hal::blocking::digital::OutputPin` trait
<re_irc>
<@john_socha:matrix.org> Thanks Grant. Let me try that.
<re_irc>
<@grantm11235:matrix.org> You can write a function that takes `stm32f1xx_hal::gpio::gpioc::PC7<Output<OpenDrain>>` or you can write a generic function that can take anything that implements the `OutputPin` trait
emerent has quit [Read error: Connection reset by peer]
<re_irc>
<@john_socha:matrix.org> I'm trying to make it so it can take different pins rather than a specific pin. This is what I tried:
<re_irc>
<@john_socha:matrix.org> error[E0277]: the size for values of type `(dyn embedded_hal::digital::v2::InputPin<Error = Infallible> + 'static)` cannot be known at compilation time
<re_irc>
<@grantm11235:matrix.org> But because that is a trait not a type, you can't just put it in the function signature like that
<re_irc>
<@grantm11235:matrix.org> GrantM11235: The `<P>` is how you declare a generic type
<re_irc>
<@john_socha:matrix.org> Yea, I'm coming from the world of interfaces, assuming I can use a trait as an interface like I would in C++ or a higher-level language like C#.
<re_irc>
<@john_socha:matrix.org> GrantM11235: I've tried to figure out what the second where, or what the syntax should be. When I use exactly what you have above, I get:
<re_irc>
<@john_socha:matrix.org> error: expected one of `!` or `::`, found `:`
<re_irc>
<@osten_music:matrix.org> Hey is there an example for the stm32-rs to adjust the startup code so that I can initialize variables in RAM sections?
fabic_ has quit [Ping timeout: 252 seconds]
<re_irc>
<@marcuss2:tedomum.net> john_socha: Its closer to a concept in C++20
<re_irc>
<@marcuss2:tedomum.net> The extra features over a traditional interface is default implementation based on other methods
<re_irc>
<@marcuss2:tedomum.net> And the fact that you can statically require a structure to implement some interface, negating the need late binding
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 268 seconds]
<re_irc>
<@adamgreig:matrix.org> john_socha: you can also use trait objects, which will be more like using an interface in c++ - it does dynamic dispatch at runtime using a vtable, whereas making the function generic over P monomorphises at compile-time, e.g.:...
<re_irc>
<@adamgreig:matrix.org> (basically the difference between `fn foo<T: InputPin>(x: &T)` and `fn foo(x: &dyn InputPin)`)
rjframe has joined #rust-embedded
fabic_ has joined #rust-embedded
rjframe has quit [Remote host closed the connection]
rjframe has joined #rust-embedded
tokomak has quit [Ping timeout: 250 seconds]
rjframe has quit [Ping timeout: 268 seconds]
starblue1 has quit [Ping timeout: 245 seconds]
starblue1 has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> I always wondered why the pin: OutputPin doesn't work. I understand there are reasons, but it would be a nicer API
<re_irc>
<@firefrommoonlight:matrix.org> It makes refactoring a pain
fabic_ has quit [Ping timeout: 258 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> @agg - that looks like nicer syntax, but it sounds like there are downsides?
<re_irc>
<@firefrommoonlight:matrix.org> Eg the normal trait syntax creates throwaway symbols, and adds additional syntax not normally present
<re_irc>
<@firefrommoonlight:matrix.org> It does so in a way that adds no useful information from the user's perspective
<re_irc>
<@firefrommoonlight:matrix.org> Ie syntactic noise and clutter
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@mathias_koch:matrix.org> What are today's options for debugging stack overflows? I cannot understand what hugs all my stack, and i can't seem to make any of japarics stack-size tools work with a recent compiler version?
<re_irc>
<@dirbaio:matrix.org> The stack-sizes should work, I used it a few weeks ago
<re_irc>
<@firefrommoonlight:matrix.org> Uh.... Comment out lines of code or add empty loops at diff places until it works???
<re_irc>
<@firefrommoonlight:matrix.org> (I am also curious)
<re_irc>
<@firefrommoonlight:matrix.org> Man, I'm really considering RTIC for my next project. I think it would be just be syntactic changes from my current flow. I'm adapting a bluetooth example that uses RTIC, and it's a 1:1 translation to the Mutex-based approach I'm using
<re_irc>
<@firefrommoonlight:matrix.org> The RTIC syntax looks well-designed for this pattern, and is more elegant. Although it has all the caveats DSLs do. Then again, the macros I use are a DSL too
<re_irc>
<@dirbaio:matrix.org> Yeah I saw that too, iirc it was that I didn't do the linker script thing correctly
<re_irc>
<@mathias_koch:matrix.org> The additional sections to keep the .stack-sizes? I thought i did that 🤔
<re_irc>
<@dirbaio:matrix.org> 🤔
<re_irc>
<@dirbaio:matrix.org> I'm afk, can try it again later and report back if you want
<re_irc>
<@dirbaio:matrix.org> But it did definitely work
<re_irc>
<@mathias_koch:matrix.org> But knowing that you had it working on recent compiler versions, makes me a bit more hopeful! I'll go back and try again 👍
<re_irc>
<@dirbaio:matrix.org> It was on small embassy examples. Maybe it's broken on some edge case that only happens in bigger / more complex bins dunno
<re_irc>
<@mathias_koch:matrix.org> I'll give it a go! Thanks
<re_irc>
<@firefrommoonlight:matrix.org> RTIC question, where my 1:1 mapping fails: What do `tasks` that aren't associated with an interrupt do? Eg:
<re_irc>
<@thalesfragoso:matrix.org> firefrommoonlight: One is a trait and the other is a type, and functions take types, you can use `impl Trait` as a way to use generics in functions arguments
<re_irc>
<@thalesfragoso:matrix.org> firefrommoonlight: Iirc you need to give RTIC interrupts to use tasks, since they're dispatched through interrupts
<re_irc>
<@thalesfragoso:matrix.org> If you don't bind to a specific interrupt you still need to provide one interrupt per task priority
<re_irc>
<@bradleyharden:matrix.org> firefrommoonlight, the search term for tasks not bound to an interrupt is software tasks. As mentioned, each priority level must have an associated interrupt that is responsible for dispatching software tasks.
<re_irc>
<@bradleyharden:matrix.org> By the way, you might consider working from v0.6alpha5 rather than v0.5. I think v0.6 is nearing release, and there are a lot of nice features and upgrades to be had
<re_irc>
<@bradleyharden:matrix.org> For instance, you can spawn software tasks from anywhere, rather than having to enumerate which tasks will be spawned from which other tasks
<re_irc>
<@bradleyharden:matrix.org> The resource syntax is also better.
<re_irc>
<@bradleyharden:matrix.org> Oh, and declaring which interrupts are used for software tasks is also way better.
<re_irc>
<@firefrommoonlight:matrix.org> Thank you for the clarifications and info. I'll go with `impl Trait` from here on. I had memories of trying before and it not working, but I evidently was doing something else wrong
<re_irc>
<@firefrommoonlight:matrix.org> In this case, those functions I was copying from RTIC were called in the idle loop, eg:
<re_irc>
<@firefrommoonlight:matrix.org> for a task wrapping a `setup` function. I'm assuming the caller is where the interrupt context comes from? Or in this case, the main loop context?
<re_irc>
<@firefrommoonlight:matrix.org> That software tasks link is v helpful
<re_irc>
<@thalesfragoso:matrix.org> firefrommoonlight: It has its downsides too, namely no turbofish
<re_irc>
<@firefrommoonlight:matrix.org> From that link, it appears the software tasks are more nuanced than my mapping. Eg with priorities
<re_irc>
<@firefrommoonlight:matrix.org> The <T: OutputPin> syntax isn't too bad - I was confused about why the simpler variant wasn't used instead since it seems to be neater from an API perspective, but that's idealistic
<cr1901>
It would've been a semi-recent RFC/issue (2021), but I can't find it for the life of me
<cr1901>
In any case, I'm giving up on this. Wish it was easier to reach Ralf than email or Zulip
<re_irc>
<@firefrommoonlight:matrix.org> Link is broken
<re_irc>
<@thalesfragoso:matrix.org> Not even sure if UnsafeCell really relax the noalias stuff
<re_irc>
<@thalesfragoso:matrix.org> Iirc there are talks to have a type that did that, they even did that for !Unpin types when they really enabled the noalias on LLVM (it last like a week)
<re_irc>
<@thalesfragoso:matrix.org> If you get a `&mut T` from an `UnsafeCell` you still invalidate all others references to it, also raw pointers
<re_irc>
<@bradleyharden:matrix.org> cr1901 it definitely rings a bell. I'm pretty sure it was a proposal to fix the Pin soundness issue
<re_irc>
<@bradleyharden:matrix.org> But I can't find it on a quick search