<re_irc>
279: 0003da7d 40 FUNC LOCAL DEFAULT 2 _ZN4core9panicking9panic_fmt17h0d4944b3b3721a92E
<re_irc>
165: 00036c49 56 FUNC LOCAL DEFAULT 2 _ZN4core9panicking13assert_failed17hc4055ee5aec0ae95E
<re_irc>
<Ablu> Peter Hansen: ok. That gives me something to chase after. Thanks :)
<re_irc>
<Ablu> I managed to piece some stuff together: "#[panic_handler]" does provide a "rust_begin_unwind" symbol and not something with panic (https://rustc-dev-guide.rust-lang.org/panic-implementation.html was a good resource). I _do_ see that symbol being added when I add that handler. I also see the symbols with rust mangling in my deps/libcore-fea1cbb5023027af.rlib. Linking that manually makes it work... Now I need to take a step...
<re_irc>
... back and see why this does not work for staticlib...
<re_irc>
<Ablu> Ok. It also works with staticlib if I manually link libcore. I tried this before asking here, but I think I might have accidentially linked in the wrong order.
<re_irc>
<Ablu> So: is it intended that "staticlib" does not link "libcore"? I could see how that makes sense when being in a rust-only world, because probably the final linking into an actual "bin" would provide the symbols? How are other people handling this when linking to C code?
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<Ablu> Apparently I can add:
<re_irc>
crate-type = ["staticlib", "lib"]
<re_irc>
``` In the Cargo.toml next to the `[package]` `crate-type`. That then produces a `.a`. Apparently only setting "staticlib" does not suffice... I will need to look at this with a fresh brain again I think.
<re_irc>
[lib]
<re_irc>
<tr09> Hi, how do I start using https://github.com/nrf-rs/nrf-hal? I tried to copy src/*.rs from examples/ and add it as a dependency but I only managed (by twiddling features in Cargo.toml) to either get an empty .elf or an error about multiple defined memory regions.
<re_irc>
< (@dirbaio:matrix.org)> without those you can get an empty .elf
steew has quit [*.net *.split]
inara has quit [*.net *.split]
ni has quit [*.net *.split]
steew has joined #rust-embedded
ni has joined #rust-embedded
inara has joined #rust-embedded
<re_irc>
<tr09> Oh darn, managed to miss .cargo somehow. thank you very much it works now.
<re_irc>
Although can I specify the "package" to be xxAA in nrf51-hal somehow? Adding
<re_irc>
features = ["xxAA-package", "rt"]```
<re_irc>
complains about “Multiple memory configurations specified”
<re_irc>
<tr09> Oh darn, managed to miss .cargo somehow. thank you very much it works now.
<re_irc>
Although can I specify the "package" to be xxAA in nrf51-hal somehow? Adding
<re_irc>
features = ["xxAA-package", "rt"]
<re_irc>
complains about “Multiple memory configurations specified”
<re_irc>
[dependencies.nrf51-hal]
<re_irc>
<tr09> Oh darn, managed to miss .cargo somehow. thank you very much it works now. Although can I specify the "package" to be xxAA in nrf51-hal somehow? Adding
<re_irc>
[dependencies.nrf51-hal] features = ["xxAA-package", "rt"]
<re_irc>
complains about “Multiple memory configurations specified”
<re_irc>
< (@dirbaio:matrix.org)> ah and what that feature does is generate "memory.x" for you, so if you enable it then you should remove your own "memory.x" and "build.rs"
<re_irc>
<tr09> I see. Seems “cleaner” without memory.x but works nonetheless.
<re_irc>
< (@xiugaze:matrix.org)> Are any of you guys using neovim for embedded rust development? If so I'd love to see how you have your environment set up
<re_irc>
< (@jamesmunns:beeper.com)> I don't, but I think it should work generally the same as for any rust setup? I don't think there's anything particularly special for embedded stuff. There should be Rust Analyzer instructions for neovim, if you aren't already using that.
<re_irc>
< (@nihal.pasham:matrix.org)> Has anyone dabbled with register mapping using device trees i.e. generate register maps from device tree blobs like "svd2rust"
<re_irc>
< (@nihal.pasham:matrix.org)> * in register mapping using device trees i.e. generate register maps from device tree blobs like svd2rust
<re_irc>
< (@nihal.pasham:matrix.org)> I was thinking maybe this would make bare-metal programming easier on more powerful cortex-a and risc-v systems.
<re_irc>
< (@nihal.pasham:matrix.org)> Just wanted to check if this is already being investigated or worked on
<re_irc>
< (@nihal.pasham:matrix.org)> I was thinking maybe this would make bare-metal (or pac) programming easier on more powerful cortex-a and risc-v systems.
<re_irc>
< (@jamesmunns:beeper.com)> I think maaaaybe? tock OS does something like that? I could be remembering totally wrong tho
<re_irc>
< (@jamesmunns:beeper.com)> I'm definitely interested in something like that for Cortex-A/RV64 systems tho. Chips I've used like the Allwinner D1 and imx6ull I think just scraped the datasheets to make an SVD.
<re_irc>
< (@jamesmunns:beeper.com)> looks like no, I might have been thinking back to the old Zinc.rs days
<re_irc>
< (@nihal.pasham:matrix.org)> Yeah, last I checked TockOS has an "aarch64-cpu" crate that provides register level access to arm64 core.
<re_irc>
< (@ryan-summers:matrix.org)> : I do :)
<re_irc>
< (@nihal.pasham:matrix.org)> But I was thinking if device trees (Linux, the various RTOSs) are what everyone uses for hardware discovery, maybe we can use it too
<re_irc>
< (@nihal.pasham:matrix.org)> I already have a device tree blob (DTB) parser and I think crates.io also has a couple of full featured parsers available.
<re_irc>
< (@nihal.pasham:matrix.org)> Maybe all we need is to put together the codegen part
<re_irc>
< (@ryan-summers:matrix.org)> I think the only rust-specific stuff I have set up is the LSP + rust-analyzer though. I don't like tools doing too much for me. And even r-a is somewhat annoying because it runs a compile on each build. For some of my larger projects, builds can take a minute or so, so it completely locks the build folder during that time
<re_irc>
< (@ryan-summers:matrix.org)> * save.
<re_irc>
< (@ryan-summers:matrix.org)> +(I instinictively save files a lot)
<re_irc>
< (@nihal.pasham:matrix.org)> But I was thinking if device trees are what everyone (Linux, the various RTOSs) uses for hardware discovery, maybe we can use it too
a_gent_00 has joined #rust-embedded
a_gent_00 has left #rust-embedded [#rust-embedded]
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> room meeting time again! agenda is https://hackmd.io/29kuxMx6TtWIygBnzu7W2g, please add anything you'd like to announce or discuss and we'll start in ~5min
<re_irc>
< (@dkhayes117:matrix.org)> I've created an RSS website for my new podcast. No content yet, but you can subscribe and be notified when the first episode drops.
<re_irc>
< (@dkhayes117:matrix.org)> I'm beginning to make calls for people who would like to be show guests. If interested, message me :)
<re_irc>
< (@adamgreig:matrix.org)> cool!
<re_irc>
< (@adamgreig:matrix.org)> only quick release announcements this week, riscv 0.10.1 and riscv-rt 0.11.0 out to fix the critical-section impl bug from last week
<re_irc>
< (@adamgreig:matrix.org)> and I think otherwise fairly quiet, I don't have anything new that needs discussing
<cr1901>
I'll have news on an MSP430 project soon (getting AT2XT boards made)...
<re_irc>
< (@adamgreig:matrix.org)> there's still the new PwmPin trait for e-h 1.0 in https://github.com/rust-embedded/embedded-hal/pull/430 where any thoughts would be welcome, especially as the new design hasn't been discussed as much as the first concept which we talked about a bit more here
<re_irc>
< (@therealprof:matrix.org)> Using the time for the final e-h 1.0 push sounds like a good idea, not sure whether all the typical suspects are currently present though. 😉
<re_irc>
< (@grantm11235:matrix.org)> I have a few more minor questions:
<re_irc>
- Is "set_percent" useful enough, or should people just do "set_fraction(percent, 100)"?
<re_irc>
- Are there any other provided methods that we should include? (We can add more later as a non-breaking change)
<re_irc>
- Should we split "get_max_duty" into it's own subtrait?
<re_irc>
< (@adamgreig:matrix.org)> I feel like set_percent is basically zero cost so might as well include it?
<re_irc>
< (@adamgreig:matrix.org)> I guess it's a bit funny because in general the idea is the e-h traits are used by driver authors and not by end application users directly, who can just use whatever convenient methods their HAL provides directly, and are more likely to be the ones wanting set_percent
<re_irc>
< (@adamgreig:matrix.org)> but in practice I guess I wouldn't be surprised if some end application users do/are using the e-h traits, or the hals use them to work out what methods to expose directly anyway, so
<re_irc>
< (@adamgreig:matrix.org)> another thing people want pwmpin for is fixed width pulses for things like actual PWM for driving servos and the like, but I think that's somehow out of scope here because it involves actual time
<re_irc>
< (@almindor:matrix.org)> I wanted to formally apologize for the riscv/riscv-rt release and yank mess, we found out the bug was there and yanked the crate and missed riscv-rt as a dependant having the same issue. Also the whole 0.9+ releases setup was a bit wonky
<re_irc>
< (@adamgreig:matrix.org)> thank you for getting the fixed releases out so fast :)
<re_irc>
< (@adamgreig:matrix.org)> : maybe worth linking your pr on the e-h pr? or perhaps even a separate pr on e-h to replace the current one
<re_irc>
< (@adamgreig:matrix.org)> I think overall your current version looks good and seems popular, be good to get it into an alpha release soon
<re_irc>
< (@adamgreig:matrix.org)> why would you split get_max_duty?
<re_irc>
< (@jannic:matrix.org)> : I like using e-h traits even in end applications, because it makes porting them easier.
<re_irc>
< (@grantm11235:matrix.org)> I'm not sure. It would be possible to have a blanket "GetMaxDuty" impl for "&T" as well as "&mut T", but I don't know if that is actually useful
<re_irc>
< (@grantm11235:matrix.org)> I thought of it because the current trait is called "SetDuty"
<re_irc>
< (@grantm11235:matrix.org)> I can't think of any other use for a "GetMaxDuty" trait other than using it with "SetDuty", can you?
<re_irc>
< (@adamgreig:matrix.org)> hmm, I see what you mean
<re_irc>
< (@adamgreig:matrix.org)> I wonder if SetDuty is the best name for it
<re_irc>
< (@adamgreig:matrix.org)> I suppose it does make sense, setting duty is what it's doing :P
<re_irc>
< (@adamgreig:matrix.org)> the other uses for pwm would be like SetWidth which won't care about "max duty"
<re_irc>
< (@adamgreig:matrix.org)> and I guess SetFrequency which, likewised
<re_irc>
< (@adamgreig:matrix.org)> * likewise
<re_irc>
< (@eldruin:matrix.org)> those would be time-dependent so it would be good to put them in a separate trait
<re_irc>
< (@adamgreig:matrix.org)> yea
<re_irc>
< (@adamgreig:matrix.org)> so like, pwm.rs can contain SetDuty, SetWidth, SetFrequency traits, eventually
<re_irc>
< (@eldruin:matrix.org)> ah I understood you now
<re_irc>
< (@eldruin:matrix.org)> yeah exactly
<re_irc>
< (@grantm11235:matrix.org)> But would any other traits need a "get_max_duty" method? If so, we should make it a separate subtrait. If not, probably just keep it in SetDuty
<re_irc>
< (@eldruin:matrix.org)> not sure, probably not
<re_irc>
< (@adamgreig:matrix.org)> I don't think so, at least for width and freq
<re_irc>
< (@adamgreig:matrix.org)> they'll have get_max_width and get_max_freq I expect (and maybe get_min_freq and so on)
<re_irc>
< (@dirbaio:matrix.org)> what's "width"?
<re_irc>
< (@dirbaio:matrix.org)> isn't it the same as "duty"?
<re_irc>
<Ralph> how about "DutyPwm" (and later "FrequencyPwm", etc.) as trait name(s)?
<re_irc>
< (@adamgreig:matrix.org)> Duty is a ratio, width is a time
<re_irc>
< (@dirbaio:matrix.org)> ohhh, ugh
<re_irc>
< (@dirbaio:matrix.org)> fun
<re_irc>
< (@adamgreig:matrix.org)> (and you might care or not care about the off-period in that case too)
<re_irc>
< (@grantm11235:matrix.org)> : Do you want to merge my pr into your pr, or should I make my own?
<re_irc>
< (@dirbaio:matrix.org)> make your own, it'll be easier I guess
<re_irc>
< (@grantm11235:matrix.org)> I was just worried about splitting the discussion, since a lot of the design happened in the comments of your pr 😅
<re_irc>
< (@dirbaio:matrix.org)> ah true
<re_irc>
< (@dirbaio:matrix.org)> let me merge then
<re_irc>
< (@dirbaio:matrix.org)> 3 days ago lol... for some reason github didn't notify me :o
<re_irc>
< (@adamgreig:matrix.org)> Ralph: Could work, though if we keep the traits inside the pwm module they could be referred to as pwm::SetDuty and so on which keeps "pwm" in the name too, not sure
<re_irc>
< (@grantm11235:matrix.org)> Maybe "SetDutyCycle" is more specific?
<re_irc>
< (@grantm11235:matrix.org)> And "duty cycle" is more googleable
<re_irc>
< (@adamgreig:matrix.org)> yea, makes sense to me
<re_irc>
<Ralph> : i (and the auto-import of IDEs) usually import the traits directly, so i generally don't see them as "pwm::SetDuty" but just as "SetDuty" (which can be weird in this case)
<re_irc>
< (@adamgreig:matrix.org)> other e-h 1.0 traits are like SpiBusWrite, SpiDevice, Write (for serial, maybe that should be renamed...), I2c, InputPin, OutputPin
<re_irc>
< (@adamgreig:matrix.org)> DutyCyclePwm, FrequencyPwm etc? it would be nice if it implied you might reasonably have two of them together, if you wanted to set the frequency and the duty cycle
<re_irc>
< (@burrbull:matrix.org)> Previously it was PwmPin
<re_irc>
< (@grantm11235:matrix.org)> If you are modulating the freqency, it's not really pwm, is it? It's FM
<re_irc>
< (@dirbaio:matrix.org)> it's useful for beep boops :D
<re_irc>
< (@dirbaio:matrix.org)> and it's usually doable by the PWM peripheral
<re_irc>
< (@adamgreig:matrix.org)> it's more that you want to _set_ the frequency
<re_irc>
< (@adamgreig:matrix.org)> but I guess you could say that's something that happens first at setup then you give the correctly-set-frequency object to the driver
<re_irc>
< (@adamgreig:matrix.org)> but anyway the set-width business is definitely still pwm :p
<re_irc>
< (@grantm11235:matrix.org)> If there was a way to query the current frequency/period, it would be possible to set a pulse width in milliseconds or whatever
<re_irc>
< (@jannic:matrix.org)> In case there are all three traits, SetDuty, SetWidth and SetFrequency, how to they interact? Do you always have to set the frequency, and then set either duty or width? Or could you also set duty and width, which is enough to determine the frequency?
<re_irc>
< (@dirbaio:matrix.org)> I think SetWidth isn't really needed, you can do it from SetFrequency
<re_irc>
< (@dirbaio:matrix.org)> * with SetDutyif you know the frequency
<re_irc>
< (@dirbaio:matrix.org)> * SetDuty if
<re_irc>
< (@dirbaio:matrix.org)> so
<re_irc>
< (@dirbaio:matrix.org)> i'd say by default the pin has some "unknown" duty/freq, and you can set either at any time you want
<re_irc>
< (@adamgreig:matrix.org)> if you change the frequency, the max_duty will probably change, I wonder if the hal has to promise to maintain the effective duty cycle after a frequency change?
<re_irc>
< (@dirbaio:matrix.org)> ah hmmm
<re_irc>
< (@adamgreig:matrix.org)> the utility of setwidth is that some things just care about a duty cycle and not what the actual pulse width is, and other things care about the pulse width and not about the duty cycle
<re_irc>
< (@dirbaio:matrix.org)> perhaps document "the duty becomes undefined, you have to immediately set a duty"
<re_irc>
< (@adamgreig:matrix.org)> so yea you can do some maths to move between one or the other, and maybe SetWidth could be fully implemented by default on anything that has SetWidth and GetFrequency or whatever
<re_irc>
< (@adamgreig:matrix.org)> but it'd probably still be useful to have
<re_irc>
< (@dirbaio:matrix.org)> hmm but you never do "I want a pulse width of 4us but don't care about the frequency", right?
<re_irc>
< (@grantm11235:matrix.org)> I don't think there should be a SetFrequency in e-h, for the same reason that there isn't SetBaud for serial
<re_irc>
< (@jannic:matrix.org)> The actual signal shape when you change the frequency of a running PWM peripheral is probably hardware dependent. It may create strange glitches if you do it at the wrong time.
<re_irc>
< (@adamgreig:matrix.org)> for pwm servos you have "i want to set the pulse width and i want the object to have a freq of like 50-100hz ish, but i don't ever need to change the freq"
<re_irc>
< (@adamgreig:matrix.org)> : the difference is SetBaud is strictly setup, but SetFrequency is sometimes setup (if it's not changed at runtime) and sometimes a dynamic parameter the same as the duty cycle
<re_irc>
< (@adamgreig:matrix.org)> so I can see an argument for having it, more so than baud (of course that sometimes changes at runtime too...)
<re_irc>
< (@adamgreig:matrix.org)> but i'm not proposing we add it now, anything with real time units is going to have to wait
<re_irc>
< (@dirbaio:matrix.org)> huh the value you send to the servo is not "scaled" with freq?
<re_irc>
< (@dirbaio:matrix.org)> like 4us is the same position regardless of freq?
<re_irc>
< (@adamgreig:matrix.org)> lots of things use absolute pulse widths to encode data, if it scaled with freq it would just be duty cycle
<re_irc>
< (@dirbaio:matrix.org)> yea I thought it was always duty cycle
<re_irc>
< (@adamgreig:matrix.org)> with a servo the duty cycle isn't very relevant, you can have almost no off-time between pulses or absolutely loads of off-time (if you have too much off-time they stop actively holding position until the next pulse)
<re_irc>
< (@dirbaio:matrix.org)> like 0% = 0deg,100% = 180deg or whatever
<re_irc>
< (@dirbaio:matrix.org)> but I see I was wrong :D
<re_irc>
< (@dirbaio:matrix.org)> like 0% = 0deg, 100% = 180deg or whatever
<re_irc>
< (@adamgreig:matrix.org)> it's usually 1000us to 2000us for 0 to full scale
<re_irc>
< (@adamgreig:matrix.org)> if nothing else you need to disambiguate 0% duty cycle from no signal
<re_irc>
< (@adamgreig:matrix.org)> I fear this hasn't got us any closer to a name 🙃
emerent has quit [Ping timeout: 248 seconds]
<re_irc>
< (@dirbaio:matrix.org)> just name it "trait Yeet"
emerent has joined #rust-embedded
<cr1901>
yeet is a secret keyword, is it not?
<re_irc>
< (@adamgreig:matrix.org)> I suppose set_duty could later get a helper method for setting a pulse width, only on types that also implement some new GetFrequency trait
<re_irc>
< (@adamgreig:matrix.org)> even if we didn't support _setting_ the frequency
<re_irc>
< (@grantm11235:matrix.org)> It also occurred to me that the same api could be used for low speed DACs
<re_irc>
< (@jannic:matrix.org)> Are there MCUs where one can set the pulse width directly, or is it always the duty cycle, and if you want to set a width, you have to do the calculation first?
<re_irc>
< (@adamgreig:matrix.org)> you usually only set the pulse width
<re_irc>
< (@adamgreig:matrix.org)> that this sets the duty cycle is a consequence of the timer having a period as well as a pulse width
<re_irc>
< (@adamgreig:matrix.org)> I've not seen anything that lets you set "duty cycle" rather than on-time and total-period
<re_irc>
< (@adamgreig:matrix.org)> the timer generally counts at some frequency, sets or clears the output pin when it overflows, and clears or sets it when it reaches some comparison value you program
<re_irc>
< (@adamgreig:matrix.org)> e.g. if it's counting up, and overflows/resets at a value of 999, and is running at 1MHz, and you set a comparison of 200, and it turns the pin on at overflow, it will then turn it off at 200 and keep counting to 999, and you'll get a 200µs pulse that repeats every 1ms, for a 20% duty cycle and 1kHz frequency
<re_irc>
< (@adamgreig:matrix.org)> programmed by setting the 200 and the 999 (and the 1MHz)
<re_irc>
< (@adamgreig:matrix.org)> (well, you'd program 199 instead of 200 because it starts at 0, but never mind)
<re_irc>
< (@jannic:matrix.org)> Yes sorry, that was a dumb question - for a fixed frequency, duty and width are basically the same, just specified in different terms. And sure, what you usually set are just counter comparator values.
<re_irc>
< (@adamgreig:matrix.org)> : yea, as in a get_max, set, set_fraction, set_percent API? I guess a lot of low speed DACs are >16 bit so you might need to default to a larger type for those
<re_irc>
<Ralph> * Arduino
<re_irc>
< (@grantm11235:matrix.org)> This makes sense because pwm is just a DAC that needs more filtering
<re_irc>
< (@grantm11235:matrix.org)> But it would probably be a bad idea to try to use the same trait for both, since people might try to drive servos with an analog voltage
<re_irc>
< (@adamgreig:matrix.org)> maybe it's because both are "set to some value out of some maximum value"
<re_irc>
< (@adamgreig:matrix.org)> but yea, i don't think you'd want to make them the same actual trait
<re_irc>
< (@jannic:matrix.org)> But the SetWidth trait would take a duration in absolute time units, not some counter value, right? So it's also not the same value as would be written to some MCU register. In the end it's just a different scaling.
<re_irc>
< (@adamgreig:matrix.org)> yea
<re_irc>
< (@adamgreig:matrix.org)> it's a different intent from the user/driver about what they care about
<re_irc>
< (@adamgreig:matrix.org)> but you could do it as one more method on SetDutyCycle that knew/obtained/took the frequency and scaled as required
<re_irc>
< (@adamgreig:matrix.org)> the max_duty value is almost certainly the counter reload value, so that the hal can just write what it's given directly to the hardware
<re_irc>
< (@jannic:matrix.org)> Yes, with max_duty == counter reload value, set_duty becomes trivial. (well not quite, there's still the issue of encoding 100% duty cycle)
<re_irc>
< (@adamgreig:matrix.org)> yea, probably you just have to set the pin to hard on for that :P
<re_irc>
< (@jannic:matrix.org)> Not sure if there was a decision about that last week?
<re_irc>
< (@adamgreig:matrix.org)> or, depending on mode, do something to set the pin fully off for 0
<re_irc>
< (@adamgreig:matrix.org)> well the "encoding" is easy, if the max_duty is the counter reload, then writing that value to the comparison register means it will never get reached
<re_irc>
< (@adamgreig:matrix.org)> "easy", uh
<re_irc>
< (@adamgreig:matrix.org)> I mean, we agreed that 0 means fully off, and setting it to the return of get_max_duty means fully on
<re_irc>
< (@adamgreig:matrix.org)> so however the hal does that, if the user gives it the number from get_max_duty, it needs to make it fully on, so it's probably going to be the reload value + 1, or maybe the reload value depending on the timer?
<re_irc>
< (@burrbull:matrix.org)> : if we go this way, we need to "unset" pin each time it is not 0 or 100% (or check it previous state)
<re_irc>
< (@adamgreig:matrix.org)> yea, but is that a big overhead?
<re_irc>
< (@adamgreig:matrix.org)> often the timer peripheral itself has a configuration bit to force the output on or off, independent of the rest of the setup
<re_irc>
< (@adamgreig:matrix.org)> so it's just "check for ==max, if so set to forced-on mode, otherwise set to normal mode and program new duty cycle" (or store state to remember if you need to re-set to normal mode)?
<re_irc>
< (@adamgreig:matrix.org)> unless the hardware has some way to do 0 and 100% by just changing the comparison register
<re_irc>
< (@jannic:matrix.org)> The code for rp2040 would look very similar to what wrote for stm32. 100% is done by just setting cc to reload_value + 1.
<re_irc>
< (@burrbull:matrix.org)> : CCRx will be programmed to 200 (on STM32, counting up). The "-1" is for ARR and PSC, but not for CCRx. So "set_off==set_duty(0)" should work fine always. "set_on==set_duty(max_duty)" (where "max_duty == reload_value + 1.") also should work fine except 1 case for 16-bit timer if you set reload_value == u16::MAX (in this case you will get overflow on "get_max_duty").
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]