00:11 <firefrommoonligh> Also, if anyone wants hot-takes on how to code AHRS in Rust, lmk

08:16 <ryan-summers[m]> <firefrommoonligh> "More rust flight controller..." <- > <@firefrommoonlight:matrix.org> More rust flight controller; changed up the control scheme so it holds attitude... but still flies like rate controls bc the RC input changes the target attitude. Should make feeding into the autopilot smooth.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/jxhbhOGxxOSKnotHWjVswioP>)

11:08 <thejpster[m]> Mara is thinking about a new binary-size WG … https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Binary.20size.20working.20group

11:10 <timokrgr[m]> yes please!

11:25 <tr09[m]> Hi, anybody good with smoltcp? I’ve implemented a phy::Device but when polling interface RxToken is always demanded, even though I’ve received 0 bytes and can’t really construct it. Why isn’t my Device’s transmit method called instead?

11:42 <whitequark[cis]> i designed it; does that mean i'm good at it?

11:44 <whitequark[cis]> if you have nothing to receive, return None from Device::receive()

11:44 <whitequark[cis]> the interface first receives, then transmits, so once you signal you have nothing to receive, you might get a frame to transmit

11:46 <whitequark[cis]> here are the key lines: https://docs.rs/smoltcp/latest/src/smoltcp/iface/interface/mod.rs.html#734-735

12:59 <tr09[m]> Catherine: perhaps I’m misusing tcp socket then, because it receives a packet, presents data in a .recv and *apparently* endlessly tries to ack it and never progresses. If the connection is closed from server side, remaining data is provided normally.

12:59 <thejpster[m]> https://github.com/rust-lang/rfcs/pull/3470 is very cool if you want your Rust bootloader (or BIOS) to talk to your Rust application (or OS).

13:00 <tr09[m]> I say apparently because poll_delay returns whatever I set socket ack delay to be

13:05 <whitequark[cis]> <thejpster[m]> "https://github.com/rust-lang/..."; <- this is so cool

13:05 <whitequark[cis]> <tr09[m]> "Catherine: perhaps I’m misusing..." <- do you have code I can look at?

13:11 <tr09[m]> <whitequark[cis]> "do you have code I can look at?" <- One moment

13:12 <jessebraham[m]> I frankly don't really understand it or the motivation behind it, so will need to read through the comments in more details. Honestly kind of with Bjoern right now though, doesn't really seem like something that belongs in the HAL to me, but maybe I'm just missing something here.

13:12 <jessebraham[m]> Not sure if I'll get to it today so I can try to take a look next week

13:40 <tr09[m]> <whitequark[cis]> "do you have code I can look at?" <- I hope I removed the right things

13:40 <whitequark[cis]> thanks

13:43 <whitequark[cis]> that looks reasonable to me at first glance

13:45 <tr09[m]> As I mentioned, it starts issuing (in this configuration) 999 delays but never attempts to get an TxToken

13:46 <whitequark[cis]> can you enable verbose logging?

13:46 <whitequark[cis]> that will show all of the TCP state transitions

13:46 <whitequark[cis]> ideally a packet tracer too

13:47 <tr09[m]> Maybe. This is currently on bare metal and semihosting takes ages.

13:58 <tr09[m]> I’ll need to try setting up logging over serial or single step it. Thanks for now!

14:00 <marmrt[m]> Log over RTT!

14:03 <tr09[m]> Ha, this device does have eink, but that might be on the same level as semihosting. Serial over Bluetooth?

14:08 <ryan-summers[m]> Use RTT. It's way faster

14:18 <tr09[m]> By RTT do you mean something over SWDIO or just serial?

14:18 <ryan-summers[m]> RTT is a protocol developed by Segger called "Real-Time Transfer. It uses a ring buffer in RAM that firmware and the debug probe read from

14:19 <ryan-summers[m]> So it's super fast because the debug probe is just reading target memory, the only actual overhead for your firmware is formatting it into the ring buffer

14:21 <ryan-summers[m]> probe-rs, probe-run, probe-rs-cli and the like all have native support for it and it makes it super easy to use

14:22 <ryan-summers[m]> And if you use defmt on top of it, logging is even lower overhead

14:23 <M9names[m]> regarding my C lib linking issue, adding "-mlong-calls" was all that was needed, and for my use-case enabling it has no performance impact.

14:23 <M9names[m]> thanks for the help y'all

14:28 <JamesMunns[m]> good fix! where did you pass that?

14:31 <M9names[m]1> As a .flags() call off of cc::build in my build.rs file

14:32 <firefrommoonligh> <ryan-summers[m]> "> <@firefrommoonlight:matrix.org..." <- Scratch-ish; built on top of the Knurling tools, STM32 PACs, and RTIC. Yep, re FPV quad. Going to try a larger quad next (Currently 3"; 5" next). I have a lot of WIP fixed-wing code too, but want to get all systems working on the quad first. Next up is a waypoint system; first with heading indications on the OSD, then fly-to-waypoint autopilot.

14:32 <firefrommoonligh> Currently having mystery IO issues on the GPS... Puzzling since I have a working standalone CAN AHRS/GPS device with a similar MCU, same GPS chip, and the same code...

14:46 <adinack[m]> <firefrommoonligh> "More rust flight controller..." <- > <@firefrommoonlight:matrix.org> More rust flight controller; changed up the control scheme so it holds attitude... but still flies like rate controls bc the RC input changes the target attitude. Should make feeding into the autopilot smooth.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/cuDPXMowJIRwjcaLoIOSYsLT>)

14:53 <calisti[m]> <firefrommoonligh> "More rust flight controller..." <- > <@firefrommoonlight:matrix.org> More rust flight controller; changed up the control scheme so it holds attitude... but still flies like rate controls bc the RC input changes the target attitude. Should make feeding into the autopilot smooth.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/WxYcqmPJSYBaYtLBAVHfqhyo>)

15:23 <firefrommoonligh> So RN it does not fly nearly as well/smoothly as BF

15:23 <adinack[m]> well i'm sure everyone will agree, we're all rooting for you

15:23 <firefrommoonligh> But I think the PC configuration/status checks/setups etc are simpler/easier. With teh important note that it's hard-coded to run on 2 boards

15:23 <firefrommoonligh> I'd like to move everything to CAN only in the future for flexibility

15:31 <firefrommoonligh> I think the trouble with BF (And, more-so AP and PX4) is they cater to such a large range of hardware and use cases, you get code and UIs/config that is very complex, and has growing hardware (mainly flash space) requirements

15:32 <firefrommoonligh> So I'm trying to keep that under control by not supporting arbitrary hardware