<re_irc>
It's a farily recent addition to embassy, sorry for so little docs! feel free to ping me with questions
<re_irc>
<dirbaio> sorry guys I couldn't attend the meeting, catching up with the spi thing now
<re_irc>
<dirbaio> GrantM11235: yes and no, there's no trait for it, but bus-sharing-providers could do the "configure" closure trick from rahix and the user could call hal-specific methods from there
<re_irc>
<dirbaio> I think it's best to leave it to HALs for now
<re_irc>
<dirbaio> maybe we can have set_mode, set_frequency traits in the future (but the time traits stuff is blocking for freq probably heh)
<re_irc>
<dirbaio> GrantM11235: done, nice catch!
<re_irc>
<dirbaio> GrantM11235: why? :D
rardiol has quit [Ping timeout: 240 seconds]
<re_irc>
<GrantM11235> dirbaio: I like the configure closure trick, but I don't think it will work for reconfiguring the word size with hals that use a word type parameter
<re_irc>
<dirbaio> why?
<re_irc>
<dirbaio> the HAL would support all word szies on the same struct at the same time
<re_irc>
impl SpiBus<u8> for Spi {..}
<re_irc>
impl SpiBus<u16> for Spi {..}
<re_irc>
<dirbaio> struct Spi {..}
<re_irc>
impl SpiBus<u32> for Spi {..}
<re_irc>
<dirbaio> a driver could do "where T: SpiDevice, T::Bus: SpiBus<u8> + SpiBus<u16>"
<re_irc>
<dirbaio> and even mix word sizes in the same transaction
<re_irc>
<dirbaio> spi.transaction(|bus| {
<re_irc>
bus.write(&my_u8_buf);
<re_irc>
bus.write(&my_u16_buf);
<re_irc>
});
<re_irc>
<GrantM11235> Most HALs do "impl<Word> SpiBus<Word> for Spi<Word>"
<re_irc>
<GrantM11235> So if you have a "&mut Spi<u8>" there is no way to turn it in to anything that impls "SpiBus<u16>"
<re_irc>
<dirbaio> then hals shouldn't do that :P
Guest2 has joined #rust-embedded
tokomak has joined #rust-embedded
<re_irc>
<vhakulinen> I asked the same question on rust science channel, but going to throw this here too.
<re_irc>
Has anyone used nalgebra on embedded systems? When ever I'm trying to use it (create a matrix/vector and/or accessing it's data), it causes hard fault on a cortex m4 system. My setup includes a c++ sdk to which the rust code is statically linked to, and I dont have access to the SDK's source code so debugging it is quite a challenge (+ I'm not that experienced on it), so I can't really get to the source of the issue from the...
<re_irc>
... debugger.
<re_irc>
<burrbull> Using of nalgebra should not be problem if you are using static allocations. But linking with c++. Too many reasons to fail
<re_irc>
<burrbull> Any way you try to catch HardFault exception with cortex-m-rt
<re_irc>
<vhakulinen> The SDK provides that exception handler, but I'm not really sure what to do in the debugger once I get there... From what I managed to gather, it seems that there is another exception before the hard fault (bus fault?).
<re_irc>
<burrbull> So you link rust to c++, not c++ to rust
<re_irc>
<vhakulinen> Yes
<re_irc>
<vhakulinen> Also, the static library that is compiled from rust has some conflicting compiler builtins (intrinsics?) that I need to strip out in order to make the linking part work.
<re_irc>
<burrbull> Have you tried to test your library on host machine?
<re_irc>
<vhakulinen> I have used nalgebra before, but not the static library I'm compiling to the target. I guess thats up next, with some similar c++ setup
<re_irc>
<rahix> vhakulinen: can you narrow it down to a particular function call? then you can look at the assembly, I think that might give some clues
<re_irc>
<rahix> the intrinsics you mentioned could also play a role, depending on how broken that c++ blob is
<re_irc>
<vhakulinen> I just did some testing and as soon as I add nalgebra types (the storage or matrix), the function fails to "start" (e.g. if I step through in debugger, I get to the start of the function, but I guess the function stack fails to load or something like that)
<re_irc>
<vhakulinen> regarding intrinsics, after I mentioned it here I tried and now it links fine without stripping them. Perhaps I changed some linking options at some point
<re_irc>
<rahix> be careful with the debugger, it does not always tell the truth
<re_irc>
<vhakulinen> +that made it work
<re_irc>
<rahix> you mean adding a local variable of some nalgebra type to your function?
<re_irc>
<vhakulinen> Yea, I've noticed that its a bit on-and-off over the jlink debugger. But either way, if I have a line like "let a = 10" as a first line of code in the function body, it doesn't get there if there is that na storage/matrix stuff when stepping through. Too mad that I don't know assembly that well the make any guesses on what its doing at that point
<re_irc>
<adamgreig> if it's a bus fault you should be able to isolate it to a particular memory access and hopefully then work out what that's coming from
<re_irc>
<adamgreig> is it possible you're just overflowing the stack or something like that?
<re_irc>
<adamgreig> especially with nalgebra it might be easy to accidentally create a very large data structure on the stack
<re_irc>
<rahix> that is also what it sounds like to me...
<re_irc>
<adamgreig> it would be instructive to see what SP is when it faults, for example
<re_irc>
<ryan-summers> Doesn't a lot of context get pushed into various debug registers for cortex-m?
<re_irc>
<adamgreig> yep, that memfault blog post ^ covers them nicely
<re_irc>
<ryan-summers> I remember it being super opaque, but the data _is_ available somewhere
<re_irc>
<vhakulinen> I've been browsing that memfault article, but I guess its time to read it through again. Regarding overflowing the stack: is that possible with statically allocated things? As far as I've understood it, if the program loads its shouldn't overflow because everything is already loaded into memory, right?
<re_irc>
<adamgreig> you're always going to be using _some_ stack just for function calls and function-local variables
<re_irc>
<ryan-summers> Depends - are you using flip-link?
<re_irc>
<adamgreig> if your large data structures are statically allocated that's OK
<re_irc>
<adamgreig> but it's very easy to accidentally stack allocate some large objects, and then copy them into statics
<re_irc>
<ryan-summers> If you're not using flip-link, large static variables still make stack overflows more dangerous
<re_irc>
<ryan-summers> Or rather, more likely, since you effectively have less stack
<re_irc>
<adamgreig> yea, but if you're already faulting it's not going to change that (maybe it will fault slightly earlier)
<re_irc>
<adamgreig> if you have a debugger attached, look at the sp register after the fault, see if it's below the start of ram
<re_irc>
<adamgreig> or single-step through the faulting region and watch sp
<re_irc>
<adamgreig> it might be something else besides a stack overflow of course! just a thought
<re_irc>
<adamgreig> the memfault blog procedure should narrow down what caused the fault, if it's a memory access to just before the start of RAM then it was probably a stack overflow
<re_irc>
<vhakulinen> Okay, thanks for the tip. I'll have another look at it 👍️
Guest2 has quit [Ping timeout: 256 seconds]
jringstad__ has joined #rust-embedded
Amadiro has quit [Ping timeout: 260 seconds]
jringstad__ has quit [Remote host closed the connection]
Amadiro has joined #rust-embedded
<re_irc>
<omar_u8> I was trying today to execute semi hosting (and also ITM) examples on the Stm32f401re, however when trying to build the examples I get a rust-lld error regarding interrupt vectors being missing. I’ve done some searching about similar errors and tried a few things to no avail. Any leads where I should look?
<re_irc>
<ryan-summers> That's usually caused by the device not being properly specified, isn't it?
<re_irc>
<ryan-summers> Are you specifying your exact chip for the HAL? E.g. enabling the "stm32f401re" feature for the HAL?
<re_irc>
<omar_u8> in the cargo.toml?
<re_irc>
<omar_u8> [dependencies.stm32f4xx-hal]
<re_irc>
version = "0.10"
<re_irc>
features = ["rt", "stm32f401"]
<re_irc>
<omar_u8> Thats what I have in there.
<re_irc>
<ryan-summers> This is a pretty common "getting-setup" issue from what I remember and is usually w.r.t feature and device selection, but my memory isn't perfect here
<re_irc>
<ryan-summers> I think it means that somehow "cortex-m-rt" isn't getting pulled in?
<re_irc>
<omar_u8> ryan-summers: Yeah, at least the error seems to indicate that.
<re_irc>
<ryan-summers> Are you building from within the "stm32f4xx-hal" repo, or from your own repo?
<re_irc>
<omar_u8> My own repo
<re_irc>
<omar_u8> Well I cloned the cortex m quick start some time back and did some mods to make debug work.
<re_irc>
<ryan-summers> My guess this is that this is related to the Cargo.toml dependencies
<re_irc>
<ryan-summers> You can try the "cargo tree" command to see if cortex-m-rt is being pulled in by the HAL
<re_irc>
<omar_u8> Ok I’ll check on that. Thanks!
<re_irc>
<adamgreig> Maybe you need to use the HAL
<re_irc>
<adamgreig> It's not enough to have it in cargo.toml if your source doesn't also use it (and cortex m rt)
<re_irc>
<ryan-summers> Ah, so "use stm32f4xx_hal as _;" in "main.rs" or something?
<re_irc>
<omar_u8> We’ll as HAL yes
<re_irc>
<omar_u8> I took the discovery example as is from what I recall
<re_irc>
<omar_u8> Just modified the imports.
<re_irc>
<omar_u8> I’m away from my pc now but I’ll give it a check and see if I missed something there.
<re_irc>
<yruama_lairba> hi, does somoen have guideline about what to mark unsafe or not in a embed context ?
<re_irc>
<ryan-summers> In general, I think the consensus is that you shouldn't use it to indicate other things, since it has a well defined meaning in Rust
<re_irc>
<yruama_lairba> ok, so a command that may cause synchronisation issue when executed is not unsafe
<re_irc>
<ryan-summers> It depends what you mean by synchronization. If you mean e.g. memory synchronization between two cores, then yes it would likely be unsafe
<re_irc>
<ryan-summers> If you mean like a frame synchronization issue on a display, I wouldn't call that unsafe
<re_irc>
<yruama_lairba> no, just clock synchronisation
<re_irc>
<ryan-summers> I would just document potential side effects of the function and how to use it to avoid the issues described
<re_irc>
<ryan-summers> But don't mark it as unsafe unless it conforms with Rust's definition of unsafe
<re_irc>
<yruama_lairba> but a command that can cause invalid combination of register values is unsafe
<re_irc>
<ryan-summers> Err, I don't think even that's considered unsafe under Rust's definitions
<re_irc>
<yruama_lairba> not agree, the unsafty is related to a DMA stuff
<re_irc>
<adamgreig> Then why is new() safe?
<re_irc>
<adamgreig> The only difference is the pins, both still consume a singleton peripheral
<re_irc>
<yruama_lairba> right, didn't see the incoherence
<re_irc>
<yruama_lairba> so i suck to write API for a codec.
<re_irc>
<yruama_lairba> i finished to write a version yesterday that looked nice, until i tried to really use it :/
<re_irc>
<yruama_lairba> i tried to imitate Peripherals Access crate by doing "set_my_register(|w| ...)" but it' not conveninet to use because you can't store the W to reuse it after
<re_irc>
<yruama_lairba> *reuse it later
<re_irc>
<yruama_lairba> a previous version was just "write(register)" but IMHO this was making "write" actually unsafe because some combination of values across register are not valid
<re_irc>
<jannic> Designing a good API without actually trying it out on a real project is really hard. (And even with a specific use case it's still hard, as the next use case will be different...)
<re_irc>
<yruama_lairba> jannic: technically, i just wanted to do something that can write all configuration register. quite simple until i wanted to use unsafe to declare unsafe stuff
<re_irc>
<firefrommoonlight> I think that's what bites many EH libs
<re_irc>
<firefrommoonlight> I find it easier to work the other way around - write a module for a specific project, then make it more generic or feature -rich after as required
<re_irc>
<firefrommoonlight> I think that's what bites EH libs
<re_irc>
<yruama_lairba> firefrommoonlight: this what i should did, writting a hal for a specific use
<re_irc>
EH as an abstraction layer is extra difficult: its usefulness for a single project is very limited by definition. You need a lot of examples to extract a common API which is both easy to use and generic enough.
<re_irc>
<jannic> > I think that's what bites EH libs
<re_irc>
<yruama_lairba> what mean EH ?
<re_irc>
<ryan-summers> embedded-hal
<re_irc>
<omar_u8> adamgreig: Using the HAL resolved the error issu
<re_irc>
e, though now when running the code it keeps breaking at the below line in the lib.rs and doesnt print anything to the console. #[cfg(all(thumb, not(feature = "inline-asm"), not(feature = "no-semihosting")))]
<re_irc>
() => __c_m_sh_syscall(_nr, _arg),
<re_irc>
<omar_u8> Using the HAL resolved the error issue, though now when running the code it keeps breaking at the below line in the lib.rs and doesnt print anything to the console. ```#[cfg(all(thumb, not(feature = "inline-asm"), not(feature = "no-semihosting")))]
<re_irc>
() => __c_m_sh_syscall(_nr, _arg),
<re_irc>
<omar_u8> Using the HAL resolved the error issue, though now when running the code it keeps breaking at the below line in the lib.rs and doesnt print anything to the console.
<re_irc>
<ryan-summers> Without more context on what your app looks like, it's going to be impossible to help debug
<re_irc>
<omar_u8> ryan-summers: Sure, I am trying to run the semihosting example from the discovery book as is but on a different board with the STM32F401RE.
<re_irc>
<ryan-summers> Where's the "__c_m_sh_syscall" stuff coming from?
<re_irc>
<ryan-summers> Also, any particular reason you want to use semihosting instead of RTT? Semihosting is incredibly slow
<re_irc>
<ryan-summers> Also, I'm assuming you have a debugger attached to the board?
<re_irc>
<omar_u8> The full setup is working with other code, GPIO and what have you. Though when I run the semihosting example the code breaks at the "__c_m_sh_syscall" line
<re_irc>
<omar_u8> Its a nucleo board with the STlink
<re_irc>
<omar_u8> ryan-summers: Well no particular reason, I just want to tray getting examples goign and see the difference.
<re_irc>
<omar_u8> * try getting examples going
<re_irc>
<ryan-summers> Are you enabling semihosting in your debugger setup? Semihosting is a bit weird and not super common nowadays
<re_irc>
<ryan-summers> You should have something along the lines of "monitor arm semihosting enable" in your GDB / Openocd config file
<re_irc>
<omar_u8> Yes in the openocd.gdb
<re_irc>
<omar_u8> I tried stepping through the code using the debugger as well. It goes through a bunch of lines before breaking at that particular line and always returning to it.
<re_irc>
<omar_u8> /// Performs a semihosting operation, takes one integer as an argument