00:39 <firefrommoonligh> <PhilMarkgraf[m]> "What approach do folks use for..." <- > <@shakencodes:matrix.org> What approach do folks use for having multiple drivers share a resource like an I2C or SPI bus? For example, I am using eldruin's excellent eeprom24x driver and need to write a driver for an ADC on the same I2C bus. The... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ecUxLccMHIYBEZtbLMtmdtDB>)

00:39 <firefrommoonligh> And make sure you're sequencing them appropriately

00:40 <firefrommoonligh> For example starting one transfer in the transfer-complete ISR of the prev one or w/e

07:39 <MathiasKoch[m]> I have my memory layout setup like this... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HYowIlnMpuuaQUfBYPWbrxeZ>)

08:37 <JamesMunns[m]> There's ~3 ways to do this MathiasKoch:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/qaQyTvxczWXLfSKRmrJXMegp>)

08:38 <JamesMunns[m]> The downside to 1 is that you will probably place your stack guard at a fixed location, which means you don't get the "most" area available

08:39 <JamesMunns[m]> I'd probably add your own stack guard object in `> RAM` at the bottom of the page, then keep stack start at the end of RAM, then assert (stack start - end of guard) >= 59K

08:39 <MathiasKoch[m]> I think 1 is essentially what i have above, right? With the stack guard placed at a fixed location

08:39 <JamesMunns[m]> yeah, I think above is approximately 1, with a section instead of a placed object

08:40 <MathiasKoch[m]> Cool! That should work! Can i do an assert in memory.x, or does it need to go at the bottom of link.x? does the order of operations matter in a linkerfile?

08:49 <JamesMunns[m]> order of operations matter, I think you'll want something like this? (check me, my linker syntax is bad):... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/xiIGgGgJasNzwqTBIlIPBAYv>)

08:49 <JamesMunns[m]> or something like that?

08:49 <JamesMunns[m]> I'm not certain that just bumping . will cause linking to fail if it overflows RAM, you'd want to check that

08:51 <JamesMunns[m]> https://docs.rs/cortex-m-rt/latest/cortex_m_rt/ is a good guide about what you can add in your link.x

08:51 <JamesMunns[m]> s/link/memory/

08:52 <JamesMunns[m]> https://docs.rs/cortex-m-rt/latest/cortex_m_rt/#extra-sections

08:54 <JamesMunns[m]> If bumping `.` *doesn't* do it, I'd probably suggest adding something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/pVgxLEKZBuXZXeYrZBChWgZT>)

08:56 <JamesMunns[m]> With the statics, I'd use this instead:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/yllsBfLFgmPCEMzLFVyBhyhp>)

08:57 <JamesMunns[m]> Someone better at linker scripts might have a more elegant suggestion, but I think you get what I'm going for :)

08:59 <JamesMunns[m]> Ah it's also #[used] not #[keep]

09:01 <ryan-summers[m]> Does anyone know why cargo isn't setting CARGO_CFG_TARGET_FAMILY during the build? The docs indicate it should always be present

09:02 <ryan-summers[m]> It's not being set, which is causing built to fail to run on my build because of it being missing

09:03 <ryan-summers[m]> Not sure if this is a cargo bug, as I don't know what I'd expect that to be

09:09 <MathiasKoch[m]> James Munns: Thank you very much for the pointers! That should get me started on something that will work 👍️

15:08 <olsen__[m]> Hi all, i currently try to migrate a c project using freertos (wrapped with cmsis) partly to rust. As the architecture ist more or less different in terms of memory and shared data i have questions. :) I have multiple tasks (preemptive) that should have access to a spi driver. Have you any hints for sharing data, and more general rules of thumb for migrating that relatively large project?

15:36 <thejpster[m]> Mara just opened a stream for a “binary size working group”

15:37 <mabez[m]> thejpster[m]: Oh hell yes

15:37 <thejpster[m]> <olsen__[m]> "Hi all, i currently try to..." <- How do you share the SPI driver in the FreeRTOS version?

15:44 <fuse117[m]> is defmt more robust (or better) than rtt-target?

15:49 <olsen__[m]> <thejpster[m]> "How do you share the SPI..." <- Using a native c api (cmsis) and created a kind of wrapper in rust to share the entity among the threads within rust space.

15:50 <Lumpio-> Does CMSIS handle locking for you?

15:51 <Lumpio-> Or how does it prevent multiple tasks from accessing it at the same time

15:51 <Lumpio-> Oh is it that CMSIS-RTOS thing?

15:51 <olsen__[m]> Nope, that must be part of the wrapper

15:51 <AngelLofey[m]> Join my private chat room

15:52 <AngelLofey[m]> Live s.ex with me for free???

15:52 <AngelLofey[m]> http://yours.baby/pUaqFYa

