<re_irc>
<@zaven:matrix.x24.tools> : Yeah that's pretty interesting. I think we'll have to figure something out, because effecting the clocks is fairly normal when coding for low power modes. In the case of our project we power down i2c, adc, etc before stop mode, and then redo parts of the setup when we wake - this is absolutely necessary to get to the lowest power consumptions. I wonder how much of this process the hal is gonna get in the way of...
<re_irc>
... because the register vars are already consumed?
<re_irc>
<@firefrommoonlight:matrix.org> Oh god. I found my first Heisenbug. And I DO NOT like it. My I2C baro only works when run from a debug interface. Stops workign when run normal, and data is viewed from complementary PC software over USB
<re_irc>
<@firefrommoonlight:matrix.org> On the other thread: I concur that freezing the clocks is not a great move
<re_irc>
<@firefrommoonlight:matrix.org> +for the reason mentioned: Changing clock speed during operation is a reasonable thing to do
<re_irc>
<@firefrommoonlight:matrix.org> This is the same Baro that I had plugged into the wrong pin due for a while due to a datasheet error. Maybe God or whoever doesn't want me using this baro
<re_irc>
<@zaven:matrix.x24.tools> : maybe some kind of explicit unfreeze functionality could be good.
<re_irc>
<@firefrommoonlight:matrix.org> zaven: That could work. There are a lot of ways to make this work from an API perspective. I think the intent to freeze works _If you assume you never change clock speeds_, since it makes other assumptions easier
<re_irc>
<@firefrommoonlight:matrix.org> My take is that's fine for maker stuff, but not suitable more broadly
<re_irc>
<@firefrommoonlight:matrix.org> I personally ditch the assumption that clock speed is immutable
<re_irc>
<@firefrommoonlight:matrix.org> So, I have a method on the clock config struct called "setup", which doesn't have the semantic implication "freeze" does
<re_irc>
<@firefrommoonlight:matrix.org> Then you just add methods to change the speed, or let the user change the config struct and re-run "setup", knowing he or she will have to change peripheral clock scalers as required
<re_irc>
<@zaven:matrix.x24.tools> : yeah exactly. in the hal i'm seeing that we could either decide not to consume cfgr and pass a ref instead, or pass pack an unfreeze struct that keeps register access alive.
<re_irc>
<@firefrommoonlight:matrix.org> zaven: This gets interesting on ST's low-power products which have a MCO which is designed to change speeds on the fly
<re_irc>
<@firefrommoonlight:matrix.org> *MSI
<re_irc>
<@zaven:matrix.x24.tools> : just had a peak at that, new to me and super neat. definitely needs to give the application dynamic clock speed control.
wes_ has quit [Ping timeout: 246 seconds]
adicarlo has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
<re_irc>
<@sourcebox:matrix.org> : Personally I don't change the clock speed in my projects but there's surely a demand for applications that require powersave actions. My main question is here how to deal with the timers since the frequencies also change requires new calculation of prescalers etc. This leads to a related question: what setup do you do with the SysTick and what is it used for internally? Typically, I'm using a 1kHz systick like in the...
<re_irc>
... ST HAL for getting millis() and micros() time functions.
fabic has joined #rust-embedded
dc740 has joined #rust-embedded
<Lumpio->
A lot of the time it makes most sense to always run at high speed and sleep completely as much as possible
<Lumpio->
And use a separate low freq low power timer for any timed wakeups from sleep
<Lumpio->
Then there's no need to ever change clocks on the fly.
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> (I also use the full speed, then sleep for the low-power projects I've done)
<re_irc>
<@sourcebox:matrix.org> : I try to figure out if I can use the SysTick counter for time measurement. What setup do you perform on it? Can I change the configuration later or is it used by something inside the HAL?
<re_irc>
<@firefrommoonlight:matrix.org> Good call - I (perhaps surprisingly) haven't used it for anything but blocking delays (eg on peripheral inits)
<re_irc>
<@firefrommoonlight:matrix.org> I'm curious too
<re_irc>
<@firefrommoonlight:matrix.org> Eg for using it to get a running time
<re_irc>
<@firefrommoonlight:matrix.org> Nice! Sounds like you could use that directly here, no?
<re_irc>
<@sourcebox:matrix.org> I do. But I realized that the settings were changed by something inside your code. So it only works when I configure the SysTick after your code.
<re_irc>
<@firefrommoonlight:matrix.org> From a skim, what that does it increment a global counter every time the systick delay happens, which is every ms?
<re_irc>
<@sourcebox:matrix.org> Yes. Basically the same as STM HAL does.
<re_irc>
<@firefrommoonlight:matrix.org> Presumably that doesn't cause problems with program flow because it's such a tiny operation? (I understand this sort of operation is common in C code)
<re_irc>
<@firefrommoonlight:matrix.org> (And presumably it would also have to be a high interrupt priority)
<re_irc>
<@sourcebox:matrix.org> SysTick has the lowest priority.
<re_irc>
<@sourcebox:matrix.org> Highest in number.
<re_irc>
<@firefrommoonlight:matrix.org> Low pri, but it never skips one, I'd guess?
<re_irc>
<@firefrommoonlight:matrix.org> I guess the only challenge here is intergrating it into the "cortex-m" or "RTIC" etc runtime
<re_irc>
<@sourcebox:matrix.org> It shouldn't. But I think, I also implemented an overflow detecttion because this is supported by the peripheral.
<re_irc>
<@sourcebox:matrix.org> But 1ms is ages in terms of MCU speed.
<re_irc>
<@sourcebox:matrix.org> As a side affect, this crate gives me also a clock cycle count, which is useful on Cortex-M0 e.g. because it doesn't have it in silicon.
<re_irc>
<@firefrommoonlight:matrix.org> Nice
<re_irc>
<@firefrommoonlight:matrix.org> (Btw, depending on use case, using the RTC can be a nice way to get time since start)
<re_irc>
<@firefrommoonlight:matrix.org> Espeically if configured with an LSE
<re_irc>
<@sourcebox:matrix.org> I've seen, you've done some integration with it, right?
<re_irc>
<@firefrommoonlight:matrix.org> Yea
<re_irc>
<@firefrommoonlight:matrix.org> Could be the perfect tool, or overkill depending on what you're using the timing for
<re_irc>
<@firefrommoonlight:matrix.org> And of course, hardware timers too that increment a counter or with some wrapping mechanism to read _their_ counter
<re_irc>
<@firefrommoonlight:matrix.org> Could possibly use any of those 3 dpeneding on use case
<re_irc>
<@sourcebox:matrix.org> I'm not sure about RTIC because I sometimes need an RTOS for application tasks. But this should be one that is not bound to a specific architecture.
<re_irc>
<@sourcebox:matrix.org> So using RTIC just for the time functions is overkill and would also prevent the use of another RTOS.
<re_irc>
<@firefrommoonlight:matrix.org> *Distinction, RTIC / RTC differnet things
<re_irc>
<@sourcebox:matrix.org> I'm typically putting all hardware related things inside a separate board crate. So if I use RTIC in that, the user of the board crate is also bound to that.
<re_irc>
<@sourcebox:matrix.org> RTIC is Cortex-M bound, that's the main problem with application code because this is mostly platform agnostic.
<re_irc>
<@sourcebox:matrix.org> But yeah, you were talking about the RTC, my fault.
<re_irc>
<@sourcebox:matrix.org> But RTC does not seem to have enough resolution for microseconds, does it?
<re_irc>
<@sourcebox:matrix.org> I also see a 16-bit sub seconds register RTC_SSR in the RM.
<re_irc>
<@sourcebox:matrix.org> : I had to use the features "embedded-time", "nb", "void" otherwise I get compile errors from the HAL.
<re_irc>
<@sourcebox:matrix.org> I wonder what's a good strategy for selecting a crate name when the preferred one is already taken in several variations on crates.io.
<re_irc>
<@firefrommoonlight:matrix.org> : Interesting. Will take a look
<re_irc>
<@sourcebox:matrix.org> I enabled the embedded-hal feature, I think after that I had to enable the other ones too.
<re_irc>
<@sourcebox:matrix.org> Full list is "["l4x2", "l4rt", "embedded-hal", "embedded-time", "nb", "void"]"
<re_irc>
<@firefrommoonlight:matrix.org> Hmm
<re_irc>
<@firefrommoonlight:matrix.org> Intent is, enabling the eh feature adds those dependencies automatically
<re_irc>
<@firefrommoonlight:matrix.org> And it is strictly optional
<re_irc>
<@sourcebox:matrix.org> : I thought it would be like that.
<re_irc>
<@firefrommoonlight:matrix.org> Ie should not be required to use the RTC
<re_irc>
<@sourcebox:matrix.org> I don't use the RTC, that's a diferent topic.
<re_irc>
<@firefrommoonlight:matrix.org> Ok try yhis
<re_irc>
<@firefrommoonlight:matrix.org> Try underscore instead of -
<re_irc>
<@sourcebox:matrix.org> For embedded-hal?
<re_irc>
<@firefrommoonlight:matrix.org> Yea
<re_irc>
<@sourcebox:matrix.org> Works.
wes_ has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> Confusing because apparently both variants exist.
<re_irc>
<@sourcebox:matrix.org> At least according to the docs.
fabic has quit [Ping timeout: 255 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> One is a feature, the other is a dependency
<re_irc>
<@firefrommoonlight:matrix.org> I'm not sure why they work interchangeably like that
<re_irc>
<@sourcebox:matrix.org> The docs list both variants as features.
<re_irc>
<@firefrommoonlight:matrix.org> Link?
<re_irc>
<@adamgreig:matrix.org> all optional dependencies are also features
<re_irc>
<@adamgreig:matrix.org> i.e., if you list a dependency and make it optional, your crate now has a few feature that enables that dependency, named the same as the dependency, even if you don't put it in "[features]"
<re_irc>
<@firefrommoonlight:matrix.org> Interesting. LMK if you have any ideas. Likely unfixable on my end from Adam's info
<re_irc>
<@firefrommoonlight:matrix.org> Other than choosing a diff name for the feature
<re_irc>
<@sourcebox:matrix.org> No idea.
<re_irc>
<@adamgreig:matrix.org> just name the feature the same as the dependency?
<re_irc>
<@adamgreig:matrix.org> you are allowed to use the dependency name to enable other dependencies and cfg-gate stuff etc iirc
<re_irc>
<@sourcebox:matrix.org> Maybe including both variants for semver compatibility?
<re_irc>
<@adamgreig:matrix.org> yea, have the (now deprecated) embedded_hal feature just enable the embedded-hal feature (and dependency), and cfg gate etc everything off embedded-hal?
<re_irc>
<@firefrommoonlight:matrix.org> Will try that
<re_irc>
<@firefrommoonlight:matrix.org> Sounds like it will work
wes_ has quit [Ping timeout: 248 seconds]
<re_irc>
<@jannic:matrix.org> > i.e., if you list a dependency and make it optional, your crate now has a few feature that enables that dependency, named the same as the dependency, even if you don't put it in "[features]"
<re_irc>
<@firefrommoonlight:matrix.org> I prefer that, since I don't want to conflate deps and features; they are different concepts
<re_irc>
<@boiethios:matrix.org> Hey, can I add tests to my project? Neither unit tests or integration ones work directly. What's the best strategy to test my code?
<re_irc>
<@boiethios:matrix.org> * nor
<re_irc>
<@boiethios:matrix.org> Hey, can I add tests to my project? Neither unit tests nor integration ones work directly. What's the best strategy to test my code?
<re_irc>
I assume that the easiest way is to extract my target-independent code in its own lib, and then test that part, am I right?
<re_irc>
<@firefrommoonlight:matrix.org> Implemented/pushed/works "dep:" tag
<re_irc>
<@mqudsi:matrix.org> : Extracting whatever peripheral-free code you have is the first step. Making code abstract over the peripherals so you can mock them is the way to go, if you have the resources to expend on that. Otherwise you can use the linux hal crate and connect the peripherals to your actual dev pc to test if needed. Qemu is a great option for testing things virtualized in CI.
<re_irc>
<@boiethios:matrix.org> : Thanks. I think I only need to test the peripheral-free logic, so that's what I'll do first. I'm keeping your comment around if I need to test the hardware part.
<re_irc>
<@boiethios:matrix.org> : How would you do that? One crate with bin + lib (not sure that'll work) or a workspace with 2 crates?
dc740 has quit [Remote host closed the connection]
<re_irc>
<@firefrommoonlight:matrix.org> typo in GPIO module
<re_irc>
<@sourcebox:matrix.org> For some reason now you don't implement the e-h traits "InputPin" and "OutputPin" anymore.
<re_irc>
<@firefrommoonlight:matrix.org> I confused myself with the "-" vs "_"
<re_irc>
<@sourcebox:matrix.org> Ok ;-)
<re_irc>
<@firefrommoonlight:matrix.org> And it was fine before because of teh conflation of dep and feature
<re_irc>
<@sourcebox:matrix.org> Yes.
<re_irc>
<@sourcebox:matrix.org> I did not change anything to my code.
<re_irc>
<@firefrommoonlight:matrix.org> Try now
<re_irc>
<@firefrommoonlight:matrix.org> I was using hyphens all over the place before I guess
<re_irc>
<@sourcebox:matrix.org> Better.
<re_irc>
<@adamgreig:matrix.org> : on fd-can, have you enabled either the "fdcan_g0_g4_l5" or "fdcan_h7" feature?
<re_irc>
<@firefrommoonlight:matrix.org> TBH this is the sort of reason why I jumped at the "dep:" syntax; this sort of thing _should_ raise an error, in the name of explicitness in rust
<re_irc>
<@firefrommoonlight:matrix.org> No
<re_irc>
<@firefrommoonlight:matrix.org> That would probably do it!
<re_irc>
<@firefrommoonlight:matrix.org> : What's your 2c (2p?) on the "fd-can" crate. Good stuff?
<re_irc>
<@dirbaio:matrix.org> I hoped they'd deprecate the old "optional=true" implicitly creates a feature... but no :(
<re_irc>
<@adamgreig:matrix.org> haven't used it
<re_irc>
<@dirbaio:matrix.org> * ""optional=true" implicitly creates a feature"...
<re_irc>
<@firefrommoonlight:matrix.org> I'm interested in working on developing a CAN-based open-source motor protocol for quadcopters, and am not sure if I should use it, or write my own from RMs
<re_irc>
<@firefrommoonlight:matrix.org> Copy thx
<re_irc>
<@adamgreig:matrix.org> from what I've seen/heard it's probably good, I'd certainly try it to start
<re_irc>
<@sourcebox:matrix.org> But the feature is still spelled "embedded_hal" not "embedded-hal".
<re_irc>
<@adamgreig:matrix.org> the can peripheral can be a bit of a pain to use effectively. easy to end up with filters and mailboxes configured suboptimally and get stuck messages or whatever
<re_irc>
<@firefrommoonlight:matrix.org> Yes. I had the latter all over teh code base
<re_irc>
<@firefrommoonlight:matrix.org> Now fixed
<re_irc>
<@firefrommoonlight:matrix.org> : Oh no! Yet, I think learning it may be worth it
<re_irc>
<@firefrommoonlight:matrix.org> I'm obviously a bit confused by the fact that CAN nominally handles a lot of things you'd have to do by hand in another protocol, but the hardware interface seems, in contrast, intimidating
<re_irc>
<@adamgreig:matrix.org> indeed
<re_irc>
<@adamgreig:matrix.org> it's a great protocol
<re_irc>
<@firefrommoonlight:matrix.org> : Yea I would love to see it stricken from Rust
<re_irc>
<@firefrommoonlight:matrix.org> I'm glad to hear that we can avoid it though! Didn't know that until the earlier convo here today
<re_irc>
<@firefrommoonlight:matrix.org> Will use "dep:" exclusively going fwd