ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
causal has joined #rust-embedded
causal has quit [Ping timeout: 252 seconds]
dc740 has quit [Remote host closed the connection]
causal has joined #rust-embedded
Darius has quit [Quit: Bye]
Darius has joined #rust-embedded
<re_irc> < (@firefrommoonlight:matrix.org)> Cleaning up those inconsistent STM IRQ names would be a great place for an abstraction
<re_irc> < (@firefrommoonlight:matrix.org)> That in conjunction with my feature-gate request would clear up this little mess that's all over one of my programs:
<re_irc> /// If this triggers, it means we've received no radio control signals for a significant
<re_irc> /// (Note that this is for TIM17 on both variants)
<re_irc> ///period of time; we treat this as a lost-link situation.
<re_irc> < (@firefrommoonlight:matrix.org)> Point #1: Thanks to ST's naming convention, the 2 names for TIM17's IRQ are quite different on the 2 MCU variants in question. The G4 one is actually misleading
<re_irc> < (@firefrommoonlight:matrix.org)> Point #2: Whenever I want to change which MCU I'm compiling for, I have to swap the commented-out line for each ISR! Quite a pain
<re_irc> < (@firefrommoonlight:matrix.org)> Since I can't feature-gate them
<re_irc> < (@dirbaio:matrix.org)> huh there's a chip where TIM17 is on TIM1_TRG_COM?
<re_irc> < (@dirbaio:matrix.org)> which one is it?
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
<re_irc> < (@laizy:matrix.org)> Hi, I want compile a program to no_std, there is a dependent crate common_types, which support no_std.
<re_irc> and I use the following in Cargo.toml:
<re_irc> common-types = { path = "../types", default-features = false} // disable common-types's "std" feature.
<re_irc> but compiles failed, so how to let the cargo or rustc to print some debug info to figure out why the std is included?
<re_irc> < (@orclev:matrix.org)> It's complaining that there's no panic handler defined. Typically you'll import one of the crates that defines a panic handler for you such as E.G. https://crates.io/crates/panic-halt, although it's also possible to define your own panic handler, it's fairly minimal.
<re_irc> < (@orclev:matrix.org)> also did you declare that it was no-std in the actual lib.rs? You should have "#![no_std]" in there, it isn't enough just to not use the std library
<re_irc> < (@laizy:matrix.org)> : no, I defined one, it is complaining my definition is a duplicate lang item. I want find out why std's panic handler is included
<re_irc> < (@orclev:matrix.org)> it seems to be under the impression that common-types needs it. I'd bet that "#![no_std]" isn't defined in it.
<re_irc> < (@laizy:matrix.org)> : common-types can be used in no_std:
<re_irc> #![cfg_attr(not(feature = "std"), no_std)]
<re_irc> < (@orclev:matrix.org)> hmm, does it have any dependencies?
<re_irc> < (@laizy:matrix.org)> : yes, it does.
<re_irc> < (@orclev:matrix.org)> check if one of its dependencies is pulling in std then. If that's not it I'm not really sure.
<re_irc> < (@laizy:matrix.org)> I have checked all dependencies support no_std, and all use "default-features = false" in common-types's Cargo.toml.
<re_irc> < (@firefrommoonlight:matrix.org)> : At least some G4 variants
<re_irc> < (@firefrommoonlight:matrix.org)> * STM32G4
<re_irc> < (@firefrommoonlight:matrix.org)> It seems in general, TIM1 triggers different IRQs depending on the interrupt, while the other timers put all their interrupts on one IRQ.
<re_irc> < (@firefrommoonlight:matrix.org)> * to an extent, TIM1 and TIM8 (advanced ctrl timers) trigger
m5zs7k has quit [Ping timeout: 272 seconds]
m5zs7k has joined #rust-embedded
explore has joined #rust-embedded
<re_irc> < (@korken89:matrix.org)> : Amazing :D :D :D
<re_irc> < (@korken89:matrix.org)> I think we are something on the tracks here!
hwj has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
hwj has quit [Ping timeout: 252 seconds]
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> < (@thejpster:matrix.org)> Are there any mastodon instances with the same kind of moderation rules that we enforce around here? Or anything generally good for rust-embedded people to join?
<re_irc> < (@firefrommoonlight:matrix.org)> Also looking for recommendations of alternative mat clients. Element is a pig
<re_irc> < (@dirbaio:matrix.org)> : well I'm still debating whether that's too cursed for real use or not
<re_irc> < (@dirbaio:matrix.org)> also, I think if you already write this macro, you don't need the second macro layer below
<re_irc> < (@dirbaio:matrix.org)> * the HAL already has
<re_irc> < (@dirbaio:matrix.org)> instead of having a trait that certifies "irq X has been wired up to handler for function Y"
<re_irc> < (@dirbaio:matrix.org)> you can have a trait that certifies "all irqs for peripheral P have been wired correctly"
<re_irc> < (@korken89:matrix.org)> Indeed, that does however put all the requirements on the HAL author and I think it's only valid to do that for really complex things
<re_irc> < (@korken89:matrix.org)> Else you'd just copy the register call from the example
<re_irc> < (@korken89:matrix.org)> Because I really do not want the ecosystem to bifurcate on different ways to do IRQ registration that after a while become incompatible
<re_irc> < (@korken89:matrix.org)> I want that at least everything builds on the same foundation to align HAL impls in this regard
<re_irc> < (@korken89:matrix.org)> Like with code, which ever HAL you work in - all handles interrupts using the same system
<re_irc> < (@korken89:matrix.org)> Which means no mental overhead
<re_irc> < (@korken89:matrix.org)> That's at least my view :)
<re_irc> < (@korken89:matrix.org)> Like with code style being the same, which ever HAL you work in all handles interrupts using the same system
<re_irc> < (@korken89:matrix.org)> And if some HAL requires a macro because of a really complex peripheral, I'd say that's the exception
<re_irc> < (@korken89:matrix.org)> +- not the norm
<re_irc> < (@dirbaio:matrix.org)> yea
<re_irc> < (@dirbaio:matrix.org)> the problem with one-size-fits-all is it hurts usability of the simpler chips
<re_irc> < (@dirbaio:matrix.org)> like, for nrf it could be "register_interrupts!(Irqs, TIMER1, UARTE0)"
<re_irc> < (@dirbaio:matrix.org)> you don't need the "->" like in stm32
causal has quit [Quit: WeeChat 3.7.1]
<re_irc> < (@korken89:matrix.org)> Is the "->" that much mental overhead?
<re_irc> < (@korken89:matrix.org)> The user will copy it in the end unless writing their own HAL
<re_irc> < (@korken89:matrix.org)> I don't see and difference in copying that vs copying a special macro from a HAL
<re_irc> < (@korken89:matrix.org)> And if the HAL wants its own it is still fine, just have the final step expand to the "cortex_m_interrupt::register_interrupt!()" call
<re_irc> < (@korken89:matrix.org)> Then all APIs will stay the same
<re_irc> < (@dirbaio:matrix.org)> the API is what the user ends up using
<re_irc> < (@dirbaio:matrix.org)> which will be this higher-level macro, not "cortex-m-interrupt"
<re_irc> < (@dirbaio:matrix.org)> so the API will still be different
<re_irc> < (@dirbaio:matrix.org)> so I'm not sure what we gain by making it go through "cortex-m-interrupt" internally
<re_irc> < (@korken89:matrix.org)> The HAL APIs would converge
<re_irc> < (@dirbaio:matrix.org)> no, the HAL API would end up being the "hal::register_interrupts_automatically!" macro. Not "cortex_m_interrupt::register_interrupts!"
<re_irc> < (@dirbaio:matrix.org)> "cortex_m_interrupt::register_interrupts!" would end up being an implementation detail
<re_irc> < (@korken89:matrix.org)> Exactly
<re_irc> < (@korken89:matrix.org)> Which works make HALs have the same registration API
<re_irc> < (@dirbaio:matrix.org)> and "hal::register_interrupts_automatically!" would be different depending on the particular chip's needs
<re_irc> < (@korken89:matrix.org)> Maybe I'm delusional on that this kind of consistency is needed
<re_irc> < (@korken89:matrix.org)> As long as the ecosystem does not come up with 9001 different ways to do this I consider it a success
<re_irc> < (@korken89:matrix.org)> Or rather, as long as each HAL does not need to reinvent this is the important factor for async HALs to take off, as not every maintainer wants to figure it out
<re_irc> < (@korken89:matrix.org)> What is then instead the way to make HAL authors aware on how to do it?
<re_irc> < (@korken89:matrix.org)> Because the end aim is for async HALs to take off
hwj has joined #rust-embedded
<re_irc> < (@dirbaio:matrix.org)> dunno
<re_irc> < (@dirbaio:matrix.org)> a blog post? :D
<re_irc> < (@korken89:matrix.org)> Hmm
hwj has quit [Remote host closed the connection]
<re_irc> < (@korken89:matrix.org)> I quite like API enforcement as it's easy to copy and the compiler with keep you on track
hwj has joined #rust-embedded
<re_irc> < (@dirbaio:matrix.org)> if the HAL is writing its own macro on top of "cortex-m-interrupt" you're not enforcing anything
<re_irc> < (@korken89:matrix.org)> It's there some other way to get the API enforcement without the macro?
<re_irc> < (@dirbaio:matrix.org)> dunno
<re_irc> < (@korken89:matrix.org)> : You care enforcing it via the traits
<re_irc> < (@korken89:matrix.org)> * are
<re_irc> < (@dirbaio:matrix.org)> uh
<re_irc> < (@dirbaio:matrix.org)> that's only part of the API, and it's the part the user won't touch directly
<re_irc> < (@dirbaio:matrix.org)> the problem with the macro (the way I wrote it, at least) needs to contain the irq names/maps
<re_irc> < (@dirbaio:matrix.org)> so you can't put it in a shared crate
<re_irc> < (@korken89:matrix.org)> I guess that is enough if the HAL implements the traits manually
<re_irc> < (@dirbaio:matrix.org)> the problem with the macro (the way I wrote it, at least) is that it needs to contain the irq names/maps
<re_irc> < (@korken89:matrix.org)> : Yeah, i think it's easy enough for the user now
<re_irc> < (@korken89:matrix.org)> I'm really only thinking about HAL maintainers now
<re_irc> < (@korken89:matrix.org)> If the user will use the magic macro or the the proposed macro is both fine IMO
<re_irc> < (@korken89:matrix.org)> The end result of all this needs to cater to both the user and maintainer for it to be useful and easy to maintain
<re_irc> < (@korken89:matrix.org)> A blog could disseminate the info but I feel it may go forgotten
<re_irc> < (@korken89:matrix.org)> Maybe I'm worried over nothing
hwj has quit [Ping timeout: 246 seconds]
<re_irc> < (@dirbaio:matrix.org)> honestly i'd say just let HAL authors do whatever
<re_irc> < (@dirbaio:matrix.org)> we don't even know whether this approach is the right one yet
<re_irc> < (@korken89:matrix.org)> I don't think that's a good approach to make async HALs take off, i think we need to make a spoon fed guide or template that maintainers can at least copy
<re_irc> < (@dirbaio:matrix.org)> Rust embedded ecosystem has quite a few examples of: someone comes up with an idea of how to do something, claims "this is THE way you do things, all HAL authors do it this way"
<re_irc> < (@dirbaio:matrix.org)> even in official REWG materials https://docs.rust-embedded.org/book/design-patterns/hal/checklist.html
<re_irc> < (@dirbaio:matrix.org)> and then all HALs mindlessly copy that
<re_irc> < (@dirbaio:matrix.org)> and many of these things it's far from settled whether that's THE way to do it or there are better ones
<re_irc> < (@korken89:matrix.org)> Seems sane to me, someone comes up with something good and we use it until something better comes along
<re_irc> < (@dirbaio:matrix.org)> Out of the 8 items in that checklist, I disagree with 5 :D
<re_irc> < (@korken89:matrix.org)> Only by first making it and having people do it would the experience be gained to decide if it was good enough
<re_irc> < (@dirbaio:matrix.org)> sure
<re_irc> < (@korken89:matrix.org)> Sounds like good input to maybe change the list :)
<re_irc> < (@korken89:matrix.org)> Experience has been gained and opinions formed, then it's time for an overhaul :)
<re_irc> < (@dirbaio:matrix.org)> I've already tried, turns out it's controversial
<re_irc> < (@korken89:matrix.org)> getting of track though
<re_irc> < (@dirbaio:matrix.org)> so I've stopped trying
<re_irc> < (@dirbaio:matrix.org)> I just implement my ideas in embassy HALs and hope other HAL maintainers will copy them if they think they're good... 🤷
<re_irc> < (@dirbaio:matrix.org)> anyway
<re_irc> < (@dirbaio:matrix.org)> my point is
<re_irc> < (@dirbaio:matrix.org)> why not _first_ implement in HALs, and _later_ try to standardize / extract a shared crate?
<re_irc> < (@korken89:matrix.org)> Maybe my view of a more unified way of doing things is not the way then
<re_irc> < (@dirbaio:matrix.org)> HALs already differ wildly in many other design decisions
<re_irc> < (@dirbaio:matrix.org)> different maintainers with different opinions/priorities/usecases
<re_irc> < (@korken89:matrix.org)> The core idea is the 2 traits, the rest is only to help implement them
<re_irc> < (@korken89:matrix.org)> I'v5e of the traits can be removed if everything is done in the HAL
<re_irc> < (@korken89:matrix.org)> * One
<re_irc> < (@korken89:matrix.org)> Should be fine as well
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
hwj has joined #rust-embedded
hwj has quit [Ping timeout: 260 seconds]
<re_irc> < (@firefrommoonlight:matrix.org)> Write firmware / build devices: The strengths and weaknesses of the underlying libs will reveal themselves
<re_irc> < (@firefrommoonlight:matrix.org)> From a number of different use cases, patterns will emerge, since various use cases have areas of overlap and differences
<re_irc> <rjmp> I'm curious, would "HAL drivers which take ownership of a RegisterBlock should make that register block available publicly so that users can extend the driver" be considered controversial here? Often peripherals have functionality not exposed by a driver, but which can be added in a wrapper with a few direct register accesses while still taking advantage of other parts of the driver (clock setup, configuration, etc). One...
<re_irc> ... can steal the register block, but this feels worse to me, and in cases of multiple identical peripherals (e.g. USART1, USART2) becomes more complicated.
<re_irc> < (@firefrommoonlight:matrix.org)> I do
<re_irc> < (@firefrommoonlight:matrix.org)> I usually don't use it, but it's an escape hatch when I realize I need functionality in a program HAL doesn't have
<re_irc> < (@firefrommoonlight:matrix.org)> If there's a simple way to abstract it in HAL, I add the HAL fn
<re_irc> < (@adamgreig:matrix.org)> I guess the problem is that once the user can access the registerblock, the hal can't control any invariants around the configuration, so anything could break or the hal has to reconfigure stuff all the time to make sure it's in the right state
<re_irc> < (@adamgreig:matrix.org)> so the function to access the registerblock would probably be "unsafe", at which point you may as well steal it
<re_irc> < (@jamesmunns:beeper.com)> yeah, I'd say the escape hatch should _probably_ be unsafe
<re_irc> < (@firefrommoonlight:matrix.org)> If it's something weird (eg SVD/PAC omission for certain variants) or I don't see an obv way to make a good HAL API, I leave the workaround in user code
<re_irc> < (@firefrommoonlight:matrix.org)> Specifically, most HAL periphs structs expose a public 'regs' field
<re_irc> <rjmp> Often the good long-term solution is to improve the HAL driver, but for most users forking and upstreaming these changes is a bit of a barrier. At least for short term.
<re_irc> < (@firefrommoonlight:matrix.org)> So, not a primary API, but an escape hatch for life's lemons, which are always about
<re_irc> <rjmp> The public "regs" is what I mean. Maybe most do, and I'm just using some that don't!
<re_irc> < (@firefrommoonlight:matrix.org)> I see the art for an unsafe getter method instead of pub field. Will consider it
<re_irc> < (@firefrommoonlight:matrix.org)> * arg
<re_irc> < (@dirbaio:matrix.org)> i'm not a fan of adding a feature to a HAL whose purpose is to make it easier to _not_ upstream stuff :D
<re_irc> < (@firefrommoonlight:matrix.org)> But, often when I have to use the regs field in program, it's a smell HAL is missing functionality
<re_irc> <rjmp> Definitely you can break the driver functionality if you access registers around it. Personally, I would consider this fine and understood. I wouldn't even require an unsafe, myself.
<re_irc> < (@firefrommoonlight:matrix.org)> Ok screw it. Will switch to the unsafe method. I like the idea
<re_irc> < (@firefrommoonlight:matrix.org)> And make the field private
<re_irc> < (@firefrommoonlight:matrix.org)> * Btw, I started with not having this functionality, but gradually added it to various modules as needs arose in firmware
<re_irc> < (@adamgreig:matrix.org)> rjmp: yea, I guess it depends on the driver, but I think you'd often have unchecked preconditions on use of the raw register block to prevent data races, in which case it "should" be unsafe
<re_irc> < (@firefrommoonlight:matrix.org)> I think mainly the unsafe is a warning that what you do with the refs could conflict with periph config etc expected by the struct
<re_irc> < (@firefrommoonlight:matrix.org)> It's just a "hey look here when mysterious breaks happen dummy"
<re_irc> < (@firefrommoonlight:matrix.org)> I think mainly the unsafe is a warning that what you do with the regs could conflict with periph config etc expected by the struct
<re_irc> <rjmp> The more unsafe proliferation there is though, the less useful of a "look here" signal it becomes!
<re_irc> < (@firefrommoonlight:matrix.org)> Yea true
<re_irc> < (@firefrommoonlight:matrix.org)> But, you just witnessed me change my mind and API here based on a good idea from :
<re_irc> <rjmp> I feel like I don't always understand the ways rust hals protect register access. To me, it should be unsafe if there's a race condition. But if I own an object owning the register block, I think that's not the case?
<re_irc> < (@firefrommoonlight:matrix.org)> I buy that too
<re_irc> < (@firefrommoonlight:matrix.org)> I think the 'unsafe' definition is a bit flexible
<re_irc> < (@firefrommoonlight:matrix.org)> And that's at the core of this
<re_irc> <rjmp> I don't like unsafe to mean "the peripheral might not behave as you want" personally, but it's very subjective for sure
<re_irc> < (@9names:matrix.org)> That in itself is a bit controversial :)
<re_irc> < (@jamesmunns:beeper.com)> It's more that "if the Hal assumes X is always true", and you break that with pac access, it may not perform as intended
<re_irc> < (@dirbaio:matrix.org)> the HAL might be coded in a way where you messing with the peripheral regs causes legit Undefined Behavior in the core though, not just "peripheral doesn't behave properly"
<re_irc> < (@jamesmunns:beeper.com)> (e.g., you broke it's "invariants", which may cause unsafety)
<re_irc> < (@dirbaio:matrix.org)> for example with DMA registers
<re_irc> < (@firefrommoonlight:matrix.org)> So, It's like this - I have designed hardware structs to work a certain way. If you mess with the regs outside this struct 's API, you may break assumptions about state etc. That may be necessary, but the unsafe makes you think twice
<re_irc> < (@firefrommoonlight:matrix.org)> Yra - I have the DMA read/write as unsafe methods too
<re_irc> < (@adamgreig:matrix.org)> yea, that's the only situation where I think the "get the registers directly" should be unsafe, but I wouldn't be surprised if the majority of HAL drivers had that
<re_irc> < (@firefrommoonlight:matrix.org)> rjmp: Completely subjective
<re_irc> < (@adamgreig:matrix.org)> definitely +1 on not making things unsafe just for "be careful with this or the hardware might not do what you expect", though
<re_irc> < (@firefrommoonlight:matrix.org)> Adam - your take on public regs field vs unsafe regs getter?
<re_irc> < (@firefrommoonlight:matrix.org)> I will reconsider
<re_irc> < (@dirbaio:matrix.org)> public field allows the user to _write_ to it which you don't want
<re_irc> <rjmp> Well, I will say, if I found an unsafe regs getters I would not have come here to test the waters. I would just have added another unsafe! So either way of exposing them meets my concern.
hwj has joined #rust-embedded
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #rust-embedded
hwj has quit [Ping timeout: 260 seconds]
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc> < (@adamgreig:matrix.org)> has anyone tried out cortex-m-rt 0.7.2 on their firmware yet? it works for me and hopefully it's basically the same as before but we have completely gotten rid of the prebuilt gcc-assembled external assembly files for global_asm so there's definitely scope for problems
dc740 has joined #rust-embedded
<re_irc> < (@dkhayes117:matrix.org)> : I just tried it in my thesis firmware, build just fine :)