yandrik[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has joined #rust-embedded
thiskappaisgrey[ has quit [Quit: Idle timeout reached: 172800s]
nex8192 has left #rust-embedded [Error from remote client]
ian_rees[m] has quit [Quit: Idle timeout reached: 172800s]
mameluc[m] has joined #rust-embedded
<mameluc[m]>
Any pointers on how to reach <10µA on an STM chip (STM32WLEx)? Example project or general wisdom welcome. I think my first hurdle is that WFE doesn't keep my device in any low power mode. Is there a way to check what event woke the chip?
RobertJrdens[m] has joined #rust-embedded
<RobertJrdens[m]>
mameluc: for example tracing (probe-rs itm ...)
<mameluc[m]>
Thanks Ill look in to ITM. I got breakpoints working and I can read all the registers but I don't know if that is using ITM
marmrt[m] has joined #rust-embedded
<marmrt[m]>
Add a delay for a few seconds in init before entering the low power mode. It will make it less likely that you brick your device
nex8192 has joined #rust-embedded
<mameluc[m]>
thanks, good warning
<ryan-summers[m]>
<mameluc[m]> "Any pointers on how to reach <..." <- Generally the WFE only sleeps the CPU. There's a ton of other clock buses in the chip that likely aren't powering down. In general, when you want low power, you need to disable as many clocks in the MCU as possible. The higher frequency clocks take the most power (generally speaking)
<ryan-summers[m]>
For example, if your peripherals are still clocked, some of the core PLLs could be the source of significant current draw
<ryan-summers[m]>
Then, lowering all of the peripheral clocks to lowest acceptable frequency etc. There's lots of steps that go into optimizing power consumption.
<mameluc[m]>
yes, I am kind of familiar with the process for 8-bit mcus but haven't done much power optimization for 32-bit or cortex-m. I find the ST reference hard to read but probably just because I am used to other vendors.
<mameluc[m]>
Also I find it hard to know where to start, right now it seems like my CPU is not staying in WFE so some event is waking it up. I am thinking the CPU should stay in WFE even with all the clocks on
<mameluc[m]>
I am drawing 1.8mA now and I can see it looping in and out of wfe.
GenTooMan has joined #rust-embedded
<Lumpio->
I think you're going to need wfi and not wfe for any deep sleep
<Lumpio->
ok scratch that I remembered the semantics wrong
<mameluc[m]>
for now I am fine with both as long as I get some kind of sleep state. I was thinking it would be easier somehow to see what event happened than looking trough all the interrupts
<ryan-summers[m]>
I mean, are you enabling any interrupts?
<ryan-summers[m]>
Because that'll obviously wake you up
<mameluc[m]>
Not that I know of, trying to look trough all the registers to see that nothing is enabled. As I was working with SEV I assumed I should be looking at events not interrupts but I understand if that assumption is wrong
<mameluc[m]>
I guess this is what I am looking for
<Lumpio->
I'm fairly sure any interrupt will also cause an "event" on STM32 at least
<stephe>
How can I get esp-println (& esp-backtrace) to use a custom UART I have set up with a custom config? I'm using write!(uart, ...); for my code
<stephe>
Maybe I need to install this UART as the default or something
mabez[m] has joined #rust-embedded
<mabez[m]>
<stephe> "How can I get esp-println (& esp..." <- There isn't any way to select the output uart for esp-println/esp-backtrace. I think it should be doable though, would you mind filing an issue?
cputoast[m] has joined #rust-embedded
<cputoast[m]>
Hi. I have some problems with getting a USB device to work. I'm trying to get a sound card working with the usbd-audio crate, but I seem to be dropping every second frame. Is that something you guys have any knowledge on?
<stephe>
mabez[m]: sure
<stephe>
mabez[m]: is there any easy workaround, like to install a uart as the default?
GenTooMan has joined #rust-embedded
<mameluc[m]>
Thanks for the help, got my wfe to work. Now it sits at 800µA but I haven't touched any of the other peripherals yet so some clocks are running that shouldn't
<mameluc[m]>
I am probably fighting som pullups or pull downs too
huegene[m] has joined #rust-embedded
<huegene[m]>
does anyone have exp how to handle division errors (i guess by zero) inside the cordic::atan2 function?
<huegene[m]>
supposedly this should not happen
<mabez[m]>
<stephe> "mabez: is there any easy..." <- The work around unfortunately is the one you are using, using the other uart with the `write!`macro
<huegene[m]>
<huegene[m]> "does anyone have exp how to..." <- I just realized (not tested yet) why this happens this regulat atan (y/x) possibly fails when y is big and x is small enough such that its value overflows for fixed point variables
<huegene[m]>
> <@huegene:matrix.org> does anyone have exp how to handle division errors (i guess by zero) inside the cordic::atan2 function?
<huegene[m]>
* I just realized (not tested yet) why this happens, the regular atan (y/x) possibly fails when y is big and x is small enough such that its value overflows for fixed point variables
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
For handling timeouts with embedded-hal implementations, wouldn't it make sense to have a variant ErrorKind::Timeout? What is the alternative, use ErrorKind::Other or a custom error type?
_whitelogger has joined #rust-embedded
<dirbaio[m]>
what trait do you want to use with timeouts? and how/why?
<sourcebox[m]>
E.g. SPI.
<sourcebox[m]>
I don't need to have the timeout value explicitely specified, this can be done inside the HAL.
<dirbaio[m]>
how can SPI timeout?
<sourcebox[m]>
That's basically the same question like how can a GPIO fail. Because something can go wrong that e.g. leads to a condition that a transfer_complete flag is never set.
<dirbaio[m]>
an SPI transfer should take exactly num_bits / freq
<sourcebox[m]>
With I2C and clock stretching, timeouts can happen.
<dirbaio[m]>
if it takes longer, either the MCU peripheral is broken or the HAL has a bug
<dirbaio[m]>
there's no way for a portable driver to handle that
<dirbaio[m]>
so in this case it'd make sense to make it a custom error type, with kind ErrorKind::Other
<sourcebox[m]>
No, the driver can't handle it, but it can return the error.
<dirbaio[m]>
so the driver just passes it up to the user
<sourcebox[m]>
Having an error that I can log is better then ending in an infinite loop.
<dirbaio[m]>
adding an ErrorKind::Timeout wouldn't help much
<dirbaio[m]>
a portable driver doesn't care about the difference between "hardware is broken, which manifested as a timeout" and "hardware is broken, which manifested as something else"
<dirbaio[m]>
all it cares is "hardware is broken"
<dirbaio[m]>
that's for SPI, GPIO, etc
<dirbaio[m]>
for I2C it is trickier because devices can hold the bus for infinite time with clock stretching, yes
<dirbaio[m]>
so perhaps ErrorKind::Timeout makes more sense there
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<huegene[m]>
* I just realized (not tested yet) why this happens, the regular atan (y/x) possibly fails when y is big and x is small enough such that its value overflows for fixed point variables, even when its not div by zero
nex8192 has left #rust-embedded [Error from remote client]
GenTooMan has quit [Ping timeout: 260 seconds]
nex8192 has joined #rust-embedded
nex8192 has left #rust-embedded [Error from remote client]
nex8192 has joined #rust-embedded
GenTooMan has joined #rust-embedded
almindor[m] has joined #rust-embedded
<almindor[m]>
I agree with dirbaio for SPI and GPIO timeout errors don't really make much sense
pbsds has quit [Ping timeout: 246 seconds]
pbsds has joined #rust-embedded
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
dirbaio: is there a typo in that e-h pr title?
<dirbaio[m]>
oops 😂
<dirbaio[m]>
fixed
<adamgreig[m]>
haha, glad I wasn't just losing it
<adamgreig[m]>
i got on a plane at 2330 local monday evening and have been more or less up since then 💤
<adamgreig[m]>
meeting time again @room! agenda is https://hackmd.io/xRnd_xiNRgKzPY6tkzXP8Q, please add anything you'd like to announce or discuss and we'll kick off in a few mins
<adamgreig[m]>
we just chat here, so you're already in it!
Mebus[m] has joined #rust-embedded
<Mebus[m]>
Hi, how is it possible to join the meeting?
<adamgreig[m]>
the link above has the agenda with links if you want to add anything
<Mebus[m]>
ah, I thought it would be a sort of audio conference.
<adamgreig[m]>
nah, just text, we very very occasionally have had video/audio calls but it's a bit more chill with text I guess
<adamgreig[m]>
also it used to be on irc where that wasn't really an option
<adamgreig[m]>
ok, let's start! just one announcement from me this week, the hal team released critical-section 1.1.2 with some updated docs, no functional changes though so shouldn't have any serious impact
<adamgreig[m]>
but hopefully people finding it have a slightly better time getting to grips with it
<adamgreig[m]>
did anyone have any other announcements? I've been afk since thursday so haven't been totally on top of everythign
thejpster[m] has joined #rust-embedded
* thejpster[m]
is on vacation 🏕️
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Also just came back 2 days ago. 😅
<adamgreig[m]>
ah, august 😅
<adamgreig[m]>
ok, a couple of other points then, not sure if anyone from the relevant teams will be around but it might be helpful to poll for some opinions regardless
<adamgreig[m]>
in the past we've basically talked about "re-export if it's a real dependency, but not when it's just being convenient (eg embedded-io in embedded-hal)"
<adamgreig[m]>
( nchong-at-aws, if you're around)
<therealprof[m]>
Just curious, why did they decide to go for a tock PAC in the first place?
<adamgreig[m]>
therealprof[m]: hmm, pass. originally it used a different wg-maintained crate that bridged tock-registers to also allow access to CPU CSRs, but now tock-registers can do that too so it's swapped
<adamgreig[m]>
I think svd files are not really a thing here, so the alternative is cortex-m's current approach of having a few different ways to read and write arbitrary registers with a mix of bit shifts and bitfield crates
dhylands[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
anyway, we can revisit later, but it seems like probably re-exporting the traits does make sense here?
<almindor[m]>
Yes, I think the main issue is to figure out which approach we want to take
<almindor[m]>
perhaps compare to similar cases elsewhere, although this is quite RISC-V centric
<adamgreig[m]>
iirc volatile-register is perhaps not encouraged because it suffers from this Dereferenceable issue where you have a &ref to some mmio that the compiler might therefore insert a spurious read to
<almindor[m]>
let's punt this for next (or later) meeting for now
<almindor[m]>
I'm also half-away, I didn't expect it to be presented for this week
<therealprof[m]>
I'm fine with doing the migration guide later, especially since there're already implementations around supporting the old and the new version.
<eldruin[m]>
maybe anybody else has some other reason to delay the rc?
<eldruin[m]>
s/anybody/somebody/
<dirbaio[m]>
i'm updating the changelogs
<eldruin[m]>
⏲️
<dirbaio[m]>
where should the defmt feature be documented?
<dirbaio[m]>
comment in Cargo.toml, or readme?
<eldruin[m]>
readme, docs (lib.rs)
<dirbaio[m]>
docs.rs main page is the readme now
<adamgreig[m]>
it's a shame docs.rs doesn't have a good way to document features despite listing them
<adamgreig[m]>
so the readme/main docstring seems the best/most common place
<adamgreig[m]>
short of a whole separate module that only exists in cfg(doc) to document them
nex8192 has left #rust-embedded [Error from remote client]
<adamgreig[m]>
anything else to say about e-h 1.0.0-rc.1?
burrbull[m] has joined #rust-embedded
<burrbull[m]>
I'd want to make new svd2rust release. What to do with #723? Ignore or merge?
<adamgreig[m]>
yea, let's talk about that briefly
<adamgreig[m]>
basically it's hard to say what the safety contract for the new steal() should be, because it's probably "you can just yolo" in terms of actual UB
<adamgreig[m]>
"make sure steal() has been called beforehand" is possible but hard to obey
<adamgreig[m]>
in the best spirit of the current model, it's probably "ensure no conflicting races with other instances of the peripheral are possible", which a HAL doing a uart split into tx/rx for instance should be able to manage
<adamgreig[m]>
(or a hal doing a gpio split with atomic bsrr and atomic mode change accesses etc)
<burrbull[m]>
yet another option?
<adamgreig[m]>
Ensure that the new instance of the peripheral cannot be used in a way that may race with any existing instances, for example by only accessing read-only or write-only registers, or by consuming the original peripheral and using critical sections to coordinate access between multiple new instances.
<adamgreig[m]>
?
<adamgreig[m]>
ugh sorry
<adamgreig[m]>
* ```
<adamgreig[m]>
# Safety
<adamgreig[m]>
Ensure that the new instance of the peripheral cannot be used in a way that may race with any existing instances, for example by only accessing read-only or write-only registers, or by consuming the original peripheral and using critical sections to coordinate access between multiple new instances.```
<adamgreig[m]>
well if no one complains I think go with that and merge it and release :P
<adamgreig[m]>
eldruin, do you want to talk about translations at all?
<dirbaio[m]>
volatile races are not UB but
<dirbaio[m]>
HALs might rely on singletons for actual memory safety
<dirbaio[m]>
like, using singletons to ensure there's no data races to conventional static memory
<dirbaio[m]>
embassy does that for example, to access global ringbuffers for uart
<dirbaio[m]>
s/uart/uarts with no locking/
<dirbaio[m]>
s/global/static/, s/uart/uarts with no locking/
<eldruin[m]>
adamgreig[m]: at the moment I will not be able to do anything about it so I do not have anything to say
<adamgreig[m]>
dirbaio: ah, eg the HAL has its own singleton that consumes a peripheral singleton, and that HAL one accesses a static buffer or so?
<dirbaio[m]>
yea
<dirbaio[m]>
"its own singleton" is the uart driver struct, but yes
<adamgreig[m]>
perhaps add "You may need to comply with any additional restrictions required by a HAL or other library that consumes this peripheral"?
<adamgreig[m]>
sure, I guess I mean something that it takes to be a singleton because it consumes a PAC singleton on construction
<dirbaio[m]>
bringing it up because depending on how svd2rust documents the safety contract
<dirbaio[m]>
it's either not allowed for HALs to do that
<dirbaio[m]>
* if the safety contract is too lax, then it's not allowed for HALs to do that
<dirbaio[m]>
if the safety contract is strict then it should say "you must ensure no two instances of the singleton exist at a time"
<dirbaio[m]>
and something like "except if you never pass the singleton to code you don't control and ensure all reg accesses you do don't race, then it might be OK to have two instances at a time"
<dirbaio[m]>
in the embassy case it's slightly different because it defines the singletons itself
<dirbaio[m]>
and I haven't seen any svd2rust-based HAL do that
<dirbaio[m]>
so idk
<dirbaio[m]>
* do that (access global mutable state without locks relying on singletons)
<adamgreig[m]>
yea, I guess we mostly have to deal with what hals actually do
<adamgreig[m]>
what svd2rust says is:
<adamgreig[m]>
> To use a peripheral first you must get an instance of the peripheral. All the device peripherals are modeled as singletons (there can only ever be, at most, one instance of any one of them) and the only way to get an instance of them is through the Peripherals::take method, enabled via the critical-section feature on the generated crate.
<adamgreig[m]>
and
<adamgreig[m]>
> The singleton property can be unsafely bypassed using the ptr static method which is available on all the peripheral types. This method is useful for implementing safe higher level abstractions.
<adamgreig[m]>
but ptr() doesn't return the peripheral instance, just a raw ptr to the register block, so you couldn't as easily pass it around
<dirbaio[m]>
eldruin: changelogs and feature docs added, could you review?
<dirbaio[m]>
yea, a `&RegisterBlock` allows doing reg access, but not "hack" HALs that rely on the singletons
<adamgreig[m]>
of course transpose() still allows it, so, kinda shrug
<adamgreig[m]>
I think just add a line about not giving anything else the stolen singleton should cover it
<adamgreig[m]>
ok, that's all we have time for today, thanks all! seeya next week
<adamgreig[m]>
burrbull: I'll push to that PR branch now with an updated safety text and then let's merge it?
nex8192 has joined #rust-embedded
<eldruin[m]>
<dirbaio[m]> "eldruin: changelogs and feature..." <- done
<adamgreig[m]>
burrbull: done
<burrbull[m]>
and #741 maybe?
<adamgreig[m]>
<burrbull[m]> "and #741 maybe?" <- could you add Cargo.lock to it and remove from .gitignore?