rektide has joined #rust-embedded
<re_irc> <@g​rantm11235:m​atrix.org> I refactored my app into a single crate that has a lib and a bin. Is it possible to set the target triple when compiling the bin but not when testing the lib?
<re_irc> <@n​ewam:m​atrix.org> Nah, but you can set a cargo alias, for example: https://github.com/newAM/stm32wl-hal/blob/main/.cargo/config.toml
<re_irc> <@n​ewam:m​atrix.org> For off-target tests I can just do `cargo unit` then for on-target I can do `cargo test-aes`.
creich has quit [Ping timeout: 258 seconds]
starblue has joined #rust-embedded
starblue3 has quit [Ping timeout: 248 seconds]
creich has joined #rust-embedded
emerent has quit [Ping timeout: 258 seconds]
emerent has joined #rust-embedded
<re_irc> <@j​orgeig:m​atrix.org> bradleyharden: It outputs an image
<re_irc> <@j​orgeig:m​atrix.org> I am thinking about using Sphinx or Slate and add some customizations to generate the packet structure images - how hard that is, I have no idea haha
<re_irc> <@b​radleyharden:m​atrix.org> I've never used Slate. How does it compare to Sphinx?
<re_irc> <@b​radleyharden:m​atrix.org> Markdown is nicer than reST for simple stuff, but I could see it being limiting for more complex documents
fabic has joined #rust-embedded
<re_irc> <@j​orgeig:m​atrix.org> Slate is awesome - it's just markdown all the way and it shows examples (in my case, the packet structure) side-to-side
<re_irc> <@j​orgeig:m​atrix.org> it's true that for a full-featured doc it's not the best, though
<re_irc> <@j​orgeig:m​atrix.org> but fortunately I don't need that :D
GenTooMan has quit [Ping timeout: 245 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
dreamcat4 has joined #rust-embedded
<re_irc> <@w​illeml:m​atrix.org> Hey so I am trying to compile a crate for stm32f303 (the 303-disco board) and I have copied the mouse jiggler example from the usb-device crate (and updated it/changed it to work with latest stm32f3xx-hal) but when compiling I get the following error: ```
<re_irc> <@w​illeml:m​atrix.org> Compiling cortex-m v0.7.3
<re_irc> <@w​illeml:m​atrix.org> error[E0463]: can't find crate for `std`
<re_irc> <@w​illeml:m​atrix.org> Compiling serde v1.0.127
<re_irc> <@w​illeml:m​atrix.org> (the target is definitely installed)
<re_irc> <@a​damgreig:m​atrix.org> You maybe need to disable the std feature on serde?
<re_irc> <@w​illeml:m​atrix.org> Serde is not a dependency of my crate though, not sure which one it is of, probably one of the two usb ones (device or hid)
<re_irc> <@w​illeml:m​atrix.org> Also, building usbd-hid on its own for the same target seems to work
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 248 seconds]
<re_irc> <@r​yan-summers:m​atrix.org> Another thing you may be running into is dependency feature flags being combined (e.g. dev-dependency feature flags combined to your build)
<re_irc> <@r​yan-summers:m​atrix.org> Check out the cargo-resolver-2: https://doc.rust-lang.org/cargo/reference/resolver.html#feature-resolver-version-2 and cargo dependency resolution: https://doc.rust-lang.org/cargo/reference/resolver.html
<re_irc> <@r​yan-summers:m​atrix.org> This hits me a lot and its always really opaque for me to debug
<Amanieu> FYI the size of #[repr(C)] enums on arm-none/thumb-none targets is going to change from 4 bytes to 1 byte to match the AAPCS ABI used in C: https://github.com/rust-lang/rust/pull/87922
fabic has joined #rust-embedded
<re_irc> <@c​hrysn:p​rivacytools.io> Thanks for the warning! (I appreciate even more when C projects just don't use enums in their APIs but just pick a suitable int type and always cast)
<re_irc> <@d​irbaio:m​atrix.org> Lol won't that break stable code?
<re_irc> <@n​ihal.pasham:m​atrix.org> quick question -
<re_irc> <@n​ihal.pasham:m​atrix.org> let jump_vector: extern "C" fn() -> ! = core::mem::transmute(reset_vector);
<re_irc> <@n​ihal.pasham:m​atrix.org> ```rust
<re_irc> <@n​ihal.pasham:m​atrix.org> this line seems to be throwing the following error -
<re_irc> <@d​irbaio:m​atrix.org> Assuming repr(c) is stable which I think it is..??
<re_irc> <@d​irbaio:m​atrix.org> nihal.pasham cast through usize, or even better, make reset_vector a usize
<re_irc> <@d​irbaio:m​atrix.org> That transmute is disallowed because the fn ptr might be 64bit in other targets
<re_irc> <@d​irbaio:m​atrix.org> Or maybe it is allowed, and you forgot --target?
<re_irc> <@n​ihal.pasham:m​atrix.org> yeah, was wondering why the explicit type error
<re_irc> <@n​ihal.pasham:m​atrix.org> its likely to do with --target
<re_irc> <@n​ihal.pasham:m​atrix.org> I'm actually working on a multicrate project and one of the crates has my hardware abstraction layer. I've a `config.toml` (with target info) file in my HAL crate and I assume that should work.
<re_irc> <@n​ihal.pasham:m​atrix.org> But I guess not
<re_irc> <@d​irbaio:m​atrix.org> config.toml only applies if it's at the dir you're running cargo from
<re_irc> <@d​irbaio:m​atrix.org> If you have it in a crate dir and are building from the parent workspace dir it won't apply
<re_irc> <@d​irbaio:m​atrix.org> It's a sucky footgun
<re_irc> <@n​ihal.pasham:m​atrix.org> Hmm, ok
<re_irc> <@n​ihal.pasham:m​atrix.org> got it. thank you!
<re_irc> <@d​irbaio:m​atrix.org> 🙃
<re_irc> <@l​ulf_:m​atrix.org> you can also put it in the parent directory of your crate, and it will pick it up iirc. Not sure if thats a bug or feature
<re_irc> <@d​irbaio:m​atrix.org> Yeah.. It's working as intended
<re_irc> <@d​irbaio:m​atrix.org> It means you can't have a workspace where crate A buids for target X and crate B builds for target Y automatically
<re_irc> <@d​irbaio:m​atrix.org> Because it's "config for the cargo invocation", not "config for the workspace/crate"
<re_irc> <@d​irbaio:m​atrix.org> 🤷‍♀️
<re_irc> <@d​irbaio:m​atrix.org> config.toml accumulates cruft that should go in cargo.toml because apparently the bar for adding something there is lower..
<re_irc> <@c​hrysn:p​rivacytools.io> dirbaio: I can't speak for the compiler, but the C ABI in general (from the C side) is not as set-in-stone as I had hoped. An innocuous flag like `-fshort-enum` makes the C side's behavior flip around, and when it's on, an addition to the enum (which is otherwise ABI compatible) makes it break.
<re_irc> <@d​irbaio:m​atrix.org> Yea... I was wondering what the rust policy on that is... Maybe their hands are tied by llvm so the policy is "do whatever llvm does" dunno
<re_irc> <@d​irbaio:m​atrix.org> Or maybe it's fine because you can only observe it with unsafe..?
<re_irc> <@h​egza:m​atrix.org> We're svd2rusting some PACs for a heterogeneous computing SoC as part of a research project. We currently... generate a separate SVD for both cores, but somebody somewhere recommended that one should use a generic SVD over the heterogeneous cores if possible. The thing is our cores are 64-bit and 32-bit, but...
<re_irc> ... similar otherwise. I suppose the 32-bit vs. 64-bit addressing range is too big of a difference to be generic over for SVD, right?
<re_irc> <@f​irefrommoonlight:m​atrix.org> https://0ver.org/ - Relevant to what I've seen in Rust
<re_irc> <@r​yan-summers:m​atrix.org> I absolutely love some of the examples they provide - some projects are lik 12 years old and have no major releases
<re_irc> <@j​orgeig:m​atrix.org> particularly in Rust embedded, I love the humble feeling, but many 0.x things are more stable than software from manufacturers, particularly HALs
<re_irc> <@j​orgeig:m​atrix.org> I loved it when I got my STM32WL nucleo boards and run the LoRa examples
<re_irc> <@j​orgeig:m​atrix.org> only to get SegFault after the first message
<re_irc> <@j​orgeig:m​atrix.org> "fully working LoRa stack!"
<re_irc> <@c​hrysn:p​rivacytools.io> But it is really easy to fall into that pattern. You do a 0.1, scrap it, do a 0.2, and by the time the 0.4 is flying, it's really just small changes any more, so you do a 0.4.1, 0.4.2 ... and well it's not like you planned for this to be the final API, but you're not breaking it any more either, so *shrug*
<re_irc> <@f​irefrommoonlight:m​atrix.org> Are ST's SVD's 1.0?
<re_irc> <@j​orgeig:m​atrix.org> <name>STM32WLE5_CM4</name>
<re_irc> <@j​orgeig:m​atrix.org> <description>STM32WLE5_CM4</description>
<re_irc> <@j​orgeig:m​atrix.org> <version>1.4</version>
<re_irc> <@j​orgeig:m​atrix.org> I had to apply quite some patches to that SVD to create the PAC 😅
<re_irc> <@f​irefrommoonlight:m​atrix.org> I really want to start a LorA project, but... don't have an idea yet :(
<re_irc> <@f​irefrommoonlight:m​atrix.org> What are you using it for?
<re_irc> <@j​orgeig:m​atrix.org> we are building remote asset monitoring products, particularly for areas without cell coverage (very common here in Asia) - we collect data via LoRa and then use a satellite connection to move it to our backend
<re_irc> <@j​orgeig:m​atrix.org> think things like agriculture, mining, aquaculture, logistics, etc.
<re_irc> <@f​irefrommoonlight:m​atrix.org> THat's awesome
<re_irc> <@j​orgeig:m​atrix.org> with a bit of luck we'll have our first satellite payload floating around end of next year
<re_irc> <@f​irefrommoonlight:m​atrix.org> What sorts of readings?
<re_irc> <@j​orgeig:m​atrix.org> programmed in Rust of course :D
<re_irc> <@j​orgeig:m​atrix.org> right now we focus on agriculture beacuse it's a massive market here in Asia, so basically soil conditions, weather, solar exposure, that kind of thing
<re_irc> <@f​irefrommoonlight:m​atrix.org> Dude, outstanding
<re_irc> <@j​orgeig:m​atrix.org> thanks! 🚀🚀
<re_irc> <@d​irbaio:m​atrix.org> Rust in orbit? :D
<re_irc> <@d​irbaio:m​atrix.org> 🚀!!, literally
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<re_irc> <@w​illeml:m​atrix.org> dirbaio: The lack of oxygen might make that difficult ;)
jasperw has quit [Ping timeout: 258 seconds]
jasperw has joined #rust-embedded
<re_irc> <@w​illeml:m​atrix.org> All jokes aside, that project does seem awesome, especially that it involves a satellite running rust code!
<re_irc> <@w​illeml:m​atrix.org> ryan-summers: Using cargo resolver 2 seems to work (at least, I get past building serde and get some errors that I am expecting and know how to fix)
<re_irc> <@r​yan-summers:m​atrix.org> resolver 1 has a super problematic "feature" where feature flags of `dev-dependencies` and `dependencies` get unified
<re_irc> <@r​yan-summers:m​atrix.org> Which can result in all kinds of `no-std` incompatibilities
<re_irc> <@w​illeml:m​atrix.org> Very good to know, thank you, TIL about resolver 2 existing, actually TIL about different resolver versions
<re_irc> <@w​illeml:m​atrix.org> Any reasons not to use resolver 2 on new crates?
<re_irc> <@d​irbaio:m​atrix.org> willeml: Resolver 2 has no effect on lib crates, the end user has to enable it in their bin crate
<re_irc> <@d​irbaio:m​atrix.org> It's not a reason to *not *put it though
<re_irc> <@d​irbaio:m​atrix.org> And It'll be the default in rust 2021
<re_irc> <@d​irbaio:m​atrix.org> So yay :D
<re_irc> <@w​illeml:m​atrix.org> Oh cool
<re_irc> <@j​orgeig:m​atrix.org> bradleyharden: revisiting this note - by any chance did you compare binary size vs the macros approach? I am interested in anything that makes binaries smaller 😀
<re_irc> <@b​radleyharden:m​atrix.org> Before we first merged the new `gpio` module, we did compare code size between the old, macro approach and the new, trait approach. I remember finding that it was important to mark most functions with `#[inline]` to get it to compile down to a few instructions.
<re_irc> <@b​radleyharden:m​atrix.org> In general, I wouldn't expect the trait approach to reduce code size, only match the macro approach. The compiler will monomorphize everything for each different type parameter. But that would happen for the macro approach too, since they are unique types instead.
<re_irc> <@b​radleyharden:m​atrix.org> If you want to reduce code size, I think the best way is probably to create non-generic functions that you call from generic functions. But there again, I think the trait approach is better than the macro approach. You can define associated constants on your traits that will act as arguments to the...
<re_irc> ... non-generic functions.
<re_irc> <@b​radleyharden:m​atrix.org> We should probably revisit the code-size comparison for the modules build on `gpio`. But it's not apples-to-apples there, because the more recent modules are more feature-rich.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Regrettably for STM32, I don't know if there's a way to avoid macros for GPIO, due to the multiple nearly-identical (But not derefable to one) port setup
<re_irc> <@d​irbaio:m​atrix.org> If you fix the PAC.. :)
<re_irc> <@f​irefrommoonlight:m​atrix.org> Touche
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm happy with the GPIO API I have, but the internal code's a mess
<re_irc> <@f​irefrommoonlight:m​atrix.org> Oh my: https://github.com/embassy-rs/embassy/blob/master/embassy-stm32/src/gpio.rs
<re_irc> <@f​irefrommoonlight:m​atrix.org> Very nice
<re_irc> <@n​ewam:m​atrix.org> dirbaio: What can be done at the PAC level?
<re_irc> <@n​ewam:m​atrix.org> Just special-casing GPIOs?
<re_irc> <@n​ewam:m​atrix.org> I kind of gave up on using the PAC for GPIOs and DMAs 😕
<re_irc> <@d​irbaio:m​atrix.org> embassy has a stm32 pac made from scratch, not from svd's
<re_irc> <@d​irbaio:m​atrix.org> well, kinda: regblocks are extracted from svd's to yaml, then manually fixed up
<re_irc> <@f​irefrommoonlight:m​atrix.org> Having all GPIOs deref to the same would do it
<re_irc> <@n​ewam:m​atrix.org> ah, I was going to say that's more data entry than I would care for
<re_irc> <@f​irefrommoonlight:m​atrix.org> Perhaps at the expense of exposing some functionality that isn't really there for all ports
<re_irc> <@d​irbaio:m​atrix.org> patched SVDs from stm32-rs are mostly right, then all the goofs can easily be fixed manually
<re_irc> <@d​irbaio:m​atrix.org> there's only 2 gpio regblock versions across all stm32 families, v1 and v2
<re_irc> <@d​irbaio:m​atrix.org> so we just have 2 yamls
<re_irc> <@d​irbaio:m​atrix.org> so all gpio ports in a chip are the same regblock
<re_irc> <@d​irbaio:m​atrix.org> and also importantly, all stm32 families have the same regblock (SVDs have inconsistencies)
<re_irc> <@d​irbaio:m​atrix.org> so you can then write a single HAL for all STM32 families
<re_irc> <@d​irbaio:m​atrix.org> you just have to impl GPIOv1 and GPIOv2
<re_irc> <@f​irefrommoonlight:m​atrix.org> The stm32-rs patched YAMLs for GPIO work great across the whole lineup, and the STM32 GPIO API is fine, but you run into issues A: The PAC GPIO structs don't all deref to the same type despite being near identical, and B: Pin abstractions are useful, but this isn't how the regs are set up
<re_irc> <@f​irefrommoonlight:m​atrix.org> Issue B is the big one, and why GPIO is a unique pain point
<re_irc> <@d​irbaio:m​atrix.org> so it's `embassy-stm32`, instead of `embassy-stm32f1`, `embassy-stm32f3`, `embassy-stm32f4`, `embassy-stm32f7`, `embassy-stm32h7` blah blah
<re_irc> <@b​radleyharden:m​atrix.org> ATSAMD chips have a way to atomically change the configuration for each pin, so maybe that's a big advantage for us
<re_irc> <@d​irbaio:m​atrix.org> yeah nrf's too
<re_irc> <@d​irbaio:m​atrix.org> stm32 is the stupid one here
<re_irc> <@d​irbaio:m​atrix.org> embassy just does critical sections
<re_irc> <@d​irbaio:m​atrix.org> so you don't have to pass `&mut moder` and co to everything
<re_irc> <@d​irbaio:m​atrix.org> not zero-cost.. but almost-zero-cost, way worth the simpler API imo
<re_irc> <@f​irefrommoonlight:m​atrix.org> I've stolen dirbaio's approach there to avoid the extraneous args
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm using this style API:
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> let mut scl = Pin::new(Port::B, 6, PinMode::Alt(4));
<re_irc> <@f​irefrommoonlight:m​atrix.org> Allowed by the messy, macro-based code I mentioned. Hopefully shouldn't require much maintenance though, since the GPIO functionality is clean-cut. IIRC embassy handles configuring GPIO in peripheral modules when possible
<re_irc> <@f​irefrommoonlight:m​atrix.org> (Which I'm still considering...)
<re_irc> <@b​radleyharden:m​atrix.org> firefrommoonlight, just out if curiosity, it looks like each pin in that API is a couple bytes, right? One of the things I really like about the type-level approach is that a pin is zero-sized, so the resulting code should be the same as the totally untracked way you would write it in C. Still might not be...
<re_irc> ... the best approach for you, but I thought I would point that out.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Correct - the pin struct stores an enum and u8, which is not as nice as 0-sized. It's a tradeoff for API in this case
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> /// Represents a single GPIO pin. Allows configuration, and reading/setting state.
<re_irc> <@f​irefrommoonlight:m​atrix.org> pub struct Pin {
<re_irc> <@f​irefrommoonlight:m​atrix.org> pub port: Port,
<re_irc> <@b​radleyharden:m​atrix.org> You must not track pin mode then, right?
<Lumpio-> One other nice thing besides zero size is that setting/reading the pin usually takes very few calculations if it's a const
<re_irc> <@f​irefrommoonlight:m​atrix.org> Correct - mode is handled via registers only.
<re_irc> <@n​ewam:m​atrix.org> I did this for the stm32wl pins: `struct Pin<const BASE: usize, const N: u8> {}`
<re_irc> <@n​ewam:m​atrix.org> Have yet to do any serious size/performance evaluations though.
<re_irc> <@b​radleyharden:m​atrix.org> newam, the type-level approach we use would be way easier to express with full const generics, but the current version has big limitations for one of the trait patterns we use. I look forward to the day we can switch
<re_irc> <@f​irefrommoonlight:m​atrix.org> Does that end up 0-size?
<re_irc> <@n​ewam:m​atrix.org> firefrommoonlight: Ok, I checked, zero runtime size.
<re_irc> <@d​irbaio:m​atrix.org> newam: fun, how do you do degraded/type-erase pins? like AnyPin
<re_irc> <@n​ewam:m​atrix.org> Have not done that part yet, still thinking about it.
GenTooMan has quit [Ping timeout: 256 seconds]
GenTooMan has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 244 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@n​ewam:m​atrix.org> Before I do data entry does anyone know if there is a `#![no_std]` crate with raw elliptic curve values?
fabic has quit [Ping timeout: 272 seconds]
<re_irc> <@j​atsekku:m​atrix.org> Hey, guys I bet it's kind of dead-brain problem, but I don't know how to enable cargo flash to actually flash my mcu, I got:
<re_irc> <@j​atsekku:m​atrix.org> Error Failed to open the debug probe.
<re_irc> <@j​atsekku:m​atrix.org> Working with stlink v2, arch linux, udev rules has been added
<re_irc> <@n​ewam:m​atrix.org> does the probe show up in `lsusb`?
<re_irc> <@j​atsekku:m​atrix.org> yes
<re_irc> <@n​ewam:m​atrix.org> and `cargo flash --version` is 0.11.0?
<re_irc> <@j​atsekku:m​atrix.org> yes
<re_irc> <@n​ewam:m​atrix.org> What does it show if you add `--log trace`?
<re_irc> <@j​atsekku:m​atrix.org> TRACE probe_rs::probe::cmsisdap::tools > Trying device Bus 001 Device 004: ID 8087:0a2a [0/135]
<re_irc> <@j​atsekku:m​atrix.org> TRACE probe_rs::probe::cmsisdap::tools > Error opening: Access
<re_irc> <@j​atsekku:m​atrix.org> TRACE probe_rs::probe::cmsisdap::tools > Trying device Bus 001 Device 003: ID 5986:0670
<re_irc> <@j​atsekku:m​atrix.org> TRACE probe_rs::probe::cmsisdap::tools > Error opening: Access
<re_irc> <@n​ewam:m​atrix.org> huh, looks like udev may not be working as expected
<re_irc> <@j​atsekku:m​atrix.org> yeah, apparently
<re_irc> <@n​ewam:m​atrix.org> ```bash
<re_irc> <@n​ewam:m​atrix.org> sudo udevadm control --reload-rules
<re_irc> <@n​ewam:m​atrix.org> if you just added the rules maybe it needs a refresh ^?
<re_irc> <@n​ewam:m​atrix.org> sudo udevadm trigger
<re_irc> <@j​atsekku:m​atrix.org> hmm, i was refrashing it, but now I do it again and it works ! Thank you very much!
<re_irc> <@n​ewam:m​atrix.org> Woo! No problem, happy to help!
GenTooMan has quit [Ping timeout: 256 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@a​lmindor:m​atrix.org> does anyone know if it's possible to tell rust-analyzer to use a feature with a specific crate? I've got an issue where the crate requires a feature choice (it's a board model choice) with no default so it trips RA for me
<re_irc> <@n​ewam:m​atrix.org> almindor: Yup, like this: https://github.com/newAM/stm32wl-hal/blob/main/.vscode/settings.json
<re_irc> <@a​lmindor:m​atrix.org> > Yup, like this: https://github.com/newAM/stm32wl-hal/blob/main/.vscode/settings.json
<re_irc> <@a​lmindor:m​atrix.org> Thanks!
zBeeble42 has joined #rust-embedded
zBeeble has quit [Ping timeout: 272 seconds]
jasperw has quit [Ping timeout: 252 seconds]