Guest7655 has quit [Killed (zinc.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
<re_irc>
<farbod peimanzadeh> thread 'main' panicked at 'Unable to find libclang: "couldn't find any valid shared libraries matching: ['libclang.so', 'libclang-_.so', 'libclang.so._', 'libclang-_.so._'], set the "LIBCLANG_PATH" environment variable to a path where one of these files can be found (invalid: [])"', /home/esp/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.59.2/src/lib.rs:2144:31
<re_irc>
<farbod peimanzadeh> I can't build my esp32 project. it's been one week. :((
<re_irc>
<gauteh> farbod peimanzadeh: maybe you need to install libclang and/or clang
<re_irc>
<gauteh> I'm trying to write a defmt-serial target. And right now I'm trying to set up a logger that works on a generic embedded_hal::serial::nb::Write static mut *. So far so good, but probably other ways to solve this. The problem shows up when I try to use the Write::write trait-func of a dyn Write static reference. It seems to be related to the Error returned by the write function which in this case has unknown size, which...
<re_irc>
... makes sense... But I am not interested in the error (except whether it is an error or not). Presumably this is needed for rust to know how much stack space to allocated.. but is there any way to avoid this or drop the error type?
<re_irc>
<9names (@9names:matrix.org)> ESP32 setup is a bit more complex than other targets, toolchain issues come up pretty often in #esp-rs:matrix.org (https://matrix.to/#/#esp-rs:matrix.org)
<re_irc>
Maybe ask / search history in there?
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 248 seconds]
cr1901_ is now known as cr1901
<re_irc>
<jounathaen> I'm struggling hard with arrays of peripherals from the svd2rust crates. I'm talking about the rp2040_pac and I want to move ownership of a single dma channel, but in the PAC the register clusters are are stored in an array (https://docs.rs/rp2040-pac/0.3.0/rp2040_pac/dma/ch/index.html).
<re_irc>
I tried everything, but I can't move them out of that &%$# array.
<re_irc>
<jounathaen> The HALs I checked implement a "split" method for that peripheral which creates distinct objects out of that array
<re_irc>
<jounathaen> Sounds fine, but I can't get it to work. Example code:
<re_irc>
<mabez> farbod peimanzadeh: Did you install the custom compiler + Xtensa enabled clang? The esp-rs/rust-build (https://github.com/esp-rs/rust-build) repo has prebuild toolchains that you can install for your OS :)
<re_irc>
<chemicstry> I'm encountering some strange struct layout issues. If I do "size_of" "struct Test(bool, bool, bool)" I get 3 bytes, seems logical. However, when I add u64 like "struct Test(u64, bool, bool, bool)" you would expect size to be 8+3=11, or at least 12 to align to 32bit system (cortex-m), but instead I get 16. Why does the struct suddenly become aligned to 64 bits, when the platform is 32bit?
<re_irc>
<bugadani> well, good link, not so good quote... but it looks like u64s are aligned to 8 bytes and that sets the alignment of your struct as well?
<re_irc>
<chemicstry> ah yeah, makes sense. Not sure why u64 should be aligned to 8 bytes on cortex-m though?
<re_irc>
<chemicstry> I guess it's because cortex-m4 has some double word instructions, but couldn't find any info on their alignment yet. Anyway, seems that my problem is deeper than I thought :D I was just investigating why my config struct is so large
<re_irc>
<mabez> bugadani: Not too sure, I just copied the data layout from clang 🙈
<re_irc>
<mabez> AFAIK there are no double word instructions on the esp32, and definitely not on the c3 or s2 (I think there are some on the s3 though) so I think this could be changed
<re_irc>
<mabez> +for those targets
<re_irc>
<bugadani> woohoo free code size gains
<re_irc>
<bugadani> * size/memory efficiency
<re_irc>
<9names (@9names:matrix.org)> chemicstry: the alignment of a struct doesn't imply the size of it though... are you mixing terms here?
<re_irc>
<bugadani> 9names: It kind of does, though. If size is the offset between array elements, and a field has to be aligned to a particular address, the size of the object is a multiple of that alignment.
<re_irc>
<chemicstry> "The size of a value is always a multiple of its alignment" from rust docs. And struct alignment is always the largest of all elements I assume
<re_irc>
I guess that's why the target definition specifies it that way in the "data_layout". Perhaps LLVM just doesn't allow to configure in-memory alignment separately from function-call alignment?
<re_irc>
<9names (@9names:matrix.org)> or more likely there were bugs when they had different sizes
<re_irc>
<jannic> BTW that spec also definies the struct size similar to the rust reference: "The size of an aggregate shall be the smallest multiple of its alignment that is sufficient to hold all of its members when they are laid out according to these rules"
<re_irc>
<jannic> So it probably can't be changed by rust as long as it wants to stay ABI compatible to C.
<re_irc>
<9names (@9names:matrix.org)> it makes sense. i guess my mental model allows for other stuff to be placed in the padding, but even in that case that unpadded "size" would not be very useful to anyone
<re_irc>
(With "#[repr(packed)]" the nested struct also has a size of 16)
<re_irc>
<Ivan Levitskiy> Now having trouble with fatfs again. I got the FS into idle function and i can successfully create a new file. Write_all into the file returns Ok but when I connect the sd card to a pc I there is no text in the created file. The same code placed in init works correctly
<re_irc>
<mabez> Ivan Levitskiy: Presumably the file doesn't get dropped in idle task? In which case you'll need to manually flush or close the file before unmounting
<re_irc>
<Ivan Levitskiy> mabez: Thank you! A flush helped. But I don't really understand why I didn't need it in init
<re_irc>
<mabez> Ivan Levitskiy: The "Drop" impl for "File" flushes the in memory changes to disc when it goes out scope. Init will end, idle goes on for ever hence drop never happens :)
<re_irc>
<mabez> * forever
<re_irc>
<9names (@9names:matrix.org)> jounathaen: I've replied on the rp2040-pac issue you made. I don't check the PAC very often since it doesn't get much activity.
causal has joined #rust-embedded
<re_irc>
<Ivan Levitskiy> mabez: Oh, okay. Thank you for explaining
<re_irc>
<Ivan Levitskiy> Is there a good way to go into the built in stm32f4 DFU bootloader from software?
<re_irc>
<jounathaen> 9names: Thank you, I'll check it out!
<re_irc>
<Tom> is there an embedded http server in rust?
<re_irc>
<almindor> Afaik there isn't even a tcp/ip stack