<cr1901>
(why are registers being accessed at different addresses than physical?)
<cr1901>
(and is it a linear offset or something more fancy?)
fabic has joined #rust-embedded
<re_irc>
<GrantM11235> (Chiptool would work with remapped registers. A chiptool register block is a wrapper for a raw pointer, so for example, instead of using the auto-generated "const SPI1: Spi = Spi(0x4001_3000 as *mut u8)" you could do "let my_spi = Spi(0xdeadbeef as *mut u8)")
fabic has quit [Ping timeout: 276 seconds]
<re_irc>
<762spr> Hi everyone Im new here and to embedded rust. I have done lots of work with STM32s in C and considering migrating to rust!
<re_irc>
While I started with STM's official HALs I quickly found them to be way overly convoluted and abstracted many times over. They were a mess and bloated everything... so I started doing everything super low level and manually setting registers for peripherals.
<re_irc>
Enter rust and now that is unsafe code. Which is cool because being generally new to embedded programming I found myself in trouble a LOT while working low level in C. But I am worried I will be going back to the bloat of HALs. I am not sure exactly how to frame the question, but put simply is there a lot of size or performance bloat for using rust HALs? I know that is probably rather subjective so sorry for the odd question I am...
<re_irc>
... just trying to get a feel for what I will be working with if I want to move forward with rust!
<re_irc>
<adamgreig> I'd say it depends on the HAL but in general the rust ones tend to be pretty similar to what you'd write yourself accessing the registers and so don't have significant overhead compared to that... but you can just access registers too if that's what you prefer
<re_irc>
<762spr> OK cool. I honestly would prefer some sort of abstraction layer just to keep my sanity. I watched a primer video on how embedded rust does it and it seems like a really intuitive way to handle everything. My only concern was the bloat. Setting bits and bits can make my eyes cross after a while haha
<re_irc>
<firefrommoonlight> I agree that setting regs manually isn't great in application code. Depends on details. Some MCUs have simpler reg APIs. adamgreig's stm32-ral crate as a clean reg-level API
<re_irc>
<762spr> Awesome I will check that out. Even for applications that don't demand utmost perfromance, I always try to keep things as lean as I can on principal
<re_irc>
<762spr> That looks very promising for what I want to do from just skimming on my phone. Thanks!
tokomak has quit [Read error: Connection reset by peer]
<re_irc>
<ub|k> Has anyone ever seen a "Could not determine a suitable packet size for this probe" error trying to use "probe-run"?
<re_irc>
<newam> O_o never
<re_irc>
but I only use the hs-probe and STLinks, pretty vanilla.
<re_irc>
<ub|k> i'm using a CMSIS-DAP probe
<re_irc>
<ub|k> I have the feeling it may be related to some recent changes in my code.
<re_irc>
<9names (@9names:matrix.org)> I've get it occasionally, resolved by unplugging/replugging debugger or substituting port/cable
<re_irc>
<xobs> cr1901: Because MMU. A process reserves a peripheral in the OS by calling "MapMemory", which returns the page at some other offset. It's not a linear offset, it's whichever address the kernel thought you should have.