<re_irc>
< (@antonok:antonok.com)> any known issues with the "thumbv7em-none-eabihf" toolchain in nightly? I have a project which has been working fine for a while (and still does in stable) but won't do any kind of visible initialization on device using the latest nightly.
IlPalazzo-ojiisa has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
<re_irc>
< (@justacec:matrix.org)> Hey guys. Been a while. I was trying to dust off an older project which was using defmt_rtt to do the logging as described on the page https://ferrous-systems.com/blog/gdb-and-defmt/. Everything used to work before but I am getting an error
<re_irc>
Info : rtt: Searching for control block 'SEGGER RTT'
<re_irc>
Info : Listening on port 8765 for rtt connections
<re_irc>
<dngrs (spookyvision@{github,cohost})> is there any mcu that does USB OTG and BLE?
<re_irc>
<dngrs (spookyvision@{github,cohost})> : I've observed stm mcus getting stuck/stubborn sometimes, independent of toolchain used. have you tried connect under reset? (hold down the board's rst button right up until flashing begins)
<re_irc>
<dngrs (spookyvision@{github,cohost})> : do you need gdb? otherwise probe-run is probably much more straightforward
<re_irc>
< (@antonok:antonok.com)> dngrs (spookyvision@{github,cohost}): oh, I've tried flashing 10+ times in the process of trying to bisect the change at first. It's 100% a nightly vs. stable issue
<re_irc>
<dngrs (spookyvision@{github,cohost})> : no idea then. Pin to an older nightly is probably your easiest way forward
<re_irc>
<dngrs (spookyvision@{github,cohost})> and/or stable of course
<re_irc>
< (@antonok:antonok.com)> mostly wanted to make sure it's reported appropriately if necessary, although I have no idea where to start in terms of the issue report đ
<re_irc>
<dngrs (spookyvision@{github,cohost})> my usual approach is "procrastinate a few weeks/months and ultimately find the issue has been resolved", HTH
<re_irc>
<dngrs (spookyvision@{github,cohost})> answering my own question - Espressif S3 seems to do both
<Darius>
STM32WB35xx has Bluetooth LE and USB
<Darius>
Nordic semi nRF52833 too
<re_irc>
<dngrs (spookyvision@{github,cohost})> STM probably works; does nrf do OTG? that'S the important part
<re_irc>
<dngrs (spookyvision@{github,cohost})> have only found nopes re: nrf52840 at least
<re_irc>
<dngrs (spookyvision@{github,cohost})> mmhm the STM also seems to not support OTG
<Darius>
ahh OTG sorry I forgot to check
<Darius>
bizarre it doesn't do OTG
<re_irc>
< (@9names:matrix.org)> do you actually need OTG though? what is your requirement?
<re_irc>
<dngrs (spookyvision@{github,cohost})> host things
<re_irc>
< (@9names:matrix.org)> okay, so you don't need OTG you just need host
<re_irc>
<dngrs (spookyvision@{github,cohost})> yeah - I was under the assumption that OTG is the closest I'll get anyway. but yes, host
<re_irc>
<dngrs (spookyvision@{github,cohost})> now though I need sleep, 6am is pushing things a little
<re_irc>
<Ralph> : thanks! but i think it'd be good if such information were in a central, official resource, where people can easily find it rather than a random (sorry, not meant in a bad way!) blog post
<re_irc>
<Ralph> : thanks! from the title of that page it wasn't obvious that it would be talking about the different abstraction layers. and e.g. for the PACs the page is using two examples which haven't been updated in several years and thus might even be abandoned?
<re_irc>
<Ralph> since i have to explain the rust embedded ecosystem to some others at the university (i did my project with Rust and none of them have a clue about it) i had to put together some "i'll tell you about embedded rust development in 5 minutes" documentation and came up with this yesterday evening:
<re_irc>
> By convention there are different "levels" of abstraction when interacting with hardware in Rust. From the bottom up (higher is preferred):
<re_irc>
1. No abstraction, know the memory location of registers and directly manipulate them (requires "unsafe" Rust, bound to specific hardware)
<re_irc>
2. Peripheral Access Crate (PAC): low-level APIs to interact with the registers of a specific device.
<re_irc>
<Ralph> since i have to explain the rust embedded ecosystem to some others at the university (i did my project with Rust and none of them have a clue about it) i had to put together some "i'll tell you about embedded rust development in 5 minutes" documentation and came up with this yesterday evening:
<re_irc>
> By convention there are different "levels" of abstraction when interacting with hardware in Rust. From the bottom up (higher is preferred):
<re_irc>
> 1. No abstraction, know the memory location of registers and directly manipulate them (requires "unsafe" Rust, bound to specific hardware)
<re_irc>
> 2. Peripheral Access Crate (PAC): low-level APIs to interact with the registers of a specific device. Usually generated from SVD files using "svd2rust" (https://github.com/rust-embedded/svd2rust/). Still requires some "unsafe" code and offers nearly no hardware abstraction, i.e. you still need to interact with the registers, but don't need to know the memory addresses.
<re_irc>
< (@korken89:matrix.org)> Do we have any atomics expert here? :D I was just trying my mental model for atomics, and did a test here: https://rust.godbolt.org/z/srTb9h7fK
<re_irc>
Am I crazy or is the DMB instruction in the wrong place?
<re_irc>
For Acquire ordering I'd expect a DMB to make data visible and then the load instruction, and for Release I'd expect the store instruction and then DMB to make it visible - but clearly I have misunderstood something in how atomics lower to cortex-m.
<re_irc>
< (@korken89:matrix.org)> I mean, why would one for example read a variable AND THEN run DMB? Is there maybe some sideeffect that atomics are relying on here?
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@christof.petig:matrix.org)> : I find the very recently announced book by Mara Bos very helpful explaining the details: https://marabos.nl/atomics/ (chapter 3). My understanding is that Acquire forces all memory operations after the acquire to remain after it, so with this reasoning the dmb asymmetry makes sense to me. But I don't consider myself an expert.
<re_irc>
< (@justacec:matrix.org)> Does probe-run via VSCode support the modification of the SVD device peripheral registers?
<re_irc>
< (@justacec:matrix.org)> Like for instance, can I jump in and quickly toggle a bit on a register through that interface in VSCode?
<re_irc>
< (@justacec:matrix.org)> I see in the documentation that there is SVD navigate and monitor, but edit seems to be missing
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
<re_irc>
< (@justacec:matrix.org)> Ok, OBE. Figured out how to get it all running with probe-run. You can edit the registers. And now RTT is working.
<re_irc>
< (@dirbaio:matrix.org)> : thread 1 does some data writes, then DMB, then release store. That ensures the release is ordered after the writes.
<re_irc>
thread 2 does the acquire load (which sees thread 1's stored value). That alone is enough to ensure thread 1's other data writes are visible to thread 2, no DMB needed. The other DMB is used to ensure later accesses aren't reordered up past the acquire load.
<re_irc>
< (@dirbaio:matrix.org)> * thread 2's
<re_irc>
< (@korken89:matrix.org)> Right, makes sense
<re_irc>
< (@korken89:matrix.org)> What seems weird though then is this
<re_irc>
< (@korken89:matrix.org)> Lets say you store a set flag with release semantics, the other thread can still read the flag as unset
<re_irc>
< (@korken89:matrix.org)> As the DMB was before the STR that stores the flag
<re_irc>
< (@korken89:matrix.org)> And on load it load LDR and the DMB
<re_irc>
< (@korken89:matrix.org)> So there is not DMB between STR -> LDR
<re_irc>
< (@korken89:matrix.org)> Am I just making this to be a problem in my head?
<re_irc>
< (@korken89:matrix.org)> Or is it guaranteed that caches etc will make the STR visible for the LDR?
<re_irc>
< (@korken89:matrix.org)> Not sure if I'm making sense with my train of thought
<re_irc>
< (@dirbaio:matrix.org)> oh hmm
<re_irc>
< (@dirbaio:matrix.org)> I think it's allowed that it reads it as unset?
<re_irc>
< (@dirbaio:matrix.org)> if it "takes time" to propagate or something
<re_irc>
< (@dirbaio:matrix.org)> then it'll assume thread 1 is not done yet, and try again later, so it shouldn't cause unsoundness
<re_irc>
< (@korken89:matrix.org)> Lets say that's the flag that keeps an mutex locked, it sounds like a data race
<re_irc>
< (@korken89:matrix.org)> Brb I must run to a meeting :(
IlPalazzo-ojiisa has joined #rust-embedded
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> : that sounds bad, the generated firmware from nightly just doesn't seem to be running at all?
<re_irc>
< (@adamgreig:matrix.org)> Ralph: yea, that could be helpful! the description on the page I linked hasn't been updated especially recently. I don't know how much it's worth emphasising the BSPs though, to me they're sort of adjacent to HALs rather than another abstraction level up
<re_irc>
< (@CyReVolt:matrix.org)> In https://github.com/oreboot/oreboot, I consider a mainboard to be "the app", replacing the BSP concept (most application SoC vendors wouldn't provide that anyway, and it's still a longish way for a full Rust OS based on PAC/HAL/...).
<re_irc>
< (@CyReVolt:matrix.org)> and I'm covering the same sorta comparison of Rust Embedded abstractions vs bare constants for MMIO registers here:
<re_irc>
< (@adamgreig:matrix.org)> : the semantics for Release ordering are only that previous loads will have happened before the store, and for Acquire that subsequent stores will happen after the load, so it seems to make sense that you'd have the dmb first in load-release and afterwards in store-acquire?
<re_irc>
< (@adamgreig:matrix.org)> so when thread A leaves its critical section and store-releases the lock back to 0, if thread B load-acquire's the lock to read 0, it's guaranteed that all the operations A did before its store-release are visible to B after its load-acquire, and any operations B does will happen after its load-acquire
<re_irc>
< (@adamgreig:matrix.org)> if B loads the lock as still-taken, before A's release back to free, then it knows A's still in a critical section and doesn't go ahead and do anything
<re_irc>
< (@adamgreig:matrix.org)> if B loads the lock as free, it must have read the value A wrote in its release to free it, and all _other_ accesses are synchronised
<re_irc>
< (@jannic:matrix.org)> So there is no way to say "wait until that write has propagate to the other core", short of a manually implemented handshake. Which is fine, because such an operation is unlikely to be actually necessary, and it could be really expensive. The other core might be in some low power state and not actually be listening on the bus, for example.
<re_irc>
< (@jannic:matrix.org)> After all, the flag is called Ordering and not guaranteed delivery.
<re_irc>
< (@adamgreig:matrix.org)> well, if you want that you can use dmb yourself, or seqcst
<re_irc>
< (@adamgreig:matrix.org)> it's just about it being delivered to memory rather than the other core necessarily reading it, I guess?
<re_irc>
< (@jannic:matrix.org)> If the other core has local caches, those are important as well.
<re_irc>
< (@jannic:matrix.org)> But the whole atomic stuff is defined in terms of some abstraction which only defines the effects, not the actual implementation.
<re_irc>
< (@jannic:matrix.org)> And as far as I know this abstraction doesn't define an absolute time reference. If you have two instructions executed on different cores, you just can't tell which one executes first, even with seqcst. All you can say that there will be some ordering, and (with seqcst) all cores will see the same ordering. But you can't specify which one.
<re_irc>
not sure how many people look at that (compared to crates.io) but it's prominently shown on the GH start page of the repo, so maybe one of the repo owners might want to do that?
<re_irc>
<Ralph> and the title in the README is still "alloc-cortex-m" đ
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
< (@omar_u8:matrix.org)> I'm tying to link a (.a extension) static library that I created from a C program, I placed the library in the project file however when ever I run the build I get a "rust-lld: error: unable to find library -lblink" error which seems to indicate that the linker cannot locate the library. I've tired adjusting the "cargo:rustc-link-search" path in the "build.rs" but I keep getting the same issue. Any clues...
<re_irc>
... for things I should try?
<re_irc>
Is there a way to return a string from a function in embedded Rust? Or do I have to pass in a reference to some buffer or so?
<re_irc>
<denbo1977> Hey rustaceans! I'm a newbie, fighting through the first steps to create a driver.
<re_irc>
< (@antonok:antonok.com)> : That's what it looks like. I do have a "panic-persist" handler set up but I'm not even getting any panic messages from that firmware.
<re_irc>
<denbo1977> : Will try this, thanks!
<re_irc>
< (@omar_u8:matrix.org)> Figured it out, turns out the file needs to be prefixed with "lib".
<re_irc>
< (@omar_u8:matrix.org)> Now there's another issue đ so i created a blinky function in C on the STM32 and verified that it works. After that I created a static library that included the function implementation so that I can import it in Rust using the FFI. Although it builds just fine, the LED fails to blink. Not sure what would be the best way to debug.
<re_irc>
< (@omar_u8:matrix.org)> The external function calls seem to appear just fine in the call stack.
<re_irc>
<dngrs (spookyvision@{github,cohost})> if we're ignoring _that_, you can probably get away with just slapping "#[repr(C)]" on your struct and sprinkling a bit of "bytemuck" on top
<re_irc>
<dngrs (spookyvision@{github,cohost})> actually you might neet "repr(packed)"
<re_irc>
(linking to second-to-latest version because latest seems to have broken docs)
<re_irc>
<dngrs (spookyvision@{github,cohost})> HOWEVER: if you actually control the receiving side of the endpoint as well, it's probably much more straightforward to go with "serde" + "postcard".
<re_irc>
< (@jamesmunns:beeper.com)> there is no safe way to do what you'd like
<re_irc>
<dngrs (spookyvision@{github,cohost})> (hmm, actually "bytemuck" seems to always use "host" endianness, so it might not be the best crate to use here.)
<re_irc>
< (@jamesmunns:beeper.com)> You can do the unsafe transmute, but then it's up to you to make sure the padding, alignment, endianness, etc.
<re_irc>
< (@jamesmunns:beeper.com)> It's also not "safe" in C, even though people do it.
<re_irc>
< (@jamesmunns:beeper.com)> (for the same reasons its unsafe in Rust)
<re_irc>
<dngrs (spookyvision@{github,cohost})> (it _is_ a bit odd though that there seems to be no straightforward "just the bytes, please" solution using serde. Am I missing something?)
<re_irc>
< (@jamesmunns:beeper.com)> I mean, earlier versions of bincode and postcard were basically that
<re_irc>
< (@jamesmunns:beeper.com)> it all falls apart as soon as you send it across the wire, and care about endianness.
<re_irc>
< (@jamesmunns:beeper.com)> I'm confused? Serde will handle things for you, recursively following the struct fields
<re_irc>
<dngrs (spookyvision@{github,cohost})> I guess the answer to my question is "a purely declarative approach probably wouldn't be powerful enough for many real world scenarios, like decoding PNG or ELF"
<re_irc>
< (@jamesmunns:beeper.com)> You don't need to structs into anything then, you just need to define each of the primitive types that serde supports ("u8", "u16", etc.)
<re_irc>
<dngrs (spookyvision@{github,cohost})> I think James is referring to BE vs LE
<re_irc>
<dngrs (spookyvision@{github,cohost})> (you could "solve" that with a feature flag; I'd argue any struct that needs both BE and LE is ill conceived, but if you really need it, field level attributes are there for youâŠ)
<re_irc>
< (@jamesmunns:beeper.com)> BE/LE are not the only reason. There are also things like types where all memory representations are not valid
<re_irc>
< (@adamgreig:matrix.org)> I think there's no reason to be afraid of "unsafe" in this case, but there's libraries to wrap this for you, I think maybe https://crates.io/crates/bytemuck can?
<re_irc>
< (@adamgreig:matrix.org)> so I just ran a demo firmware stm32f401 thumbv7em-none-eabihf and it works fine on both latest stable and latest nightly
<re_irc>
< (@adamgreig:matrix.org)> any more details about your setup or anything unusual you're doing, anything different in memory.x or anything like that? maybe output of "cargo tree"?
<re_irc>
< (@antonok:antonok.com)> that's good to know. I can try minimizing the project to try to find a smaller case that reproduces it