00:15 <rafael[m]> barafael: have You ever played with MPU9250 as opposed to MPU6050? It seems like this is an improved version with better ADC & a magnetoscope added. I read some people have managed to get it working with a mpu6050 driver, not using added precision and also not the added sensor data of course. Anyway, I ordered one and maybe I can build on top of Your driver 🙂

08:01 <barafael[m]> I haven't, only bno085. Good luck! Make sure to check other people's work too

08:38 <albus_dandelion[> Hi! I have a very stupid question. When device sending information with UART this will be on the tx wire, but at the same time does it sending something on rx? Like, anti-phase or something. Or rx only for receiving?

08:46 <FreeKill[m]> <albus_dandelion[> "Hi! I have a very stupid..." <- In general, no. Tx carries data one way, Rx the other

08:47 <FreeKill[m]> But your intuition is good - because some physical serial protocols like RS422 do use 2 wires per lane, which carry the signal differentially in precisely the way you describe.

08:52 <FreeKill[m]> * In UART, no. Tx carries data one way, Rx the other

09:19 <M9names[m]> In case you were not aware, tx is a shortened version of the word "transmitter", and rx is shortened version of "receiver".

09:19 <M9names[m]> If you think of them in terms of those words, it doesn't make sense for the receiver to send anything.

11:13 <barafael[m]> rafael: version 0.5.0 of mpu-6050-rs has been released on crates.io!

11:13 <barafael[m]> * of mpu-6050-rs with your examples, massive doc effort, and hw/sw motion detection has been

11:15 <barafael[m]> I'm thinking, with the amount of features, the current API, async, defmt feature, e-hal-1... we could go 1.0 here

11:24 <barafael[m]> * of mpu-6050-rs with your examples, temperature sensor, massive doc effort, and hw/sw motion detection has been

11:33 <barafael[m]> elpiel found some issues where calibration might overflow internally: https://github.com/barafael/mpu6050-dmp-rs/pull/6. I'm thinking we could just use checked math there and return results in case of overflow?

11:45 <Ralph[m]> <barafael[m]> "I'm thinking, with the amount of..." <- since defmt should probably soon hit v1.0 (https://github.com/knurling-rs/defmt/discussions/888) you might want to wait for that? then you have all stable dependencies

12:03 <rafael[m]> <barafael[m]> "I'm thinking, with the amount of..." <- Given the fact that the both of us struggle with all the details I'd say let it rest a while and wait what people report. But the usage on crates.io is very low, probably mostly bots, so that may never happen.... I am happy to let You make that choice either way.

12:06 <elpiel[m]> <barafael[m]> "elpiel found some issues where..." <- I'm unsure how I got to this result but it was the first time I used the breakout board.

12:06 <elpiel[m]> Apart from this I haven't met any other issues.

12:06 <elpiel[m]> I would personally like to make a few improvements on the crate if 1.0 will be in the works soon

12:07 <elpiel[m]> I tried to use checked_* but then I still got a panic from Rust's core 😅

12:13 <rafael[m]> I can't have a look today since my kids are queueing up to play TinyGlade on my laptop, but I remember reading that calibration accumulates data and if there is vibration/movement while calibration it may fail or take indefinitely. I never saw that happen last two days. But I have exactly one device from an electronics kit.

12:15 <rafael[m]> And later there is this Christmas thing ... I am kind of expected to attend, also I have cooking duty so no code for me today 😕

12:23 <elpiel[m]> rafael: no worries, it's good to know there's an issue and a known test case that needs to pass 😅

12:23 <elpiel[m]> As for vibrations... Idk actually, it was on my desk all of the time without any noticeable vibration when I bumped into this issue.

12:24 <rafael[m]> You cannot repro, can you?

12:28 <elpiel[m]> Not anymore

12:28 <elpiel[m]> I think the edge case was present only on initial calibration, aka first time use

12:29 <elpiel[m]> There are some hints in the tests though

12:29 <elpiel[m]> And they should be enough to fix the calibration imo

14:53 <AlexandrosLiarok> If I have a custom linker section for a function and I call other functions that do not use a custom linker section how does it work?

14:54 <AlexandrosLiarok> I guess the others are always placed in the .text section like normal ?

14:54 <AlexandrosLiarok> unless inlined

14:54 <AlexandrosLiarok> yea I guess that would be the only thing that makes sense

14:54 <berkus[m]> AlexandrosLiarok: Sections are a link-time concept, not runtime.

14:54 <AlexandrosLiarok> they do affect the relative jump offsets no ?

14:54 <berkus[m]> Usually function sections are merged into the .text segment by the linker

14:55 <berkus[m]> AlexandrosLiarok: no, they affect the linker's ability to move functions around and remove them if unreferenced

14:55 <berkus[m]> the linker has no idea about your source language, it only operates sections and cross-refs (and the addresses/relocations are resulting from the final arrangement of sections to segments)

14:57 <AlexandrosLiarok> Can I not have a function call into a function that is not placed in the .text segment? (Eg because I may want it to be executed from RAM instead.)

14:58 <berkus[m]> You can call to anywhere, the placement to segments is controlled by linker script.

14:58 <AlexandrosLiarok> yea I mean having a custom section that puts the functions into a custom REGION

14:58 <berkus[m]> yes, that's easily controlled by the linker script

14:59 <berkus[m]> the addresses will be generated by the linker based on the segment placement

14:59 <berkus[m]> i.e. if one fn is in .text AT 0x4000_0000 and another is in .my_sec AT 0x8000_0000 they will have appropriate start addresses

15:00 <berkus[m]> calling one() will call to 0x4000_0000 and calling another() will call to 0x8000_0000, because these are simply markers to generate addresses appropriately

15:02 <AlexandrosLiarok> okay that's what I assumed as well, unless the second one is inlined I guess.

15:02 <berkus[m]> if it's inlined it will not have a section at all

15:03 <AlexandrosLiarok> I am trying to see how to produce a single binary that will use an external flash region by default

15:03 <AlexandrosLiarok> but I want to perform the entry in embedded flash.

15:03 <AlexandrosLiarok> to do init, enable ext flash etc.

15:03 <AlexandrosLiarok> I am using cortex-m-rt

15:05 <AlexandrosLiarok> So I guess:... (full message at <https://catircservices.org/_irc/v1/media/download/AX-rPA-_Kb6oi2Nd3jZl2RsFnk3iM_7PbMI0btRnvhQqi-Z6oSgUh0bzT-_fj8p1NuhOy8ZZCPjCPvigSB9kybm_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9pZEh0YWN5TGtsZ3lTb0N0dmRuSmh0QnA>)

15:05 <berkus[m]> I have this for my chain bootloader - it links at 32M, but is loaded and executed from 0x8_0000 by the system https://github.com/metta-systems/vesper/blob/f96cf8f85c743033c4fac5cab98a3b85257c22d0/bin/chainboot/src/link.ld#L52-L65

15:07 <berkus[m]> AlexandrosLiarok: something like this yes;

15:07 <berkus[m]> there is also a nice thing called NO_CROSSREFS and it was recently merged in LLVM iirc, that helps to see you do not have accidental references between sections; it will probably not help you because you need to have refs, but can be useful debugging tool to track them

15:08 <AlexandrosLiarok> thanks for the code!

15:08 <AlexandrosLiarok> and for the tip :)

15:14 <JamesMunns[m]> Yeah, my usual way of explaining this is:... (full message at <https://catircservices.org/_irc/v1/media/download/AZEZuHE-Oq11HGzjfhEFvA0PxBeXvgapp1kROapcLtxxewmvgwFDS4Ci9kzaRcc-ZNE8zoHe5dhfKGHgp0FIxpe_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9DU3ViVGt6QnR5bUdYdUtBR0hPU2tTUWk>)

15:15 <JamesMunns[m]> (this isn't always very convenient, especially in Rust, because ABI)

15:16 <AlexandrosLiarok> yea I know, splitting into different programs and doing the chaining would be best but currently can't due to limitations in the embassy-stm32 repr(C) stuff. So I am just exploring doing it in a single binary instead.

15:16 <JamesMunns[m]> yeah, the real challenge though (if you want to ensure nothing is in flash, for example, in hot RAM-only interrupt handlers), is that the stdlib functions will always end up in "normal" sections. Not sure if that is relevant for your use case though!

15:17 <AlexandrosLiarok> Yea that's why I think using the external flash region as the default "FLASH" region would help in this case.

15:18 <AlexandrosLiarok> on the other hand this means kind of forcing cortex-m-rt sections to be placed to the custom non-FLASH region instead.

15:18 <JamesMunns[m]> I would be surprised if you couldn't do pre-linking tweaks of object files/archives, to move their sections. But Cargo isn't going to do it (or be happy about it), so you might end up needing to make everything a staticlib or something and have a final linking step manually driven with lld or something.

15:18 <AlexandrosLiarok> hmm I guess that create sissues if the driver core calls stdlib stuff yea

15:18 <JamesMunns[m]> yeah, memcpy is usually the one that gets you :D

15:18 <AlexandrosLiarok> * hmm I guess that create sissues if the driver core calls non-inlined stdlib functions.. hmm..

15:18 <JamesMunns[m]> lots of normal rust code will be optimized to a memcpy from the stdlib.

15:18 <AlexandrosLiarok> * hmm I guess that create sissues if the driver code calls non-inlined stdlib functions.. hmm..

15:19 <berkus[m]> JamesMunns[m]: 🤷 https://github.com/metta-systems/vesper/blob/f96cf8f85c743033c4fac5cab98a3b85257c22d0/bin/chainboot/src/boot.rs#L101

15:19 <AlexandrosLiarok> * hmm I guess that creates issues if the driver code calls non-inlined stdlib functions.. hmm..

15:19 <berkus[m]> and of course a -fno-builtins for the compiler

15:19 <JamesMunns[m]> berkus[m]: yeah, but I mean stuff where you even just pass a struct by value. llvm will go "hey that's a memcpy"! and turn it into an intrinsic call

15:20 <JamesMunns[m]> berkus[m]: ah there it is lol

15:20 <berkus[m]> JamesMunns[m]: yep, true

15:20 <JamesMunns[m]> it's possible, and I bet you could even build some relatively nice tooling around it. I just haven't needed it yet, and I haven't seen anyone publicly doing it yet.

15:22 <JamesMunns[m]> JamesMunns[m]: my favorite is when you write your own opinionated memcpy (for size, speed, whatever), and the compiler looks at it and goes "that's a memcpy"! and replaces it with the stock memcpy lol

15:38 <berkus[m]> <JamesMunns[m]> "my favorite is when you write..." <- Yes, this is exactly what happened to my local_memcpy and local_memset :)

15:38 <berkus[m]> "Oh look you wrote a bad version of memcpy, here's the better one, it's also NEON, who cares you are a kernel with no NEON state prepared"

16:42 <FreeKill[m]> <JamesMunns[m]> "my favorite is when you write..." <- Or when it sees the assignments in your impl of memcpy and replaces them with memcpy and you recurse yourself into a stack overflow 😋

19:04 <thejpster[m]> https://danielmangum.com/posts/vpr-nordic-risc-v-processor/

19:04 <thejpster[m]> Has anyone here tried programming FLPR or PPR in Rust?

19:17 <JamesMunns[m]> No atomics? 😭

23:23 <M9names[m]> RV32EMC is going to be pretty close in size/efficiency to a cortex-m0.

23:23 <M9names[m]> If youAdding atomics

23:23 <M9names[m]> s/If youAdding atomics/If your adding atomics you might as well go RV32IMAC/

23:24 <M9names[m]> s/If youAdding atomics/If you're adding atomics you might as well go RV32IMAC/

23:25 <M9names[m]> I assume they prioritised less gates for lower power because it's always on even when the bigger cores are off?

23:43 <M9names[m]> apparently AndesTech do have a configuration of one of their CPU IP's in an RV32EMAC configuration - can't find any evidence that it's ever been used, but that's often the case for deeply embedded MCUs anyway