15:52 <AngelLofey[m]> Copy and paste link on any browser create an account , put your age 45+ confirm your email and give me screenshot

15:52 <Charles[m]> might want to consider setting up the ruma automod bot in this room

15:53 <jessebraham[m]> @dirbaio @James Munns @adamgreig

15:54 <Charles[m]> that account was added to the ruma automod bot's banlist 20 minutes ago

15:54 <olsen__[m]> Lumpio-: Yes, but still native c

15:54 <Charles[m]> * minutes ago (i.e. before the account joined this room)

16:54 <thejpster[m]> So you’ve got two options. Using CMSIS-RTOS functions to lock access to the shared objects. Or have the SPI owned by just one task add have other tasks post it messages containing commands that it will complete on their behalf using the SPI bus. I don’t know what you’re building but I’ve built several systems of the latter design.

17:27 <JamesMunns[m]> <Charles[m]> "might want to consider setting..." <- Do you work with that? If so would you mind being at the meeting tomorrow at 8pm cest? Might be good to discuss then

17:27 <JamesMunns[m]> (cc adamgreig for agenda reasons)

17:36 <Charles[m]> Yeah, we use it in Rust (lang) and Conduit Matrix Server and probably others too. I can be at the meeting but I think all it takes is inviting it and giving it a high enough power level

17:37 <Charles[m]> There's a control room I'd invite you to so you can, well, control it

17:57 <JamesMunns[m]> Cool! Any docs we could/should read first?

18:35 <Charles[m]> i'm pretty sure it's just an instance of https://github.com/matrix-org/mjolnir

19:59 <ilpalazzo-ojiis4> <M9names[m]> "Looks like all the avr templates..." <- I did just that, thank you. But… the errors persist.

20:00 <ilpalazzo-ojiis4> Hmmmmmmm. The errors only appear when compiling with --release.

20:00 <ilpalazzo-ojiis4> Let me check something real quick…

20:01 <ilpalazzo-ojiis4> Yes, changing the optimisation level from 3 to "s" makes the problem go awaya.

20:01 <ilpalazzo-ojiis4> * Yes, changing the optimisation level from 3 to "s" makes the problem go away.

20:02 <ilpalazzo-ojiis4> Still, I'd rather have a definitive solution.

20:53 <M9names[m]> Is that segfaulting in the compile phase or the link phase?

20:53 <M9names[m]> If the latter, which linker are you using?

20:55 <M9names[m]> Is it this?

20:55 <M9names[m]> https://github.com/rust-lang/rust/issues/107261

21:09 <M9names[m]> The folks that would know best what is broken in avr are in avr-rust/Lobby, but I see you've already posted this there as well 😕

21:18 <M9names[m]> Llvm support for avr is not finished. The "definitive solution" is to fix it yourself, work around issues like this when they come up or switch to an arch that isn't so broken.

22:57 <ilpalazzo-ojiis4> You've probably noticed, their channel is not exactly what one would call “active”.

22:59 <PhilMarkgraf[m]> Following the [removal of traits with unconstrained Time associated types](https://github.com/rust-embedded/embedded-hal/pull/324/), has anyone "landed" these in a new location outside of embedded-hal? (This is mentioned in the discussion.)

22:59 <PhilMarkgraf[m]> If not, what are people doing at the moment? Are we copying the trait into a file local to its usage?

23:05 <dngrsspookyvisio> is there a `no_std` friendly alternative to [linefeed](https://docs.rs/linefeed/latest/linefeed/) ?

23:14 <cr1901> https://crates.io/crates/noline ?

23:14 <dngrsspookyvisio> cool, thx!

23:15 <cr1901> Last commit was in mid-2022, but the author checks PRs at least: https://github.com/rustne-kretser/noline/pull/17

23:16 <dngrsspookyvisio> no completion, sadface... but I think I can implement that myself

23:16 <cr1901> I'd be curious to see completion w/ only static buffers

23:17 <dngrsspookyvisio> I never said no_alloc 😬

23:17 <cr1901> Ahhh :(

23:18 <cr1901> Anyways, I've not used this crate yet. But it's under my starred crates on crates.io, so I'm watching w/ interest

23:18 <dngrsspookyvisio> I mean, it'd be cool, but I'm looking for quick wins first

23:18 <dngrsspookyvisio> and since the project is a VM, I'll pretty much need alloc anyway. I tried writing one with `no_alloc` but it's so enormously tedious to guess all the heapless struct sizes

23:19 <dngrsspookyvisio> (I did make it work but then quickly abandoned the branch)

23:19 <cr1901> I commend your effort to make it work out of spite

23:20 <dngrsspookyvisio> spite is my main motivator

23:21 <cr1901> I know that feeling :)