06:18 <re_irc> <Oliver> Hey I'm wondering if there is some kind of logging library adapter that allows logging via a sdmmc peripheral to a fat32 file? Currently my project is using "embedded-sdmmc"

13:49 <re_irc> <luojia65> I wrote an ARM Trustzone demo in Rust

13:49 <re_irc> (based on a new ARM manual, uses xtask to help execution)

13:49 <re_irc> https://rustcc.cn/article?id=eeec71c9-e1ab-4035-8509-171fae76ce6f

15:13 <re_irc> <James Munns> Nice! You should tweet about it and tag "@rustembedded" luojia65 :D

15:14 <re_irc> <James Munns> Oliver: Not out-of-the box, but if your driver supports streaming to a file, and maybe file rotation (like "logrotate" on the desktop), https://github.com/jamesmunns/defmt-bbq/ will allow you to take defmt logs and receive them as a stream, which you could dump to a file.

15:16 <re_irc> <James Munns> You would need the elf file/debug info (of the firmware that produced the logs) to decode the messages. However, you could also write a similar logging adapter for the "log" crate using a similar technique.

15:16 <re_irc> <James Munns> But that does still require you to handle your own finalization, rotation, etc. of logs.

15:19 <re_irc> <James Munns> Also, only semi-related, I wonder if "defmt-bbq" would benefit from a "dual mode", which supports RTT and/or bbqueue sink. Often I debug devices via RTT (e.g. "probe-run"), but then deploy them to the "field", where I get logs over the network or something. Usually I use a feature flag to switch between "defmt-rtt" and "defmt-bbq", but I wonder if it could be "smart" enough to sink to both, or even detect if a probe...

15:19 <re_irc> ... is attached and use RTT when it is, and use the sink otherwise.

15:23 <re_irc> <James Munns> (if that sounds interesting, let me know or open an issue, otherwise I might get to it next time the feature is annoying me). An even better optimization would be to use the same buffer for efficiency, but I think that would require some surgical hax on both libraries to support (probably forking "bbqueue" AND "defmt-rtt" to make it happen).

15:23 <re_irc> <James Munns> But I am working with some boards with only 8K of RAM, so it might be worth that to not have 1024 bytes for bbqueue and 1024 bytes for defmt-rtt at the same time :)

15:31 <re_irc> <Michael Eden> this is kinda long shot, but has anyone experienced an i2c device not working in a release build but working fine in debug? I just open it with i2c dev and send one ioctl (to identify the chip, it should always return the same value) and I get different results in different builds

15:31 <re_irc> <James Munns> That smells like a DMA/ordering problem. Which chip are you using?

15:32 <re_irc> <James Munns> and can you link to the HAL you are using (or your I2C driver)?

15:32 <re_irc> <James Munns> Michael Eden ^

15:32 <re_irc> <Michael Eden> oh interesting, is there a way to force the ordering?

15:32 <re_irc> <James Munns> Yeah, usually by adding "compiler_fence()" or "fence()" calls in the right places

15:34 <re_irc> <Michael Eden> literally just "LinuxI2CDevice::new("/dev/i2c-3", I2C_ADDRESS)" and then a read of "0x0016" is my code

15:34 <re_irc> <Michael Eden> this is interesting though, I've never used fence

15:34 <re_irc> <James Munns> for example, note the "compiler_fence" calls in the nrf52840 HAL, which "synchronize" that the compiler should not re-order certain operations (which could cause it to have bad data): https://github.com/nrf-rs/nrf-hal/blob/54c658644497031970700ab1432558166f0cc90b/nrf-hal-common/src/twim.rs#L203-L246

15:34 <re_irc> <James Munns> ohhh

15:34 <re_irc> <James Munns> on linux... hmmm

15:35 <re_irc> <James Munns> "compiler_fence" says "hey compiler, be careful what you optimize across this barrier"

15:35 <re_irc> <James Munns> "fence" does the same for the compiler, but also instructs the CPU to do the same (usually for things like cache control) at runtime.

