<re_irc>
<nihal.pasham> yep, tried debugging a 32-bit "elf" and it is able to read the symbols. I guess we need to be looking for "aarch64-none-eabi-gdb" or "gdb-multiarch"
<re_irc>
GNU gdb (xPack GNU Arm Embedded GCC arm64) 10.2.90.20210621-git
<re_irc>
<9names (@9names:matrix.org)> I typically don't use their target specific gdb since it doesn't include python support (and I don't see the point when multiarch exists) - hope you can find some version of multiarch.
<re_irc>
Also, I wasn't considering using the toolchain for native development, not sure what the best option is there.
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
gsalazar has joined #rust-embedded
<re_irc>
<nihal.pasham> I was actually targeting the raspberry pi4 which has a aarch64 processor. For native (i.e. apple silicon) development I guess we can use lldb or the cmd line tools that come with Xcode.
<re_irc>
One way around this limitation is to use rosetta2 (m1's built-in instruction emulator).
<re_irc>
if rosetta isn't already installed, start with
<re_irc>
<nihal.pasham> I was actually targeting the raspberry pi4 which has an "aarch64" processor. For native (i.e. apple silicon) development I guess we can use lldb or the cmd line tools that come with Xcode.
<re_irc>
But one way around this limitation is to use rosetta2 (m1's built-in instruction emulator).
<re_irc>
softwareupdate --install-rosetta
<re_irc>
if rosetta isn't already installed, start with
dc740 has quit [Remote host closed the connection]
<re_irc>
<wucke13> I'm currently building a "no_std" library, that for some cases can provide a "panic handler". What is a good course of action here? Can I provide the "panic_handle" as fallback, but ignore it for example when compiling for std? Or shall this be opt-in via a feature?
<re_irc>
<James Munns> I usually do that with a feature
<re_irc>
<wucke13> Opt in or Opt out?
Socke has quit [Quit: WeeChat 3.5]
<re_irc>
<wucke13> Is there a "cfg()" thing which is only set when building for a target that does not come with a std lib?
<re_irc>
<James Munns> opt in
Socke has joined #rust-embedded
<re_irc>
<James Munns> wucke13: Probably you could get it from part of the triple (e.g. if it has "none" in it), but I'd probably just stick with the feature
<re_irc>
<wucke13> I see, thank you :)
causal has joined #rust-embedded
gsalazar has quit [Ping timeout: 276 seconds]
aspe has joined #rust-embedded
gsalazar has joined #rust-embedded
aspe has quit [Quit: aspe]
gsalazar has quit [Ping timeout: 258 seconds]
<re_irc>
<barafael> Selling 2 broken stm32g4 nucleo boards, 100€ each
<cr1901>
My God, the supply is THAT bad that broken boards go for that much?
<cr1901>
I have one stm32f407 that I extracted from a broken discovery board. I will sell it for $500
<re_irc>
<d8sn6f6nzq> Hi al I’m prettig new to the whole rust ecosystem, coming from the world of C. I’m trying to code an I2C slave on an stm32l0 but having a hard time, there seems to be no support for it in the HAL.
<re_irc>
I guess in this case it’s just working directly with the PAC and try to get that working, right?
<re_irc>
<adamgreig> yea, that's the way. i2c slaves are a less common so not well supported
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<barafael> The idea is to use the PAC to initialize the i2c peripheral in slave mode. You'll get away without the smbus state machine stuff linked above, the relevant code is in the stm32f0 example module
<re_irc>
<d8sn6f6nzq> Cool thanks, will check it out! Haven’t gone into rtic yet but seems like the way to go when implementing an i2c slave based around interrupts.