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
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
<re_irc> < (@TimSmall:matrix.org)> This year's FOSDEM conference (Brussels 4th + 5th Feb, free to attend both online and in-person) includes a day of Rust talks. Other tracks which might be of interest include: "Embedded, Mobile and Automotive", "LLVM", "Microkernel and Component-based OS" and "Open Source Firmware, BMC and Bootloader". The mostly-complete list of talks is here: https://fosdem.org/2023/schedule/tracks/ . If anyone...
<re_irc> ... who's attending in-person would like to meet up, give me a shout.
<re_irc> < (@TimSmall:matrix.org)> I should have said - FOSDEM is Europe's largest open source software conference, and usually has about 5000 to 8000 attendees, and is well worth a visit, the hallway (and bar/restaurant) track is great. There are also third party "Fringe" events held before and afterwards.
<re_irc> < (@lulf_:matrix.org)> : I plan to be there, would love to meet up with you and others from the community!
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> <cdetka> Happy New Year to all. I'm very new to Rust and unsure where to turn for help. I am trying to generate a peripheral access crate from an SVD file using svd2rust. I've tried two SVD files for two different MCUs and the results produce the same compiler error.
<re_irc> <cdetka> Sorry, hit send before ready
<re_irc> <cdetka> According to the docs, I need to use this kind of syntax to get to the perhipherals: let mut peripherals = mk24::Peripherals::take().unwrap();
<re_irc> <cdetka> When the compiler encounters this line, I get this error: "mk24::Peripherals" is not an iterator
<re_irc> <cdetka> I'm using version 0.28.0 of svd2rust
<re_irc> <cdetka> version 1.66.0 of rustc
<re_irc> <cdetka> Can anyone point me in a useful direction? Could this be due to an incompatible compiler version?
<re_irc> <cdetka> Thank you for your help!
<re_irc> <FredrikLL> I am using 1.66.0 without issue. Have you checked that the pub struct Peripherals has been generated in src/lib.rs of your pac? And do you have use mk24; in the file where you are trying to use it?
<re_irc> <cdetka> Thank you for the input FredrikLL. I will read and read until I understand your questions and can answer them. :-) I assume there is nothing wrong with 1.66.0. I assume the issue is due to something I have or have not done. Thanks again!
<re_irc> < (@ryan-summers:matrix.org)> I'm confused by the error you quote, as the "Peripherals" struct indeed is not an iterator - is the compiler error being generated when you generate the PAC from the SVD, or when you try to use the generated PAC code?
<re_irc> <cdetka> Sorry for the confusion ryan-summers. Here's my process. 1) created an application project (cargo new) 2) within this project, I added a folder called "lib" where I deposited the SVD file. 3) Run svd2rust in the "lib" tree 4) use form and shuffle code to the src folder (as suggested on the svd2rust wiki) 5) "cargo build" the source produced from svd2rust in the "lib" tree -- this builds without any errors. 6) return to...
<re_irc> ... the application folder (above "lib") 7) update the Cargo.toml to point to the new PAC. 8) attempt to compile the application with the peripheral line shown above. BTW, I have "use mk24" in my application (with allow unused) so the linker can find the ISR code -- I think that means I'm linking the PAC. At step (8) the build fails with the error message "mk24::Perhiperals is not an iterator". If I remove that line, the code...
<re_irc> ... compiles without errors.
<re_irc> < (@ryan-summers:matrix.org)> When you remove what line of code? It sounds like the PAC is getting generated successfully? Or is the "use mk24;" causing the compile to fail?
<re_irc> <cdetka> The direct answer to your question is: when I try to use the PAC
<re_irc> <cdetka> No, "use mk24" allows the compile to succeed -- without this the linker does not find the ISR code produced by svd2rust
<re_irc> <cdetka> The compile breaks only after I call the "mk24::Perhipherals" take function
<re_irc> < (@ryan-summers:matrix.org)> What does your code look like where it's breaking? Can you post a snippet here?
<re_irc> <cdetka> #![no_std]
<re_irc> #![no_main]
<re_irc> extern crate no_std_compat as std;
<re_irc> extern crate panic_halt;
<re_irc> < (@ryan-summers:matrix.org)> Hmm that all looks fine to me. I wonder why the compiler isn't liking the "take()" call
<re_irc> < (@ryan-summers:matrix.org)> Also, you can wrap code in three "`" (backtick) to format it
<re_irc> // Like this
<re_irc> < (@ryan-summers:matrix.org)> pub fn sample() {
<re_irc> }
<re_irc> < (@ryan-summers:matrix.org)> Also, you can wrap code in three "`" (backtick) to format it (then add ````rs` to make it rust)
<re_irc> < (@ryan-summers:matrix.org)> Also, you can wrap code in three "`" (backtick) to format it (then add ```rs\ to make it rust)
<re_irc> < (@ryan-summers:matrix.org)> Also, you can wrap code in three "`" (backtick) to format it (then add the rs tag at the end of the first backtick line (```rs) to make it rust)
<re_irc> < (@marmrt:matrix.org)> Have you tried generating the documentation for the pac? "cargo doc --open"
<re_irc> < (@ryan-summers:matrix.org)> You can always just take a look at the generated mk24 source code for "mk24::Peripherals" to see that the signatures are lining up with what you expect, but I guess that's where cargo doc helps
<re_irc> <cdetka> Thank you marmrt! I have not done that. My plan is to do as marmrt, ryan-summers and FredrikLL have suggested: 1) generate docs and review, 2) inspect the code and 3) find a PAC in github that includes the peripheral code to see if I'm missing something. If anyone can suggest a PAC on github for me to inspect, that would be most helpful. Thanks everyone for your time and attention!
<re_irc> < (@korken89:matrix.org)> Here you have an example of how it should look
<re_irc> <FredrikLL> I tried an old project (almost identical) that was working with an older version of svd2rust & rustc and I am now getting the same error cdetka is facing.
<re_irc> <FredrikLL> The PAC is working when I am using it in an RTIC project.
<re_irc> <cdetka> Thank you for trying that FredrikLL !
<re_irc> < (@korken89:matrix.org)> Have you enabled the "rt" feature of the PAC?
<re_irc> < (@adamgreig:matrix.org)> I think it's the critical-section feature that needs enabling
<re_irc> path = "./lib/mk24"
<re_irc> features = ["rt"]
<re_irc> <cdetka> Yes to . I have this in my Cargo.toml: ```[dependencies.mk24]
<re_irc> version = "0.1.0"
<re_irc> <cdetka> * "0.1.0"```
<re_irc> < (@adamgreig:matrix.org)> The error message is astonishingly bad and it's because take() is a method on the built in Iterator trait which is imported by default, so because the critical-section feature isn't enabled, there's no take() method available on the Peripherals struct, so instead Rust tries to call the method on Iterator and then complains that Peripherals doesn't implement Iterator
<re_irc> < (@adamgreig:matrix.org)> Ideally we'd have called the method something that doesn't exist on a built in trait like that...
<re_irc> < (@korken89:matrix.org)> ops
<re_irc> < (@adamgreig:matrix.org)> Although arguably Rust could do a better job of the error message here
<re_irc> < (@adamgreig:matrix.org)> Anyway enable the "critical-section" feature alongside the "rt" feature
<re_irc> < (@korken89:matrix.org)> Ah you need the feature on "svd2rust"
<re_irc> < (@korken89:matrix.org)> Not the generated PAC crate
<re_irc> < (@adamgreig:matrix.org)> Are you sure? I think it's on the PAC...?
<re_irc> < (@korken89:matrix.org)> Oh
<re_irc> < (@korken89:matrix.org)> I was checking the rp2040 pac and it does not have the critical section feature flag
<re_irc> < (@korken89:matrix.org)> Maybe it's an old PAC
<re_irc> < (@adamgreig:matrix.org)> But it does have an optional dependency on c-s maybe?
<re_irc> [dependencies]
<re_irc> < (@korken89:matrix.org)> Not really
<re_irc> vcell = "0.1.0"
<re_irc> cortex-m = "0.7.3"
<re_irc> < (@adamgreig:matrix.org)> Ah, that probably is just old then
<re_irc> < (@korken89:matrix.org)> Makes sense
<re_irc> < (@adamgreig:matrix.org)> This came in 0.26
<re_irc> < (@korken89:matrix.org)> "This crate has been built using svd2rust version 0.21"
<re_irc> < (@korken89:matrix.org)> Just old :)
<re_irc> < (@adamgreig:matrix.org)> I wonder if we can generate a take() method when c-s isn't available that generates a compiler error...
<re_irc> < (@adamgreig:matrix.org)> Or maybe make it a hard dependency :/ I don't think it was appreciated at the time that rust would end up generating this wild error message about Iterator
<re_irc> <FredrikLL> I have the optional dependency on c-s in the pac and got the error
<re_irc> <cdetka> I feel like the answer sits in front of me, but I do not understand exactly how to enact the change. If I put "critical-section" next to "rt" in my PAC toml file, that does not work -- critical-section is not a feature of my PAC. Can someone dumb this down for me? Where must I indicate that I require "critical-section"?
<re_irc> < (@dirbaio:matrix.org)> yea I dunno why it's optional
<re_irc> < (@adamgreig:matrix.org)> Your Cargo.toml also needs to have an optional dependency on the critical-section crate
<re_irc> < (@dirbaio:matrix.org)> you can still build without a cs impl as long as you never call .take()
<re_irc> < (@adamgreig:matrix.org)> Like the example in https://docs.rs/svd2rust/latest/svd2rust/#target--cortex-m
<re_irc> < (@adamgreig:matrix.org)> Another confusing rust thing is that all optional dependencies create a feature with the name of the dependency
<re_irc> < (@adamgreig:matrix.org)> : The error message in this case isn't amazing either but at least it's not as deeply confusing as the iterator one...
<re_irc> < (@dirbaio:matrix.org)> with namespaced features, if you explicitly do "dep:cortex-m-rt" then the "cortex-m-rt" feature isn't autocreated
<re_irc> <FredrikLL> I am getting the same error with c-s as a dependency
<re_irc> < (@adamgreig:matrix.org)> : Yea, at last, though it's a shame it's something of a magical syntax and doesn't really help the confusion here
<re_irc> < (@adamgreig:matrix.org)> FredrikLL: Are you adding the dependency to the PAC Cargo.toml, not your project's?
<re_irc> <FredrikLL> I’ve tried adding it to both
<re_irc> < (@adamgreig:matrix.org)> You need the dependency added to the Cargo.toml of your PAC, and then enable the feature in the Cargo.toml of your project where it depends on the PAC
<re_irc> < (@adamgreig:matrix.org)> cdetka: Did you get this working? You could copy from this PAC's Cargo.toml.https://github.com/stm32-rs/stm32-rs-nightlies/tree/master/stm32f0
<re_irc> < (@adamgreig:matrix.org)> There the critical-section feature is enabled by default so that you don't need to enable it in your own project crate
<re_irc> <cdetka> : your comments are obviously exactly what I need. I've tried and failed, but that is because I'm a n00b. I must commit time to the work I am employed to perform, so for now, I must shelf this and return later. I believe once learn a little more about the things you have mentioned, this will come together for me. I'm am sorry that I cannot drive this to conclusion at this moment. I have trust that the many comments...
<re_irc> ... above will all come clear to me soon enough. Thanks a million to everyone for your time and attention!
<re_irc> < (@adamgreig:matrix.org)> No worries! In this case I really think it's more a problem with svd2rust, not you! Shout when you're back at it and hopefully we can get it working
<re_irc> <FredrikLL> I have tried to do the same thing in my PAC and I was not able to make it work, however I got a different problem.
<re_irc> <skye> hello!
tafa has quit [Quit: ZNC - https://znc.in]
<re_irc> <skye> does anyone have a working code for a keyboard using usbd_hid?
<re_irc> < (@ryan-summers:matrix.org)> Check out https://github.com/TeXitoi/keyberon
<re_irc> <skye> oh cool
<re_irc> < (@ryan-summers:matrix.org)> There's lots of sample projects etc. there - pretty active development on that front :)
tafa has joined #rust-embedded
<re_irc> <FredrikLL> In the PAC c-s is an optional dependency, and I added the default feature that adds rt and c-s.
<re_irc> I am now getting a rust-lld: warning: section type mismatch for .got
<re_irc> In the project I removed the feature from the PAC dependency and tried to compile.
<re_irc> < (@dirbaio:matrix.org)> FredrikLL: you can ignore that warning.
<re_irc> <skye> yeah I'm trying to make something akin to a USB rubber ducky(but not really it's a weird project) and my modified mouse jiggler demo from rp-hal isn't working
<re_irc> < (@texitoi:matrix.org)> There is some rp project using keyberon, should be listed on the github
<re_irc> <skye> I'm checking it out
<re_irc> <skye> meanwhile can someone look at my code and see if there's any glaringly obvious problems that I missed because I'm bad at embedded
<re_irc> <FredrikLL> I also get error: undefined_symbol: _critical_section_1_0_release
<re_irc> <FredrikLL> I had used c-s v1.1.1, I guess that could be it
<re_irc> < (@adamgreig:matrix.org)> FredrikLL: For this you need to enable a critical-section implementation, e.g. enable the critical-section-single-core feature on the cortex-m crate
<re_irc> <FredrikLL> : Thanks Adam, that worked.
<re_irc> <skye> can yall check my code and see if there's something I'm doing wrong
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
<re_irc> <FredrikLL> I have a set register (sets the bits that are 1 and leaves the others untouched) for my soc that I would like to be able to write to. I have been trying to add a function in the PAC for this but haven't had much luck. I am trying create a temporary register by getting the address from the normal register and adding the offset to. They writing to this register exactly as in write_with_zero(). Does it seem possible to...
<re_irc> ... do it this way?
<re_irc> <FredrikLL> I have a set register (sets the bits that are 1 and leaves the others untouched) for my soc that I would like to be able to write to. I have been trying to add a function in the PAC for this but haven't had much luck. I am trying create a temporary register by getting the address from the normal register and adding the offset to it. Then writing to this register exactly as in write_with_zero(). Does it seem possible...
<re_irc> ... to do it this way?
<re_irc> <wes_ (@wes_:matrix.org)> hello all. if i wanted to take a stab at creating a driver for a specific chip (fusb302b - https://www.onsemi.com/pdf/datasheet/fusb302b-d.pdf), what is the appropriate starting point? is there a good (easy, "simple") example that i should model?
<re_irc> <FredrikLL> in src/generic.rs:
<re_irc> I have tried to add my function there:
<re_irc> pub unsafe fn write_set<F>(&self, f: F)
<re_irc> ``` #[inline(always)]
Lumpio- has quit [Ping timeout: 264 seconds]
<re_irc> < (@adamgreig:matrix.org)> , I'm about to copy the documentation added in https://github.com/rust-embedded/cortex-m/pull/451 into the v0.7.x branch for cortex-m, but I wonder now if the rest of the changes in 451 should be copied over too?
<re_irc> < (@adamgreig:matrix.org)> I don't think they're breaking...?
<re_irc> < (@dirbaio:matrix.org)> changing "singleton!" from interrupt::free to critical-section is breaking
<re_irc> < (@adamgreig:matrix.org)> in other news, std::net::IpAddr into core is entering FCP https://github.com/rust-lang/rfcs/pull/2832#issuecomment-1370056376
<re_irc> < (@adamgreig:matrix.org)> I don't think the singleton change is in 451, isn't that https://github.com/rust-embedded/cortex-m/pull/447
<re_irc> < (@dirbaio:matrix.org)> ah yes, the crate-level docs (for the critical-section-single-core feature) are missing in 0.7.x, copying it over sounds good to me
<re_irc> < (@dirbaio:matrix.org)> all the other stuff is about the "singleton!" macro, which hasn't been changed to use c-s in 0.7.x
<re_irc> < (@adamgreig:matrix.org)> thanks, I'll just do the docs then
<re_irc> < (@adamgreig:matrix.org)> I opened an issue on svd2rust about this confusing "take()" error message, https://github.com/rust-embedded/svd2rust/issues/704
<re_irc> < (@adamgreig:matrix.org)> we made c-s optional because some platforms didn't support it at the time, but I dunno how useful that is in practice...
<re_irc> <cdetka> Wanted to close-the-loop and thank everyone for their input, especially and FredrikLL . Thanks also to , and . With the feedback you've provided me, I was able to get the PAC working. The comments from Adam about critical-section and critical-section-single-core provided the magic I needed. I'm off to learn more Rust. Thanks again everyone!
<re_irc> < (@adamgreig:matrix.org)> glad to hear it!
<re_irc> < (@dkhayes117:matrix.org)> wes_: Probably go through the driver crates listed under the WG awesome-embedded-rust drivers list https://github.com/rust-embedded/awesome-embedded-rust#driver-crates
<re_irc> <wes_ (@wes_:matrix.org)> : thank you. i'll check that out
Lumpio- has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc> < (@andrewgazelka:matrix.org)> Is it bad to ask here if I am asking a question that pertains to https://github.com/stm32-rs? Or should I always ask in "stm32-rs"?
<re_irc> <Andrew Gazelka> Hello, what is the idiomatic way to read if an alternate pin is high or low? (in particular for https://github.com/stm32-rs/stm32h7xx-hal)
<re_irc> < (@9names:matrix.org)> probably not bad, but if it's stm32-rs specific and you ask in stm32-rs, it will be easier for others to search for the answer in the channel history
<re_irc> <Andrew Gazelka> oops thought it would quote it
<re_irc> <Andrew Gazelka> I am new to Element/Matrix
<re_irc> <Andrew Gazelka> can delete that q
<re_irc> < (@9names:matrix.org)> don't worry about it
<re_irc> < (@9names:matrix.org)> oh, you asked it in both channels. please don't do that. people will spend the time answering your question in two places. please delete the one in this channel.
<re_irc> < (@9names:matrix.org)> thanks!
<re_irc> <Andrew Gazelka> yes, that's what I meant
<re_irc> <Andrew Gazelka> Element makes it look like it would quote it, but it doesn't unfortunantely
<re_irc> <Andrew Gazelka> like send a link to the q
<re_irc> <Andrew Gazelka> i apologize
<re_irc> < (@9names:matrix.org)> you can link to a message on another channel but it's very janky
<re_irc> <Andrew Gazelka> yea ¯_(ツ)_/¯ not a big deal
<re_irc> <Andrew Gazelka> "¯\_(ツ)_/¯"
<re_irc> < (@9names:matrix.org)> escaping is hard :D