starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #rust-embedded
fabic has joined #rust-embedded
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter has joined #rust-embedded
richardeoin has quit [*.net *.split]
richardeoin has joined #rust-embedded
Rondom has quit [*.net *.split]
Rondom has joined #rust-embedded
dcz_ has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
dcz_ has quit [Ping timeout: 252 seconds]
<re_irc> <> Hi. I'm about to get going with a sparkfun artemis redboard nano with an amiq apollo3 MCU (cortex-m). there does not seem to be any hal implementations ready. are there any generic cortex-m hal crates? seems like e.g. implementing I2C for the apollo3 would have a lot in common with other MCU's on the same cpu?
<Lumpio-> The generic cortex-m crate(s) are for using the processor specific features, which are a very small thing compared to actual peripherals
<Lumpio-> And those are pretty much hardware specific.
<Lumpio-> However a lot of peripherals can have similarities just because they do the same thing in the end, so taking another HAL's implementation as a base, removing all the register manipulation, and putting new registers in can be helpful
<Lumpio-> Just to get a good idea for the Rust API design
<Lumpio-> But in the end you'll have to look at the datasheet/reference manual for your chip to figure out how to implement it. Or maybe examples from a C HAL or something.
<re_irc> <> Ok, thanks.
<re_irc> <> So the cortex-m pac is for the cpu, while the apollo3_pac is a level above more or less.. but probably re-exports the same stuff as cortex-m
<re_irc> <> (or re-implements)
<Lumpio-> Usually the -pac crate is autogenerated from an SVD file or similar and only contains platform specific register access stuff
<Lumpio-> And I don't think they usually re-export cortex-m stuff
<re_irc> <> Ok
<re_irc> <> greetings! another newbie question:
<re_irc> <> Q: in HAL to use a peripheral I take it moving away from the `xxx_hal::pac::Peripherals`. Then how I can move it back?
<re_irc> <> I guess I missed a documentation fragment
<Lumpio-> Usually you don't move it back
<re_irc> <> If you move it away, the only way to move it back is to re-assign back into the original struct
<re_irc> <> But as mentioned above, you typically don't move it back
<re_irc> <> typically, yes. I'll try to move back then...
<Lumpio-> Why do you need to put it back tho
<re_irc> <> I've needed to do something like this for re-using a GPIO for multiple purposes during setup
<re_irc> <> btw is it possible to e.g. use pins as GPIO after I released the TWIM using that pins?
<re_irc> <> Only if your HAL returns the pins via some `free()` API - not all HALs implement that
<re_irc> <> I'm writing an interactive multipurpose FW that allows using multiple protocols on user's demand
<re_irc> <> A lot of HALs will just silently consume and delete the pins themselves. Some (but not all) expose a way to re-acquire the consumed pins via a `free()`-like function
<re_irc> <> I see. Back to experimenting then )))
<re_irc> <> thanks
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 245 seconds]
<re_irc> <> is there a way to get svdtools to not modify the description when arrayifying registers?
<re_irc> <> I feel like maybe you can set a new description
<re_irc> <> hmm, might be misremembering, can't see anything for that in the code
<re_irc> <> i can (in modify), but any zeros in the description get replaced with %s
<re_irc> <> what i've got now is this:
<re_irc> <> _modify:
<re_irc> <> "SPINLOCK[0123456789],SPINLOCK[12][0123456789],SPINLOCK3[01]":
<re_irc> <> SIO:
<Lumpio-> Oh, it's trying to be a bit too smart eh
* cr1901 sorely wishes svd patching was unnecessary
<cr1901> agg: Btw, will not be here for the meeting tomorrow- prior engagement
<agg> nw, thanks
<re_irc> <> I'm trying to use rust's `[cfg]` instead of C preprocessor defs, with not much luck atm! Any ideas on how to get something like this working:
<re_irc> <> apparently, `removing an expression is not supported in this position` which is annoying
<Lumpio-> Well that's an interesting conundrum
<Lumpio-> Are multiple asm!() statements in a row guaranteed to work as one
<Lumpio-> ...I guess not
<re_irc> <> you _might_ be able to stick a match expression inline there
<re_irc> <> `match () ={ #[cfg(a)] () => {1}, #[cfg(b)] () => {2}}`
<re_irc> <> it's a naked fn, it can only be one big asm! blob
<re_irc> <> 9names: yea, that's annoying, lol, might need a PR to svdtools
<re_irc> <> I guess worst case you have to duplicate the function either way and cfg-gate each function definition
<re_irc> <> if you can put multiple strings into the asm!() call the match expression might work but i'm not sure you can?
fabic has joined #rust-embedded
<re_irc> <> oh, you can
<re_irc> <> but yea i guess the macro cannot handle a match expression
<re_irc> <> yea it needs a single literal..
<re_irc> <> it can have multiple literals, right?
<re_irc> <> It can have multiple literals, yes
<re_irc> <> but each one has to be a literal, not a const fn call or a match expression, tricky
<re_irc> <> maybe you can cook a macro that *emits* the entire asm! call with the right things in it
<re_irc> <> you can't put macros or cfg's *inside* the asm!
<re_irc> <> because outer macros are expanded first..
<re_irc> <> Hmm, doesn't seem possible at the moment, I think a custom macro is probably a bit much for this use case!
<re_irc> <> got a cursed macro for you
<re_irc> <> Omfg it actually works :D
<re_irc> <> My eyes are burning but it works! :D
<re_irc> <> Thank you! dirbaio
<re_irc> <> it's absolutely horrible
<re_irc> <> maybe it's not worth it, I dunno
<re_irc> <> Honestly its really quite good! To me it works how the cfg macro should work anyways, and I've searched zulip and its popped up a few times
<re_irc> <> Maybe worth popping in its own crate? 🤔
<re_irc> <> mhmm maybe
<re_irc> <> very frustrating, i'm unable to enable a dma stream and i really don't why. the hardware doesn't event show me any error
<re_irc> <> hideous, I love it
* re_irc *screams in horror* :D
<re_irc> <> renaming `$x` might help slightly
Shell has quit [Quit: ZNC 1.8.2 -]
<re_irc> <> What on earth did I just look at
Shell has joined #rust-embedded
<re_irc> <> remember Ring, the movie? that, as a Rust macro
fabic has quit [Ping timeout: 265 seconds]
<re_irc> <> Do you have code to show?
<re_irc> <> henrik_alser: yes but unreadable
<re_irc> <> i went back compared to this
<re_irc> <> i went back just before i tried to enable dma. i'm now trying make it work one by one
<re_irc> <> i found some error, i forgot to setup dma stuff in rcc registers. But even fixing that it still no working
<re_irc> <> finally, i made a stream run!
<re_irc> <> it run, but i don't get the right data
tokomak has quit [Ping timeout: 252 seconds]
hosewiejacke has joined #rust-embedded
hosewiejacke has quit [Client Quit]
<re_irc> <> yruama_lairba: i’ll have a better look later but quick first glance you should be using a ’static buffer for the dma
<re_irc> <> henrik_alser: aren't rtic resource static ?
<re_irc> <> henrik_alser thank you, rtic resources aren't static and this is was a source of trouble
<re_irc> <> does it happen to you to frequently to be stuck on stuff like this for days ?
<re_irc> <> i passed at least 3 day on my dma stuff. it was evil because i already did the same thing working outside of rtic, but i forgot few things when copying my old work
<re_irc> <> Did you figure out how to fix it? (In rtic 0.5 if you put a ”static mut” at the start of the init fn it will do a &’static mut transform for you, in 0.6 you initialize it as ”local” in the init attribute)
<re_irc> <> i managed to fix it by declaring my static buffer outside of rtic
<re_irc> <> i just need unsafe block to access it
<re_irc> <> You can have it as a resource if you do as per above :)
<re_irc> <> Just change your let mut to static mut and make sure it’s at the top of the init fn
<re_irc> <> #[task(local = [my_resource: [u8; 16] = [0; 16]])]`
<re_irc> <> This hidden magic is removed in 0.6 and is declared in the attribute instead
<re_irc> <> To make it pure Rust
<re_irc> <> I wonder how people would've felt about co-opting default argument-like syntax:
<re_irc> <> ```rust
<re_irc> <> fn foobar(cx: foobar::Context, my_resource: [u8; 16] = [0; 16]) {
<re_irc> <> #[task]
<re_irc> <> Wouldn’t it feel confusing when doing spawn message passing?
<re_irc> <> I really enjoy the new syntax
<re_irc> <> Maybe yeah. Might not be confusing if the argument needs the `#[local]` attribute.
<re_irc> <> I really like it to, I just wish there was syntax highlighting
<re_irc> <> Yeah that would be nice :) 🌈
<re_irc> <> does this trick allow to share static variable accross context ?
<re_irc> <> Yes, you put it in Resources and return it in LateResources of you’re on 0.5
<re_irc> <> henrik_alser: syntax please ?
<re_irc> <> I’ll try and dig up some old examples, everything is 0.6 these days hehe
<re_irc> <> ok, i will migrate soon, there was a release candidate published today
<re_irc> <> Here’s some nrf examples
<re_irc> <> Yeah if you migrate i got a lot of small DMA examples for the stm32f4 here
<re_irc> <> it's not a miniaml example
<re_irc> <> 🤷🏻‍♀️
<re_irc> <> dma example interess me, especially i there is a bit of abstraction to make thing clearer
<re_irc> <> i find my code not easy to understand
<re_irc> <> Just stick it in Resources as a &’static mut and at the start of init you make it a static mut then return it in LateResources
<re_irc> <> It will do the static mut -> &’static mut transform for you
cyrozap has quit [Remote host closed the connection]
<re_irc> <> Like the singleton! macro
<re_irc> <> This has been a source of confusion in 0.5 (and same thing in cortex-m-rt) because it's not obvious and has therefore been replaced by the attribute declaration in 0.6
<re_irc> <> To provide a safe dma abstraction you will usually see something like that Transfer api in most hals that will own both the buffer and the peripheral
<re_irc> <> > Just stick it in Resources as a &’static mut and at the start of init you make it a static mut then return it in LateResources
<re_irc> <> may don't understand, don't work
<re_irc> <> Need more info to give you hints :)
<re_irc> <> lol, make if work
<re_irc> <> the static declaration need really to be the first thing in the init
<re_irc> <> i did this error many times
<re_irc> <> Yeah that's why it was removed :)
<re_irc> <> it's also removed from cortex_m_rt ?
<re_irc> <> I don’t think so but haven’t really used rt in quite a while
<re_irc> <> (You can also use the singleton! macro for this)
sauce has quit [Remote host closed the connection]
xnor has quit [Ping timeout: 246 seconds]
sauce has joined #rust-embedded
xnor has joined #rust-embedded
cyrozap has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 268 seconds]
mrkajetanp has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]