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
cgc17[m] has joined #rust-embedded
<dirbaio[m]> it's templated a bit and outputted into the link.x filename here https://github.com/rust-embedded/cortex-m/blob/master/cortex-m-rt/build.rs#L23
<cgc17[m]> ah, got it. so -C is codegen and -T is what? and now i know what link.x is :)
<dirbaio[m]> -C link-arg=whatever passes whatever as link args
<dirbaio[m]> so to be able to figure out what it is, you need to look it up in the linker's manual
<dirbaio[m]> > --script=file, -T file
<dirbaio[m]> > Read linker script from file. If multiple linker scripts are given, they are processed as if they were concatenated in the order they appeared on the command line.
<dirbaio[m]> (yep, command line flags inside command line flags 💀)
<dirbaio[m]> * -C link-arg=whatever passes whatever as a command line flag to the linker
<cgc17[m]> And no space between -T and link.x bc something else is parsing that out?
<dirbaio[m]> no, the linker accepts both -T link.x and -Tlink.x
<dirbaio[m]> space is usually optional in options that are single dash + single letter
<cgc17[m]> ah cool I didn’t realize that. I let this be magic for a while, but it kept nagging me so thanks for explaining the pieces and linking to docs!
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #rust-embedded
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]> <thejpster[m]> ":tada: https://ferrous-systems...." <- Oh hoh hoh do I have some clients to inform
<ryan-summers[m]> <sourcebox[m]> "Not a topic for the meeting, but..." <- If no one has gotten to it after next week, please re ping me. I'm currently swamped onsite with a client and don't have much time until I fly back home
igiona[m] has joined #rust-embedded
<igiona[m]> <thejpster[m]> ":tada: https://ferrous-systems...." <- Fantastic! I hope this is going to be another asset for finally bringing Rust in our embedded systems (real once, not Linux embedded 🙈 )
FrreJacques[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> Finally?
<thejpster[m]> <bartmassey[m]> "That would be good! Let me..." <- You have mail ;)
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
limpkin has joined #rust-embedded
LiamKinne[m] has quit [Quit: Idle timeout reached: 172800s]
fooker has quit [Ping timeout: 272 seconds]
corecode[m] has joined #rust-embedded
<corecode[m]> i'm getting a disallow references to static mut lint now, in my interrupt handler that calls a callback (if it is `Some`). The callback by itself is `Box<dyn FnMut() + Send>`. What would be a more idiomatic way of doing this?
fooker has joined #rust-embedded
Dlaw[m] has joined #rust-embedded
<Dlaw[m]> <corecode[m]> "i'm getting a disallow reference..." <- As far as I understand it, you can either use a raw mut pointer instead of a mut reference, or else change to a type with interior mutability and take a non-mut static reference
<Dlaw[m]> Dlaw[m]: If you don't have control over the callback type, I'm not sure
<corecode[m]> <Dlaw[m]> "If you don't have control over..." <- but what interior mutability can work inside interrupt context?
<corecode[m]> corecode[m]: atomic maybe?
jduck[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> I got a reply from Renesas. They said, no, they will not RMA my board.
<dirbaio[m]> no Rust for them 🤷
ilhanben[m] has joined #rust-embedded
<ilhanben[m]> Good morning guys, i see three thousands of people here. Thanks for today and for future !🚀
berkus[m] has joined #rust-embedded
<berkus[m]> ilhanben[m]: for impl Future
<berkus[m]> in return position perhaps
<thejpster[m]> I had to type out the interrupt enum by hand having read the PDF datasheet, because I couldn't find an SVD file and I didn't really want to bring a PAC into my example. So it's possible I typed it wrong.
AlexandrosLiarok has joined #rust-embedded
<AlexandrosLiarok> how should one approach making PRs for projects in the rust-embedded-community repos ?
<AlexandrosLiarok> I have one for serde-json-core, last PR merge / commit was done 5 months ago.
<JamesMunns[m]> <thejpster[m]> "bah, my interrupts are not..." <- > <@thejpster:matrix.org> bah, my interrupts are not firing. What have I forgotten?... (full message at <https://catircservices.org/_irc/v1/media/download/Aa2G5A5Z5PbdR8LXD3LW89ANrt9t3gw-QUeI8wP9M9Nt8biw6aEZqceAN_CayOKGin_zx6J81iSJ5sUJ_fI4-fi_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9xVWpWdmZhd1JrcXV2R21Tdkh4QlBqbms>)
<JamesMunns[m]> ah, that's probably what you mean by "enable interrupts", and the "CONTROL" part was "enable interrupt source in the peripheral"
<thejpster[m]> yeah, that
<JamesMunns[m]> does it keep doing stuff? or just lock up?
<thejpster[m]> the interupt never fires
<JamesMunns[m]> if you had a bad vector table, or weren't clearing the interrupts, I'd expect it to halt or endlessly loop in the interrupt
<thejpster[m]> ikr
<JamesMunns[m]> if it's not firing... idk. I'd probably double check the peripheral setup, does the non-interrupt peripheral work?
<thejpster[m]> maybe I'll try single stepping it
<thejpster[m]> yeah the non-interrupt version works fine
<JamesMunns[m]> huh. my only other guess was "the peripheral wasn't clocked so it wasn't generating events"
<JamesMunns[m]> you could try manually pending the interrupt to make sure that bit works?
<JamesMunns[m]> might help bisect things
ithinuel[m] has quit [Quit: Idle timeout reached: 172800s]
<bogdan[m]> I'd also check the errata for the microcontroller
<thejpster[m]> oh no
<thejpster[m]> I mis-typed the interrupt list. There's a reserved block in the middle
<JamesMunns[m]> like, the actual vector table? or the peripheral control block?
<thejpster[m]> I'm writing the vector table by hand as there is no SVD I can find
swork[m] has quit [*.net *.split]
vancz has quit [*.net *.split]
WSalmon has quit [*.net *.split]
Artea has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
<JamesMunns[m]> I'm... surprised it doesn't just rage quit/hard fault when the interrupt does occur
<JamesMunns[m]> what address are you filling the non-populated entries with?
swork[m] has joined #rust-embedded
vancz has joined #rust-embedded
Artea has joined #rust-embedded
WSalmon has joined #rust-embedded
Foxyloxy has joined #rust-embedded
Artea has quit [Max SendQ exceeded]
Artea has joined #rust-embedded
<thejpster[m]> fixing the interrupt numbers didn't fix it. I suspect i need to poke the UART harder to actually enable the interrupt
<JamesMunns[m]> ahh, it's thumbv8m, I wonder if you have to do Weird Things for the NS/S stuff
<thejpster[m]> I hope not
<dirbaio[m]> on all chips i've seen (stm32, nrf) you can run on S mode and pretend trustzone doesn't exist
<dirbaio[m]> but it's just because all peripherals+RAM defaults to S, which is vendor-specific I think
<thejpster[m]> oh I see what I did
<thejpster[m]> I fill up the ring buffer, but I never actually do the first manual transmit. The IRQ won't fire until the TX buffer has something in it and then goes empty
<dirbaio[m]> you can also the irq to kickstart it instead of doing a tx manually
<dirbaio[m]> nicer because it centralizes tx in a single place
<thejpster[m]> i feel race hazards coming on
<thejpster[m]> hey, i got interrupts
vancz has quit [Quit: No Ping reply in 180 seconds.]
vancz has joined #rust-embedded
<thejpster[m]> ok, I ripped it all apart and added simplicity. Now it seems to work.
<thejpster[m]> I decided to use an spsc buffer inside a Mutex rather than using an mpsc buffer and a Uart inside a Mutex
<thejpster[m]> thoughts on https://github.com/ferrous-systems/rust-training/pull/246 very much appreciated. It has to be right, as it's going to become a worked exercise.
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
almindor[m] has quit [Quit: Idle timeout reached: 172800s]
HeapUnderflow[m] has joined #rust-embedded
<HeapUnderflow[m]> heyo, does anyone have a good-ish example for rust on an esp32-c3? (specifically usage with ble, maybe using esp32-nimble)
dngrs[m] has joined #rust-embedded
<dngrs[m]> HeapUnderflow[m]: esp-idf has [examples](https://github.com/esp-rs/esp-idf-hal/tree/master/examples), though no bluetooth. How about [the nimble examples](https://github.com/taks/esp32-nimble/tree/main/examples)?
<dngrs[m]> also I highly recommend the #esp-rs:matrix.org room if you have specific questions, lots of very helpful folk there
<HeapUnderflow[m]> ahhh nice, i will check those out (missed them before :D)... tho i have also found at least one of the issues ive encountered until now, which was a typo (sdkconfig.default instead of sdkconfig.defaults, which builds the esp stuff without ble 🤦)
petekubiak[m] has joined #rust-embedded
JamesSizeland[m] has joined #rust-embedded
<JamesSizeland[m]> <HeapUnderflow[m]> "heyo, does anyone have a good-..." <- We have bare metal ble examples here https://github.com/embassy-rs/trouble/tree/main/examples%2Fesp32
<JamesSizeland[m]> * Beat me to it Pete!
<HeapUnderflow[m]> petekubiak[m]: i have not. from a first glance this seems to be alright? ill definetly giving it a go seeing as nimble is being a bit finnicky....
<HeapUnderflow[m]> i really am only looking for pure scanning, i dont need any kind of connecting or pairing so... (tho it looks like the "central" example has that covered somewhat?)
<petekubiak[m]> I've personally mainly been focused on the peripheral side, but yes I believe the central example does cover scanning.
<petekubiak[m]> We're actively developing it with a focus on being user friendly so please do let us know what you'd like to see improved!
ouilemur has left #rust-embedded [WeeChat 4.5.1]