ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
starblue has quit [Ping timeout: 250 seconds]
starblue has joined #rust-embedded
dngrsspookyvisio has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has joined #rust-embedded
GenTooMan has quit [Ping timeout: 256 seconds]
GenTooMan has joined #rust-embedded
CHMchmousset[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
Noah[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
Socke has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
Ablu[m] has quit [Quit: Idle timeout reached: 172800s]
MathiasKoch[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]> it's a bit in cortex-m SCB SCR
<dirbaio[m]> for some reason cortex-m doesn't expose it 🤣
<dirbaio[m]> bit 4 in SCR, you can set it via the raw RegisterBlock API
<dirbaio[m]> I think it's already set on reset though
<dirbaio[m]> SEVONPEND=1 is more "wakey", if you have set it to 1 and wakeup is not working then it's something else
<dirbaio[m]> the way it works is
<dirbaio[m]> - WFI waits for some *enabled* interrupt to fire *after* the instruction has started running... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/iYEUduiIjRSddqtkSOttBqUc>)
<dirbaio[m]> so WFE (with SEVONPEND=1) can "wait" for interrupts that have happened in the past
<dirbaio[m]> WFI doesn't, it waits for a future interrupt only
<dirbaio[m]> yeah with WFI it should work I think
<dirbaio[m]> do you have the interrupt enabled?
<dirbaio[m]> does the interrupt handler fire if you replace the WFI with loop{}? if you print "hello!" from it for example
<dirbaio[m]> yeah that should work
<dirbaio[m]> does it fail to compile?
<dirbaio[m]> to check if the irq handler is working, you can force it to fire by doing this from main:
<dirbaio[m]> interrupts::RTC_WKUP.enable()
<dirbaio[m]> interrupts::RTC_WKUP.pend()
<dirbaio[m]> * to check if the irq handler is working, you can force it to fire by doing this from main:
<dirbaio[m]> interrupts::RTC_WKUP.pend()
<dirbaio[m]> if that works, but with the real RTC doesn't, then it's some issue configuring the RTC
<dirbaio[m]> use embassy_stm32::interrupt::InterruptExt;
<dirbaio[m]> embassy_stm32::interrupt::RTC_WKUP.pend();
<dirbaio[m]> interrupt, not interrupts, sorry 😓
<dirbaio[m]> did you do this? embassy_stm32::interrupt::RTC_WKUP.enable();
<dirbaio[m]> you always have to do enable yes
<dirbaio[m]> then either you pend() it manually or let the rtc periph pend it
<dirbaio[m]> yep
<dirbaio[m]> yep, was a suggestion just for debugging
<dirbaio[m]> now that you know the irq handler works, you can try getting the RTC to do it
<dirbaio[m]> I suggest trying with a loop{} in main instead of WFE/WFI first
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]> so you're sure stop mode isn't interfering
<dirbaio[m]> and when you get that working, try adding the WFE/WFI
GenTooMan has quit [Ping timeout: 248 seconds]
GenTooMan has joined #rust-embedded
nex8192 has left #rust-embedded [Error from remote client]
nex8192 has joined #rust-embedded
<ryan-summers[m]> <stephen> "Hi everyone! I'm having an issue..." <- > <@stephen:crabsin.space> Hi everyone! I'm having an issue with USB CDC. Basically I want to constantly sends data from my stm32 to the host.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RouMiCzBPhgMprWvBXOZBfur>)
badrb[m] has quit [Quit: Idle timeout reached: 172800s]
dirbaio[m] has quit [Quit: Bridge terminating on SIGTERM]
thejpster[m] has quit [Quit: Bridge terminating on SIGTERM]
adinack[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
JamesMunns[m] has quit [Quit: Bridge terminating on SIGTERM]
M9names[m] has quit [Quit: Bridge terminating on SIGTERM]
firefrommoonligh has quit [Quit: Bridge terminating on SIGTERM]
ryan-summers[m] has quit [Quit: Bridge terminating on SIGTERM]
calisti[m] has quit [Quit: Bridge terminating on SIGTERM]
timokrgr[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
tr09[m] has quit [Quit: Bridge terminating on SIGTERM]
marmrt[m] has quit [Quit: Bridge terminating on SIGTERM]
jessebraham[m] has quit [Quit: Bridge terminating on SIGTERM]
M9names[m]1 has quit [Quit: Bridge terminating on SIGTERM]
sauce has joined #rust-embedded
_catircservices has joined #rust-embedded
_catircservices1 has joined #rust-embedded
StephenD[m] has joined #rust-embedded
<StephenD[m]> <ryan-summers> "> <@stephen:crabsin.space> Hi..." <- I'm not checking any - I thought poll was supposed to handle that all for me. That's how it's done in the examples at least
<StephenD[m]> Unless it means there are bytes on the incoming buffer I'm supposed to read? Unsure where they'd come from but could be worth a try
dirbaio[m] has joined #rust-embedded
<dirbaio[m]> you can try embassy-usb+embassy-stm32, that one does handle the interrupt for you
<dirbaio[m]> * you can try embassy-usb + embassy-stm32, that one does handle the interrupt for you
<dirbaio[m]> (I know it's not what you're looking for, but it can be an alternative if synopsys_usb_otg refuses to collaborate 😅)
_catircservices1 has quit [Quit: Bridge terminating on SIGTERM]
StephenD[m] has quit [Client Quit]
_catircservices has quit [Read error: Connection reset by peer]
dirbaio[m] has quit [Client Quit]
_catircservices has joined #rust-embedded
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
<StephenD[m]> <dirbaio> "you can try embassy-usb+embassy..." <- ooh, I haven't heard of either of thoes
StephenD[m] has joined #rust-embedded
<StephenD[m]> s/thoes/those/
dirbaio[m] has joined #rust-embedded
adinack[m] has joined #rust-embedded
<adinack[m]> i just discovered embassy last night it looks super cool (especially nrf-softdevice) but their hals are a bit bare, but they say other hals can be used instead!
<dirbaio[m]> what have you found missing in the HALs?
<adinack[m]> i didn’t even see a pwm structure for stm32f0
<adinack[m]> i guess they just don’t have an example for it then
<dirbaio[m]> the API is the same for all stm32's, if your family doesn't have an example for what you want you can look at other families
<adinack[m]> oh shut they even have complementary pwm
<adinack[m]> ok nvm this looks great then
<adinack[m]> i wonder if there are any significant performance drawbacks from the RTOS-ish nature of it
<dirbaio[m]> async is quite light. there is some overhaed vs real bare metal
<dirbaio[m]> but it's smaller+faster than C RTOS's https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown
<adinack[m]> i never had any doubt it would be less over head than the C RTOSs 😎
<dirbaio[m]> if what you're doing is really simple you can also use embassy-stm32 without async
<adinack[m]> well thanks i want to give embassy a shot ASAP
<dirbaio[m]> it supports blocking too
<dirbaio[m]> I wouldn't recommend it though because it has less support for raw interrupt-driven stuff than the stm32-rs HALs
<adinack[m]> yeah that’s what i was gonna ask
<adinack[m]> you seem to know a lot about embassy, are you a contributor? or just a happy user
<dirbaio[m]> maintainer 🙃
<adinack[m]> very nice 😎
<adinack[m]> i am thinking embassy may be the answer for doing a GATT server with an nrf
<adinack[m]> it seems there is little alternative when it comes to Rust
IlPalazzo-ojiisa has quit [Remote host closed the connection]
crabbedhaloablut has quit []