cr1901 has quit [Read error: Connection reset by peer]
cr1901_ has joined #rust-embedded
cr1901_ is now known as cr1901
<conplan>
do you know how to open these software packs?
<re_irc>
< (@9names:matrix.org)> i think they're just zip files
<conplan>
9names: thanks. It worked... is the lib.rs file generated the only thing I need
<cr1901>
9names: while you're around. This is for a client, so I can't share code, but... does rpi-rs have provisions for getting the pin assignments from a C header (for mixed Rust and C projects)?
<cr1901>
for a custom rp2040* board
<re_irc>
< (@9names:matrix.org)> No, we don't have anything like that
<re_irc>
< (@9names:matrix.org)> I don't think anyone in the group has done any interop with the C SDK so it hasn't come up
<cr1901>
9names: Well, me doing my part of the code in Rust is the compromise. I'm not going to force my client to learn Rust right now. I can ad-hoc a solution. Will dynamically giving the rp-rs hal pin assignments be feasible if I write code for it?
<re_irc>
< (@duskmoon:matrix.org)> conplan: You can use "form" to convert "lib.rs" to separate files organized by module. A simple usage could be like this:
<re_irc>
< (@duskmoon:matrix.org)> Also, I just tried the "esp-pacs" kind of method of using xtask to manage "svd2rust" versions. If anyone is maintaining pac, this repo might be of interest. Looking for advice.
<re_irc>
< (@jessebraham:matrix.org)> Glad to see somebody else found it useful! 😁
causal has joined #rust-embedded
<re_irc>
< (@9names:matrix.org)> cr1901: i think that should be fine. The constructor for DynPin is private so you can't currently do it, but since it's already marked as unsafe we could probably relax that restriction to allow you to manually construct a pin by bank, id and type.
<re_irc>
There's no drop impl so it shouldn't change modes without you explicitly asking for it - up to you to get it right.
<re_irc>
< (@9names:matrix.org)> or, maybe we could make DynRegisters public?
<re_irc>
all the other required structs are already public...
<re_irc>
< (@duskmoon:matrix.org)> There are two kinds of crate: a binary and a lib. The former needs "main.rs" and the latter needs "lib.rs"
<re_irc>
< (@jamesmunns:beeper.com)> If you don't declare the modules with a "mod foo", cargo won't compile it
<re_irc>
< (@jamesmunns:beeper.com)> (it works the same for main rs files in a binary)
<conplan>
interesting. is 'pub' considered a module declaration
<re_irc>
< (@duskmoon:matrix.org)> "pub" means "public"
<re_irc>
< (@grantm11235:matrix.org)> "mod foo;" declares a module called foo, "pub mod foo;" does the same thing, and it makes the module visible to other crates
<re_irc>
< (@adamgreig:matrix.org)> (you can also have a main.rs and a lib.rs, which means you have two crates in a single package)
<re_irc>
< (@adamgreig:matrix.org)> (or indeed multiple main files, one per binary crate, all in the same package)
<re_irc>
< (@adamgreig:matrix.org)> (each Cargo.toml file gives you one package, which can have zero or one library crates and zero or more binary crates)
<re_irc>
< (@adamgreig:matrix.org)> (...except Cargo.tomls that give you a workspace that contains multiple packages...)
<re_irc>
< (@jamesmunns:beeper.com)> there are a couple rules it follows
<conplan>
jamesmunns: thanks. this is what I was looking for
<re_irc>
< (@jamesmunns:beeper.com)> but basically, if you declare "mod foo", it is going to look for "foo.rs" in the same folder, or a subfolder called "foo/" with a file called "foo/mod.rs"
<re_irc>
< (@jamesmunns:beeper.com)> Don't thank me, it's the same link posted above :D
<re_irc>
< (@jamesmunns:beeper.com)> might be useful
<conplan>
jamesmunns: using i3. based
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
creich has joined #rust-embedded
dc740 has joined #rust-embedded
conplan has quit [Remote host closed the connection]
conplan has joined #rust-embedded
<conplan>
hello. So I've been continuing with my work on the MSP432P4111-pac. When I try to take the compiler throws an error saying 'Peripherals is not an iterator' does anyone have any idea whit might be going on?
<re_irc>
< (@jamesmunns:beeper.com)> "Peripherals.take()" instead of "Peripherals::take()" maybe?
<conplan>
no dice. it's suppose to be Peripherals::take()
<re_irc>
< (@duskmoon:matrix.org)> : In my mind it is defined as "impl Peripherals { pub fn take() -> Option<Self> ..."
<re_irc>
< (@jamesmunns:beeper.com)> (sorry yes, i was suggesting to make sure you are using ::take(), didn't word it very clearly :D)
<conplan>
duskmoon: that's correct. speaking of the code, when I split it off using form, it packed all the code into a single line. is there tool to cause it to lay out in a more readable format?
<conplan>
maybe there is something wrong with the output of svd2rust
<re_irc>
< (@jamesmunns:beeper.com)> cargo fmt
<re_irc>
< (@jamesmunns:beeper.com)> You can just run cargo fmt on the generated pac
<conplan>
thanks
<conplan>
much better
<conplan>
do you have to call your own pac if you are writing an example?
<re_irc>
< (@duskmoon:matrix.org)> maybe yes
<conplan>
interesting. can I write a Cargo.toml file for the example specifically?
<re_irc>
< (@duskmoon:matrix.org)> I think this may be helpful
<re_irc>
< (@duskmoon:matrix.org)> You can take a look at the "examples" section
<re_irc>
<Tim Yates> Hi folks, I'm working on an app (and hopefully eventually an embedded-hal driver) that uses SPI to configure a TMC2130 stepper driver. It's got some particular requirements for the CS line—it has to come up between every 40-bit datagram—and I can't figure out a way to make it work other than separately handling the CS pin as a GPIO.
<re_irc>
Originally asked in the context of the RP2040 HAL, but if I'm ever going to write a driver it will need to use the generic API. So I'm wondering if this is the accepted solution, or if there are better ways to handle CS in embedded-hal. https://github.com/rp-rs/rp-hal/issues/480
GenTooMan has quit [Ping timeout: 272 seconds]
<re_irc>
< (@jannic:matrix.org)> When I read that ticket, I remembered that there was a discussion in this channel a while ago, about what CS modes the embedded-hal abstraction should support. That's why I referred Tim Yates to this channel.
<re_irc>
< (@adamgreig:matrix.org)> the driver now provides a "transaction" that asserts CS, runs your closure (which can read/write multiple bytes), then deasserts CS
<re_irc>
< (@adamgreig:matrix.org)> it would be great to hear if that should work for your use case as the hope is that it's much more generically useful now
<re_irc>
< (@jannic:matrix.org)> So that "transaction" should really guarantee that CS gets deasserted, even if two transactions to the same device happen directly after each other, right?
<re_irc>
< (@adamgreig:matrix.org)> yes, it's a requirement on implementations of the embedded-hal traits (i.e. the HALs) that CS is asserted, transaction runs, then CS is de-asserted
<re_irc>
< (@adamgreig:matrix.org)> the traits _don't_ specify how long you necessarily have to wait between transactions, but _do_ specify that the bus must be flushed after the closure finishes (i.e. you can't still have some data waiting in the queue bfore deasserting CS), so your driver can always do its own delay between transactions if required
<re_irc>
< (@adamgreig:matrix.org)> but the CS behaviour is now much more clearly defined
<re_irc>
< (@adamgreig:matrix.org)> there's also the SpiBus traits which are direct bus access and don't involve CS at all, so you can take exclusive use of a bus and handle CS via an OutputPin yourself
<re_irc>
< (@jannic:matrix.org)> (Tim Yates this doesn't help you immediately, as rp2040-hal doesn't implement that part of the alpha API yet...)
<re_irc>
<Tim Yates> Yeah, I've been working on a few boards but none of them are fully up-to-date with the 1.0.0-alphas, so I haven't been paying much attention. It does seem like that solves the issue in the long term, and timing between transactions should be manageable.
<re_irc>
< (@adamgreig:matrix.org)> (one of the other motivations for the redesign is it makes it sensible to allow sharing the spi bus between multiple drivers)
<re_irc>
<Tim Yates> Yeah it seems to make a lot more sense in general. I'll work with what I've got for now, and once the ecosystem is a little more updated I can hopefully get to work on that driver.
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 272 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 260 seconds]
hwj has joined #rust-embedded
hwj has quit [Ping timeout: 272 seconds]
<conplan>
I'm still unable to solve the peripherals is does not implement triat iterator
<re_irc>
< (@datdenkikniet:matrix.org)> are you sure you've imported the correct Peripherals? Does "unsafe { Peripherals::steal() } " compile?
<re_irc>
< (@jessebraham:matrix.org)> I think you have to enable the "critical-section" feature now? I remember running into that last week but I don't quite recall if that was the solution or not...
<re_irc>
< (@jessebraham:matrix.org)> (for that PAC, that is)
<re_irc>
< (@datdenkikniet:matrix.org)> +for a full explanation
hwj has joined #rust-embedded
<conplan>
thanks. I tried to compile with steal() and now unwrap() isn't working
<re_irc>
< (@datdenkikniet:matrix.org)> once you've enabled the feature you can use "take". "steal" is the unsafe, unchecked alternative (that you usually want to avoid)
<conplan>
but "steal" will not work
<conplan>
how do I declare a feature for the crate I am compiling? I don't have a separate cargo.toml for my examples
<re_irc>
< (@datdenkikniet:matrix.org)> Have you looked at the signature of "steal", and the safety invariants it requires you to uphold?
<re_irc>
< (@datdenkikniet:matrix.org)> * "steal" (and compared it to "take"),
<conplan>
ahh.. it only returns self, not option<self>
<re_irc>
< (@datdenkikniet:matrix.org)> IDK which part of that is generated by "svd2rust" (if any), but it's missing an optional dependency on critical-section (https://crates.io/crates/critical-section)
<conplan>
it's saying that critical section does not implement critical section
<conplan>
feature
<re_irc>
< (@adamgreig:matrix.org)> you need to provide an implementation of the critical-section traits, which is usually provided by your architecture crate like cortex-m
<re_irc>
< (@adamgreig:matrix.org)> so try "cortex-m = { version = "0.7.6", features = ["critical-section-single-core"] }"
dc740 has quit [Remote host closed the connection]
<conplan>
datendkikniet: somehow it compiled. I'm still not totally clear on how that worked...
<conplan>
interesting... this doesn't implement split. is that typical of a pac?
<conplan>
writing stuff without a hal is weird...
<conplan>
are optional dependencies actually optional?
<re_irc>
< (@grantm11235:matrix.org)> conplan: PACs don't have a split method. That comes from a HAL, for example to transform a PAC "GpioA" struct into multiple HAL structs (one for each gpio pin)
<cr1901>
In the case of the critical-section dep, you're expected to roll your own way to safely share peripherals w/o that crate
<cr1901>
_if_ you don't include that optional dependency. There are ways to do that (Peripherals::steal()), but it's unsafe code. Best to include the critical-section dep
<conplan>
jamesmunns: last night you sent me a video about ~roughly building a hal. can you please send it to me again? I can't seem to find it no your youtube
<re_irc>
< (@CyReVolt:matrix.org)> : Underrated - needs more sharing and liking! 🥳🧡🦀
<re_irc>
< (@CyReVolt:matrix.org)> Oh and that reminds me of a tool that didn't work for me (see issues):
<re_irc>
This is supposed to generate SVD from DTS (Device Tree Source). Written in Python, unfortunately. The platforms I'm dealing with usually have medicore to zero docs, so any tool would really help.