<re_irc> <thejpster> dirbaio: Using a heapless::Vec to also track ownership of an item. Like, I don't know, an HTTP Response. There's only one HTTP Response to an HTTP Request and you might write a function that takes ownership of the heapless::Vec containing the response to say "it's my job to deal with this response now". But you've gone and made it Copy so now you can call that function multiple times without error, when the intention...
<re_irc> ... was the function can only be called once. I just think it's bad to _automatically_ and _irrevocably_ make things Copy that aren't plain scalar values.
<re_irc> <adamgreig> stdlib says "Generally speaking, if your type can implement Copy, it should." https://doc.rust-lang.org/std/marker/trait.Copy.html#when-should-my-type-be-copy
<re_irc> <adamgreig> you're right that for things like tokens and singletons and stuff representing resources you can't make it copy, even though it consists of plain data
<re_irc> <adamgreig> but in your http case, you'd perhaps be putting non-copy Ts into the Vec<T>, so it wouldn't be copy - you choose to make the HttpResponse not Copy
<re_irc> <adamgreig> the vec would only be Copy if it contained Copy items, so that's the level at which ownership can be tracked
<re_irc> <adamgreig> for example, stdlib impls Copy for [T; N] where T: Copy, which is quite similar to the heapless::Vec case
<cr1901> Amanieu: Because everything to inline asm is Copy, that means I can safely change this function to use lateout? https://github.com/cr1901/msp430-atomic/blob/new-asm/src/lib.rs#L638-L642
<cr1901> i.e. the same register can be used for dst and out, even tho the fn sig said "* const Self"?
<re_irc> <dirbaio> Vec<u8, N> is dumb data, and dumb data should be Copy if it can
<re_irc> <dirbaio> if you want ownership semantics you should wrap the Vec in a "Response" non-Copy struct
<re_irc> <dirbaio> even without Copy, Vec is a really bad way of tracking ownership of stuff, because you can ".clone()" it :P
<re_irc> <adamgreig> only if T:Clone :P
<re_irc> <adamgreig> but yea, wrapping the vec in a newtype that's not Copy is the way to go to control ownership semantics
<re_irc> <dirbaio> yeah, but same goes for Copy
<re_irc> <adamgreig> (or putting non-Copy items inside the Vec if that happens to make more sense)
<re_irc> <dirbaio> all Clone types should also be Copy if they can
<re_irc> <dirbaio> error[E0184]: the trait `Copy` may not be implemented for this type; the type has a destructor
<re_irc> |
<re_irc> 845 | impl<T, const N: usize> Copy for Vec<T, N> where T: Copy {}
<re_irc> --> src/vec.rs:845:1
<re_irc> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Copy not allowed on types with destructors
<re_irc> <dirbaio> ohhmm whoops
<re_irc> <adamgreig> I guess that's why not
<re_irc> <dirbaio> yeah, RIP
<re_irc> <dirbaio> and you can't do stuff like "impl Drop for Vec<T, N> where T: Drop", or "impl Drop for Vec<T, N> where T: !Copy"
<re_irc> <dirbaio> shame shame shame
<re_irc> <adamgreig> did docs.rs get a cool new theme for new crates or something? the heapless page looks great
<re_irc> <dirbaio> sorted_li
<re_irc> 👌
<re_irc> nked_list
<re_irc> <adamgreig> ugh, i keep bumping in to f32 just mysteriously not having abs() on thumbv7 targets
<re_irc> <adamgreig> i can see not having trig functions and stuff, but abs isn't transcendental 🙈
<re_irc> <adamgreig> rust now has f32::to_bits() and from_bits() so I guess I could do a bit better...
<re_irc> <adamgreig> "f32::from_bits(x.to_bits() & 0x7FFF_FFFF)" nice
<re_irc> <adamgreig> compiles to "bic r0, r0, #-2147483648", I'll take it
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #rust-embedded
emerent has quit [Ping timeout: 250 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
slugbyte has quit [Remote host closed the connection]
slugbyte has joined #rust-embedded
<re_irc> <nihal.pasham> ran into an odd issue - my "no_std" code attempts to subtract with an overflow. I assumed, subtraction between 2 "u32's" cannot trigger an overflow and at runtime, we expect it to panic but that doesn't seem to be the case. It panics later on for a different reason. Is there a difference between "std" and "no_std" beahvior when it comes to "subtracting with an overflow"?
<re_irc> <nihal.pasham> * behavior
<re_irc> <nihal.pasham> ahh, figured it out. "nightly" does not produce "subtract with overflow" errors
<re_irc> <nihal.pasham> well, guess there is no explicit runtime protection (i.e. via panicking) for overflow errors.
<re_irc> <K900> You can use "checked_sub" and such
<re_irc> <K900> If you need to detect overflows
<re_irc> <K900> Generally the difference is that debug mode panics, and release mode wraps (for performance reasons)
<limpkin> hello all! is there a "clean" way to call a function from an interrupt? in my particular case i'm initiliazing a module that includes a function that should be called by the interrupt it deals with
tokomak has joined #rust-embedded
<re_irc> <ryan-summers> I'm unsure what you're asking. Interrupts can call functions just like any other rust code. Are you asking how to attach code to an interrupt handler?
<re_irc> <ryan-summers> Or are you looking for a way to "dynamically" attach some type of handler to the interrupt?
<limpkin> that's it, yes
<limpkin> i'm currently checking out the irq crate
<re_irc> <ryan-summers> Any kind of "dynamic" attachment would likely require some type of "alloc"
<re_irc> <ryan-summers> Since you'd have to probably move some "impl Fn()" into an "Option" or a "Vec" or something
<re_irc> <ryan-summers> Your best bet is to just statically call the function from the ISR
<limpkin> unfortnately the function gets created at code start as I instantiate a module
<limpkin> i thought i had found a good solution: let mut debug_class = BoardDebug::new();debug_class.init(dp.USART3, &clock_cfg); handler!(usart_interrupt = ||{debug_class.usart_interrupt();});
<limpkin> .... but as you can't borrow part of the debug_class struct.... I can't call any function on debug_class anymore
<re_irc> <ryan-summers> I think what you actually want to do is move your variables into "static mut"'s so the ISR has access to them directly
<re_irc> <ryan-summers> In essence, I think you're thinking about things backwards. You don't want to dynamically attach functions to the ISR, but rather make the objects needed accessible by the ISR
<re_irc> <ryan-summers> This is a concept that tools like RTIC automatically do for you, but you can still do it yourself using "MaybeUninit" or "static mut Option<TYPE>" that gets populated at run-time
<re_irc> <ryan-summers> Once your ISR can access an object of "BoardDebug", it can call any functions associated with that instant without any trouble
<re_irc> <ryan-summers> * instance
<re_irc> <ryan-summers> So you'd have something like:
<re_irc> #[ISR]
<re_irc> static mut MY_OBJECT: Option<BoardDebug> = None;
<re_irc> fn my_handler() {
<re_irc> <ryan-summers> So you'd have something like:
<re_irc> #[ISR]
<re_irc> fn my_handler() {
<re_irc> static mut MY_OBJECT: Option<BoardDebug> = None;
<re_irc> <ryan-summers> Essentially, your ISR just needs to be able to access your "BoardDebug" object to call associated functions, which implies that the object must have a "static" lifetime
<re_irc> <ryan-summers> Note that you _always_ have to be very careful about concurrent access of static-muts, that's why there's a ton of "unsafe" wrappers there. Tools like RTIC ensure that safety for you
<limpkin> thanks a lot for writing this
<limpkin> I was actually hoping to not do that as my interruption function actually uses mutexes, refcells on the data it needs to handle
<limpkin> so that extra mutex to access the class would be quite pointless
<limpkin> therefore if I could have borrowed just that function to pass it to the handler.... would have been neat
Amadiro has quit [Remote host closed the connection]
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #rust-embedded
<re_irc> <ryan-summers> But that function relies on internal data of "debug_class", which can mutate in other contexts
<re_irc> <ryan-summers> What you're describing is not allowed by Rust's ownership system
<re_irc> <ryan-summers> If you want to do that, you have to break apart "debug_class" into multiple objects. If you make something that you can "Move" into the interrupt context, that would work as well
<re_irc> <ryan-summers> Because then the object is only accessed in a single context
onio has joined #rust-embedded
<onio> Hi I am trying to run this command "cargo readobj --bin app -- --file-headers" that is shown on the embedded rust book page but getting error
<onio> $user_home/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-readobj: error: unknown argument '-f-output-style=GNU'
<onio> I am on Ubuntu 20.04 mate 64-bit machine
<re_irc> <9names (@9names:matrix.org)> that works for me on ubuntu 20.04, have you tried it on another project?
<onio> re_irc, No I have not. This is my first attempt of Rust
<re_irc> <9names (@9names:matrix.org)> i don't know what's causing your error, but in the meantime you can get the same data via readelf if that is installed.
<re_irc> example: (replace thumbv6m-none-eabi with your cpu type, myapp with your binary name)
<re_irc> readelf -h target/thumbv6m-none-eabi/release/myapp
<onio> When I use the command "file target/thumbv7m-none-eabi/debug/app" it shows "target/thumbv7m-none-eabi/debug/app: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped"
<re_irc> <9names (@9names:matrix.org)> sounds right
<re_irc> <9names (@9names:matrix.org)> but readelf -h will give you more information about the binary than that
<onio> readelf -h app shows the header
<onio> readelf -h target/thumbv7m-none-eabi/debug/app
<re_irc> <9names (@9names:matrix.org)> correct. that's exactly what "cargo readobj --bin app -- --file-headers" does too (when it's working)
<onio> it would be good to know why cargo-readobj does not work though
<onio> re_irc, thanks
fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
fabic has quit [Quit: Leaving]
tokomak has quit [Ping timeout: 240 seconds]
<Amanieu> cr1901: Yes, that's fine.
jackneillll has quit [Read error: Connection reset by peer]
<re_irc> <ruabmbua> Curious question: I just tried to read a memory mapped io register, and realized it is actually UB according to read_volatile. Not properly initialized memory problem. Tried in Miri which agrees.
<re_irc> Is it even possible to do that, looks like a hole in the language to me
<re_irc> <ruabmbua> We have UnsafeCell to trick the compiler mutability, volatile PTR operations to force loads and stores, but nothing that lets us treat pod types read from uninit memory as valid initialized objects
<re_irc> <K900> You want "MaybeUninit"
<re_irc> <ruabmbua> I tried, but unless I write to it first with write it is still an error
<re_irc> <K900> Under miri? I'm not sure there's a way to tell miri that some addresses are initialized by default
<re_irc> <K900> But that's basically something it needs to assume there
<re_irc> <ruabmbua> Yep under Miri. but even according to documentation it is undefined behavior? Have to check the docs again
neceve has joined #rust-embedded
<re_irc> <jannic> I'd call it a hold in the language spec in the sense that it's just out of scope. The contents of the register are not really uninitialized, but they are initialized by the hardware. The rust compiler just doesn't know that.
<re_irc> What's still important is the word "properly" in "properly initialized value of type T". The value must be legal for the given type T. As long as you only use read_volatile
<re_irc> on types like u8 or u32, where every possible combination of bits represents a legal value, you are fine. But if, for example, T is an enum and the register contains a value which doesn't map to one of enum values, you still get undefined behavior.
<re_irc> <ruabmbua> hm MaybeUninit docs explicitly state, that rules around "proper" for integer types are still unstable
<re_irc> <ruabmbua> But I guess creating a struct with a couple of integer members, then reading the struct from uninit memory is definitively out of spec / undefined
<re_irc> <ruabmbua> I guess MaybeUninit is also not really the right tool for the job. Its here to safely "hold" uninitialized data somewhere.
<re_irc> <jannic> AFAIK just read_volatile is fine, MaybeUninit is not necessary. But I don't know where it's specified. So maybe I'm wrong?
<re_irc> <ruabmbua> I guess so. But the docs could use some more explanation around the properties of "properly initialized type of T"
<re_irc> <ruabmbua> * value of type
<re_irc> <ruabmbua> And then maybe a flag to miri, to not tread reading uninitialized u32 etc... as undefined behavior
<re_irc> <ruabmbua> * treat
<onio> Hi I a now have openocd and gdb-multiarch working on STM32H743ZI nucleo board. Just wondering if there is a way to suppress the "Info : halted: PC: 0x080004d2" continually shown on both gdb and openocd
onio has quit [Ping timeout: 256 seconds]
neceve has quit [Ping timeout: 256 seconds]
cr1901 has quit [Quit: Leaving]
cr1901 has joined #rust-embedded
<re_irc> <marmrt> Is there a good resource on writing drivers for chips? I have a DAC and an ADC htat I need to control via SPI