09:58 <re_irc> <MathiasKoch> Does anyone here already have an async wrapper (std) around a defmt decoder & rtt upchannel? Something along the lines of an async stream that can be awaited to get decoded defmt frames?

10:14 <re_irc> <matejcik> could someone help me troubleshoot "cargo-call-stack"? or, well, more specifically, cross-compiling examples?

10:14 <re_irc> my crate is originally a "staticlib", the result would then be linked to more C code for the final image.

10:14 <re_irc> I changed it to normal lib (otherwise neither binaries nor examples see the crate??), successfully built and linked the example against the parts of the C code that it needs. (i believe the linking step succeeds, because I also know how to make it _fail_, and how to fix that failure)

10:14 <re_irc> after that, I can successfully _build_ the example, but call-stack complains that ".text section not found"

10:14 <re_irc> which is true -- the binary is 10 megabytes, but "objdump -h" only reports debug sections, no ".text", no ".data", none of the usual things that would contain any code

10:15 <re_irc> <matejcik> i'm in no_std so I had to enable "#![feature(start)]" and declare a starting point as "#[start] fn start(...)"

10:15 <re_irc> one thing comes to mind that this didn't take and there is no starting point so the linker throws away everything?

10:17 <re_irc> <chrysn (@chrysn:matrix.org)> All I can offer is an old pointer to where I started adding support for static libraries directly (https://github.com/japaric/cargo-call-stack/issues/4) -- but I'm afraid that's terribly outdated and immature :-(

10:27 <re_irc> <matejcik> chrysn: thanks, i actually saw that before .) i'm trying not to tinker with cargo-call-stack before i figure out what is going wrong with the built binary

11:03 <re_irc> <matejcik> so in case anyone is interested:

11:03 <re_irc> instead of tinkering with "feature(start)", I can use "#![no_main]" and then specify a "#[no_mangle] fn _start() -> !"

11:03 <re_irc> this gets me a step further to more linker errors :)

11:03 <re_irc> <matejcik> "_start" seems to be special (https://stackoverflow.com/questions/67918256/rust-custom-bare-metal-compile-target-linker-expects-start-symbol-and-discar)

19:00 <re_irc> <Marco Silva> hello everyon 👋

19:00 <re_irc> <Marco Silva> * everyone

19:01 <re_irc> <Marco Silva> I'm trying to learn rust by doing an embedded project

19:01 <re_irc> <Marco Silva> so I'm in stage 3, coming here for support xD

19:02 <re_irc> <Marco Silva> trying to read a sensor that uses I2C, and sending the data to usb serial

19:02 <re_irc> <Mathias> Stage 3: bargaining? :)

19:03 <re_irc> <Marco Silva> I'm using a pi pico, got the blink to work (stage 1), got the serial to work kinda (stage 2), and now im stuck since yesterday for hours

19:04 <re_irc> <Marco Silva> just managed to get some better error handling so I know it's from i2c, error Abort with code 1

19:04 <re_irc> <Marco Silva> I'm using a driver library but not sure if it's working :/

19:05 <re_irc> <Marco Silva> https://github.com/miek/sht3x-rs this is the one, not sure if sending pastebins is allowed here so I can share my code

19:07 <re_irc> <Marco Silva> http://localhost:8008/_matrix/media/r0/download/matrix.org/GXbkfSFFkWAMhafykqDXLcZs/main.rs

19:07 <re_irc> <Marco Silva> looks like I can just do that :/

19:08 <re_irc> <Marco Silva> it's based on the pico template

19:08 <re_irc> <Marco Silva> I'm sure it's really bad code xD try not to get tilted

19:11 <re_irc> <Marco Silva> on the hardware side I'm using the stuff from Grove, with the sensor connected on the shield with the cable on I2C0

20:32 <re_irc> <jannic> According to https://wiki.seeedstudio.com/Grove-I2C_High_Accuracy_Temp&Humi_Sensor-SHT35/ (if that's the module you are using), the default address is "0x45", which would be "Address::High", but your "main.rs" shows that you are using "Address::Low".

20:32 <re_irc> This also matches the error code 1, which just means that no device acknowledged the address.

21:49 <re_irc> <Marco Silva> ty jannic , I've seen som examples with it to low, just changed it but I still have the same error

21:49 <re_irc> <Marco Silva> im also using I2C0, and some people have it in 1. would that make any difference?

21:51 <re_irc> <Marco Silva> I think I might need to do some type of waiting to set up the device before it being ready, but not sure what I should write to do it. the guy that wrote the crate I'm using is using this driver on a normal pi, so it's a bit different with the /dev/ port, and maybe the OS does the handshaking needed

21:58 <re_irc> <Marco Silva> just reading the i2c code I see a code saying that the way I'm doing is enabling it in "master" mode, it should be "slave" right? is it related with this https://github.com/rust-embedded/embedded-hal/issues/179