ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
Lumpio- has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc> <James Munns> It's gotta be a double double then, two decimal points :D
<re_irc> <dirbaio> a quadruple!
<re_irc> <dirbaio> "f128"
sknebel has quit [Quit: sknebel]
sknebel has joined #rust-embedded
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
bpye has quit [Ping timeout: 246 seconds]
jr-oss has quit [*.net *.split]
jr-oss has joined #rust-embedded
tafa has quit [*.net *.split]
richardeoin has quit [*.net *.split]
tafa has joined #rust-embedded
richardeoin has joined #rust-embedded
bpye has joined #rust-embedded
fabic has joined #rust-embedded
bpye has quit [Quit: The Lounge -]
bpye has joined #rust-embedded
gsalazar has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
neceve has joined #rust-embedded
hwj has joined #rust-embedded
<re_irc> <James Munns> So, question for all the Cortex-M/ASM folks:
<re_irc> Does anyone know offhand what I need to in Cortex-M in an interrupt handler to basically totally context-switch-on-handler-exit? I have thread mode set up with it's own process stack, but if I wanted to "boot the app like new", I think I need to:
<re_irc> - Wipe everything in the process address space, reset the stack pointer back to the top of the new (clear) stack
<re_irc> - Put something (???) on the stack, to be restored on exit of the interrupt
<re_irc> <James Munns> Basically in my tiny OS, I want some way to "exit"/"context switch"/"load new app". So app A would make a syscall, and when the syscall exits, I want to be back at the top of app B.
<re_irc> <James Munns> (right now I "cheat" by just rebooting)
<re_irc> <James Munns> Ah, I found, which seems to have enough info to start with :)
hwj has quit [Ping timeout: 276 seconds]
fabic has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic has quit [Ping timeout: 276 seconds]
fabic_ has quit [Ping timeout: 256 seconds]
hwj has joined #rust-embedded
hwj has quit [Quit: Leaving]
<re_irc> <yruama_lairba> i just realize i don't understand some details about Alternate function
<re_irc> <yruama_lairba> is there a special thing to do with alternate pin depending the alternate function read or write the pin ?
<re_irc> <yruama_lairba> sorry, stm32 chip
<re_irc> <yruama_lairba> ooops wasn't looking the right figure in datasheet. Apparantly alternate function manage automatically if the input schmitt trigger or output buffer should be enabled
<re_irc> <Lachlan> I can't seem to get my stm32f1 to acknowledge CAN frames
<re_irc> <Lachlan> It can send them, but can't receive them
<re_irc> <Lachlan> Same with the raspi with an mcp2515 on the other side
<re_irc> <Lachlan> I have them both hooked up to an oscilloscope, and the levels are pretty much the same. It's possible the bauds aren't the same. The can controller on the stm32f1 doesn't seem to do the bitrate that says it should.
<re_irc> <James Munns> dumb question - do they have a common ground?
<re_irc> <James Munns> I guess at least through the common oscilloscope ground, if you have them both connected.
<re_irc> <aholtzma> has anyone used cargo-call-stack on stm32?
<re_irc> --> /Users/aholtzma/.cargo/registry/src/
<re_irc> <aholtzma> error[E0432]: unresolved import `alloc::sync`
<re_irc> 2 | use alloc::sync::Arc;
<re_irc> |
<re_irc> | ^^^^ could not find `sync` in `alloc`
<re_irc> <aholtzma> It looks like it is building Gimli with no-std?
<re_irc> <dirbaio> it's a standalone command line tool, you have to "cargo install" it, not add it to your dependencies
<re_irc> <aholtzma> right, I'm running the tool, it does some compiling to build something that outputs the dot graph
<re_irc> <aholtzma> cargo +nightly call-stack --bin foo --target thumbv6m-none-eabi
<re_irc> <aholtzma> the code is the example from here:
neceve has quit [Ping timeout: 246 seconds]
<re_irc> <dirbaio> oh huh
<re_irc> <dirbaio> I get the same error. seems like it doesn't like --target
<re_irc> <Lachlan> James Munns: One of the boards is powering the other, so yep
diagprov has joined #rust-embedded
<re_irc> <Lachlan> Well, it's still not working. I guess I'll put it down for today
<re_irc> <yruama_lairba> i wonder if it's acceptable for a hal to allow meaningless operation ? (no side effects) any opinion ?