15:35 <re_irc> <James Munns> I have _no_ idea how that applies on linux, rather than bare metal though :(

15:36 <re_irc> - Timing problems (the release code is "too fast", you were getting lucky with the speed in "debug" mode)

15:36 <re_irc> <James Munns> but "works in debug, not in release" usually means one of two things:

15:36 <re_irc> - Incorrect unsafe code/optimizations, which often "remove" the hardware side effects you wanted

15:38 <re_irc> <James Munns> Since you're on linux, you might be able to use "strace" to monitor the syscalls that your program performs in debug/release mode, to see if it is doing the "same" thing

15:38 <re_irc> <James Munns> if not, that might help you diagnose what is wrong with the "i2cdev" crate

15:41 <re_irc> <Michael Eden> thank you! I'll try to look into fence, I already tested that both are making the same syscalls (and they appear to be in the same order) and I've tried placing sleeps to slow it down

15:42 <re_irc> <James Munns> (it'll be a lot to look at, but hopefully looking at or diffing the output should help you notice patterns, or where things differ)

15:42 <re_irc> <James Munns> yeah, fence shouldn't be necessary on desktop, AFAIK, but this is outside of my area of expertise :/

16:09 <re_irc> <dalepsmith> Michael Eden: Also, might be a good idea to look at the _timing_ of syscalls

16:52 <re_irc> <yruama_lairba> hi, with cargo embed, is there a way to copy in a file what happen inside a channel during a rtt sesion ?

17:36 <re_irc> <ryan-summers> Why not just use piping into tee? "cargo embed | tee rtt-output.log"

17:37 <re_irc> <ryan-summers> You'll have some header info from the flash process, but everything after would just be RTT

17:51 <re_irc> <Christof Petig> If you would like to see Rust in automotive and functional safety please consider joining our working group at SAE to define best practices for ISO 26262 compliant projects in Rust. More information at https://connection.sae.org/volunteeropportunities/volunteer-opportunity-details?VolunteerOpportunityKey=057a92a9-c6b8-4405-ae81-e293136a9284

17:51 <re_irc> PS: There is also a similar task force within AUTOSAR SAF at your preference - I am still waiting for the press release to manifest, thus I can't link to it yet.

18:01 <re_irc> <ryan-summers> That page doesn't seem to provide a mechanism to apply or nominate someone unless you're an SAE member

18:04 <re_irc> <ryan-summers> Christof Petig: ^

18:44 <re_irc> <taunusflieger> Seems that SAE membership is required

19:06 <re_irc> <James Munns> Christof Petig: Christof Petig if you haven't reached out to the folks at Ferrous Systems yet, now would be a good time :)

19:09 <re_irc> <James Munns> ryan-summers: I guess that makes sense, it would seem more odd if they were soliciting free/unpaid volunteers from the public. At least as a member/company member, it's more likely your work would be "sponsoring" that effort (at least covering the time spent on it)_

19:09 <re_irc> <James Munns> * it)

19:10 <re_irc> <James Munns> Also if you can tweet that link Christof Petig and tag "@rustembedded", happy to retweet it to spread it around.

19:13 <re_irc> <allexoll> anybody know if/how i can have a closure in a trait implementation? imagine you want to have a trait similar to serial::read, but with 1 closure to call to set a Countdown timer, and another to check if that timer has expired? I'm trying something similar but i think "rustc" is trying to tell me i'm taking this on the wrong way...

19:17 <re_irc> <James Munns> Are you trying to emulate some kind of "callback" mechanism?

19:20 <re_irc> <allexoll> mhh yes. I'm trying to find a way to have a timeout detection on serial RX basically

19:20 <re_irc> <allexoll> i'm fine with it being limited to needing the "timer::countdown" trait, so arbitrary callback is not needed per say, it was just one way that i thought it could be done

19:50 <re_irc> <allexoll> but there are issues with the type requirement for the Countdown timer it seems, as it is currently removed from embedded-hal...

19:51 <re_irc> <Christof Petig> ryan-summers: Sorry, that I didn't check for the page to provide a direct contact or feedback form even if you are not logged in. If you are interested please write directly to Jennifer.grider(at)sae.org , she organizes access formalities - and I can tell for sure that besides investing your time, there is no financial fee involved with becoming a member of this working group.

19:52 <re_irc> <Christof Petig> And please include a CV or link to a page describing your background.

19:54 <re_irc> <Christof Petig> James Munns: Florian Gilcher became already a member of this group, so I assume Ferrous is aware 😉.

19:54 <re_irc> Thank you for the offer to retweet, I will create an account …

20:32 <re_irc> <Christof Petig> taunusflieger: It seems that a login on that page is indeed needed to contact SAE, but you only need to apply for a free membership in the working group (or its mailing list). Please use the e-mail address above if you are interested (or just DM me).

20:55 <re_irc> <Christof Petig> James Munns: I can tell for sure that all people in their working groups are volunteers - and I would also prefer to contribute to a freely accessible standards document (e.g. the ANSSI one), but that just seems to not align with how automotive software development works at the moment. 🤷

21:04 <re_irc> Using alpha status free software for functional safety doesn't sound scary enough to me any longer, I have seen C/++ code.

21:04 <re_irc> <Christof Petig> … and I just want to be able to use embassy in series projects.

22:22 <re_irc> <tamashi> Hi there! Does anybody know how to show deprecation warnings? I'm very new to rust but noticed that "stm32f1xx_hal::device" and "stm32f1xx_hal::stm32" are aliases for "stm32f1xx_hal::pac", however I have not found a way to show deprecation warnings which I assume is possible since they have the "#[deprecated]" attribute?

22:31 <re_irc> <firefrommoonlight> Does it not do so in the normal compiler warnings?

22:35 <re_irc> <firefrommoonlight> I just tested:

22:35 <re_irc> warning: use of deprecated function `find_access_points`

22:36 <re_irc> <firefrommoonlight> Also, Pycharm/IntelliJ rust is marking the function call to the deprecated function with a strikethrough

22:37 <re_irc> <tamashi> I can write e.g. "stm32f1xx_hal::device::Peripherals::take().unwrap();" and do not get any warnings. I also don't have the deprecate notice with auto-complete, but I'm using vscode.

22:38 <re_irc> <firefrommoonlight> Link to the fn that has the "[deprecated]" attr

22:38 <re_irc> <firefrommoonlight> * Post

22:38 <re_irc> <firefrommoonlight> On GH or w/e

22:39 <re_irc> <tamashi> https://github.com/stm32-rs/stm32f1xx-hal/blob/master/src/lib.rs#L132

22:41 <re_irc> <firefrommoonlight> Now, post its use in your code

22:42 <re_irc> <firefrommoonlight> Eg, copy + paste into a code block or w/e

22:44 <re_irc> <dirbaio> "#[deprecated]" on "pub use" does nothing, rust bug: https://github.com/rust-lang/rust/issues/30827

22:50 <re_irc> <tamashi> Oh I see thanks! Yeah it doesn't work with e.g. the examples from the "stm32f1xx-hal" repo (replacing "pac" with "device"). I have been relying a bit on the editor auto completing and navigation for learning things so was a bit confused why these did the same things until I noticed some where deprecated in the source. Anyway thanks again!

23:51 <re_irc> <yruama_lairba> never saw"#[deprecated]" outside the standard library. Is this usable in other crate with stable ?