00:15 <re_irc> <almindor> does anyone know if there's a way to tell gdb to "shorten" the ludicrously long fulltype names when viewing things in "layout asm" mode?

00:20 <re_irc> <9names (@9names:matrix.org)> answering my own question: http_io (https://crates.io/crates/http_io/) seems like a good candidate. there's someone already using it with core2 (https://crates.io/crates/core2), shouldn't be hard to move it to embedded-io (https://crates.io/crates/embedded-io)

02:22 <re_irc> <sis3020> Come try the top mmorpg https://splog.win/ wyrmob experiment now

06:40 <re_irc> <762spr> Still having trouble with cargo and the stm32l4xx-hal package...

06:40 <re_irc> I downloaded it and changed the dependency for stm32l4 to version 0.15.1, then in my original project's cargo.toml I updated it to point to the new path of my local version:

06:41 <re_irc> [dependencies.stm32l4xx-hal]

06:41 <re_irc> version = "0.7.1"

06:41 <re_irc> ... long message truncated: http://localhost:8008/_matrix/media/r0/download/psion.agg.io/399d7db837e7e5ac66bcd2a393b5c71f393ebf9d76a976fb65401e39cd2362d9 (6 lines)

06:57 <re_irc> <burrbull> You can use 'cargo tree' to see all dependency tree

07:00 <re_irc> <762spr> should I do that on the HAL library or on my main project?

07:02 <re_irc> <762spr> esc_tester v0.1.0 (C:\Users...\Documents\VSCode_workspace\STM32\ESC_Tester)

07:02 <re_irc> ├── cortex-m v0.7.5

07:02 <re_irc> │ │ [build-dependencies]

07:02 <re_irc> ... long message truncated: http://localhost:8008/_matrix/media/r0/download/psion.agg.io/5dee7b38e20afb275d8902495b8faf602ae293f0f571e98aaefd249cfbdaa405 (79 lines)

07:02 <re_irc> │ ├── bare-metal v0.2.5

07:02 <re_irc> <762spr> it doesn't seem to be linking it to the PAC but maybe I am misunderstanding how it is supposed to work?

07:03 <re_irc> <762spr> oh nevermind, I missed that it was below it.

07:08 <re_irc> <762spr> still not really sure why it isn't integrating and thinks it is redefining everything though

07:38 <re_irc> <firefrommoonlight> Don't add PAC as a dependency. Use the HAL's re-export

07:44 <re_irc> <762spr> 😮 I thought it could figure that out on it's own! OK, that makes sense, but now it complains that I don't have the features selected ["stm32l4x2", "rt"]

07:44 <re_irc> Is there a way to pass that on through the main project or should that be added to the HAL library?

07:48 <re_irc> <762spr> I put it in the HAL's cargo.toml and re compiled my project. Same result. 463 re-defines...

07:54 <re_irc> <762spr> ok I must have something seriously wrong with my setup somehow... if I try to just build the library, I get the same 463 re-define errors, so I tried building it with version 0.14.0 of the PAC which is the default one, it STILL gives me the same errors!

07:55 <re_irc> <firefrommoonlight> Post your cargo.toml deps section

07:55 <re_irc> <jspngh> You should have something like this in your project

07:55 <re_irc> path = "/path/to/stm32l4xx-hal"

07:55 <re_irc> features = ["stm32l476", "rt"]

07:55 <re_irc> [dependencies.stm32l4xx-hal]

07:55 <re_irc> <jspngh> and in your local stm32l4xx-hal copy, you only need to change the version of the "stm32l4" dependency.

07:56 <re_irc> <jspngh> Like firefrommoonlight is saying, don't put the stm32l4 dependency in your project

07:56 <re_irc> <762spr> ok let me try that real quick. I think I tried it before and it didn't like setting the features that way but I am not sure

07:57 <re_irc> <jspngh> You will have to fix some small things in the HAL though, since it's not ready for the 0.15 PAC yet

07:57 <re_irc> <762spr> error: failed to select a version for "stm32l4xx-hal".

07:57 <re_irc> ... required by package "esc_tester v0.1.0 (C:\Users\Matt\Documents\VSCode_workspace\STM32\ESC_Tester)"

07:57 <re_irc> versions that meet the requirements "^0.7.1" (locked to 0.7.1) are: 0.7.1

07:57 <re_irc> the package "esc_tester" depends on "stm32l4xx-hal", with features: "stm32l4x2" but "stm32l4xx-hal" does not have these features.

07:57 <re_irc> failed to select a version for "stm32l4xx-hal" which could resolve this conflict

07:58 <re_irc> <762spr> yeah I may just have to give up on the HAL for now I think this is over my head :/

07:59 <re_irc> <762spr> it doesn't seem to like selecting features through the HAL crate

07:59 <re_irc> <762spr> [dependencies.stm32l4xx-hal]

07:59 <re_irc> features = ["stm32l4x2", "rt"]

07:59 <re_irc> path = "../stm32l4xx-hal"

07:59 <re_irc> version = "0.7.1"

08:00 <re_irc> <jspngh> The problem is that the available features have been changed in the master branch, but not yet in the last release on crates.io

08:00 <re_irc> So the feature that would have worked if you used the crates.io package, won't work anymore when you are using the master branch on your local copy

08:00 <re_irc> <jspngh> In the Cargo.toml file you can see the available features: https://github.com/stm32-rs/stm32l4xx-hal/blob/master/Cargo.toml

08:01 <re_irc> <jspngh> You will see that L4x2 has been split up

08:01 <re_irc> stm32l432 = [ "stm32l4/stm32l4x2" ]

08:01 <re_irc> # L4x2

08:01 <re_irc> stm32l442 = [ "stm32l4/stm32l4x2" ]

08:01 <re_irc> ... long message truncated: http://localhost:8008/_matrix/media/r0/download/psion.agg.io/89fe9c068eb858424466f51f52672d6f7fc65c6745e2655a6e848bbac4a4159f (6 lines)

08:01 <re_irc> <jspngh> You will see that L4x2 has been split up

08:01 <re_irc> stm32l442 = [ "stm32l4/stm32l4x2" ]

08:01 <re_irc> # L4x2

08:01 <re_irc> stm32l432 = [ "stm32l4/stm32l4x2" ]

08:01 <re_irc> ... long message truncated: http://localhost:8008/_matrix/media/r0/download/psion.agg.io/5640c71104e618e388ba84dad68f40660e92cbdcd8f30571a6327f121a48beac (6 lines)

08:02 <re_irc> <762spr> oh yeah I was wondering about that. I tried setting it to l432 because that's what I'm running but it errored out. makes sense now that you mention they don't match

08:02 <re_irc> <jspngh> If you use this

08:02 <re_irc> [dependencies.stm32l4xx-hal]

08:02 <re_irc> Do you still get an error?

08:02 <re_irc> features = ["stm32l432", "rt"]

08:02 <re_irc> path = "../stm32l4xx-hal"

08:03 <re_irc> <jspngh> So, leaving out the version + using "stm32l432"

08:04 <re_irc> <762spr> well, it's down to 22 errors 😅

08:06 <re_irc> <762spr> they are all of similar nature to:

08:06 <re_irc> ... long message truncated: http://localhost:8008/_matrix/media/r0/download/psion.agg.io/182dd0ff75097c725fe89f690a6c79db0b5347603157969c0a3bc3505c58de82 (17 lines)

08:06 <re_irc> error[E0615]: attempted to take value of method "ccr1" on type "stm32l4::stm32l4x2::tim1::RegisterBlock"

08:06 <re_irc> |

08:06 <re_irc> --> C:\Users...\Documents\VSCode_workspace\STM32\stm32l4xx-hal\src\pwm.rs:225:48

08:06 <re_irc> <jspngh> Yes, those are the differences between 0.14 and 0.15 that need to be fixed

08:06 <re_irc> <jspngh> You can send me a private message if you need help

08:06 <re_irc> <762spr> ah.

08:07 <re_irc> <762spr> well the compiler seems to be giving reasonable suggestions, I guess I could take a crack at fixing them on my local copy. If not I guess I will just wait for the smart people to get to it 😂

08:17 <re_irc> <762spr> Actually that was really easy! most of the 22 errors were duplicates and I only had to change the code in like 5 spots! It seems to be working now. Thank you so much for all your help and for all your work on making these crates! Obviously I could never do this on my own so you make it possible for guys like me to make stuff!

08:18 <re_irc> <762spr> and for putting up with all of my super noob questions! 😂

09:52 <re_irc> <David Rheinsberg> Hey! We have recently starting looking for a home for UEFI development in rust. We are working on getting the UEFI rustc targets at Tier-2 and try to setup centralized documentation and ecosystem information. We were wondering whether rust-embedded would serve as a suitable home, and whether you are open to have us as a team? We are in contact with people across different companies, including Red Hat, Google,...

09:52 <re_irc> ... Microsoft, and Intel, trying to better centralize the UEFI efforts in Rust. I can gladly open an issue in the wg-repository instead, but just wanted to get some general comments here first.

09:53 <re_irc> <David Rheinsberg> Note that it is not a perfect fit for "embedded" development, but I personally think the overlap is big enough, given the challenges we face with UEFI platforms.

11:17 <re_irc> <firefrommoonlight> jspngh: Btw, the reason for this is that the L412 uses a different (newer) RTC than the others

11:17 <re_irc> <firefrommoonlight> I had a fun surprise when swapping between 2 diff 4x2 chips wherein my RTC stopped working

11:18 <re_irc> <firefrommoonlight> * L4x2

11:38 <re_irc> <adamgreig> David Rheinsberg: an issue on the wg tracker is probably a good idea, I agree you probably face very similar challenges (I guess maybe it's "also bare-metal" instead of "also embedded"?) and we could certainly have a new team, or maybe it would end up making more sense to have a new working group

11:41 <re_irc> <chemicstry> David Rheinsberg: I think the main problem is that UEFI development is focused on application processors such as Cortex-A or x86, which is not really common in embedded-rust ecosystem. There are just a few crates for cortex-a, used mainly for raspberry pi bare-metal experiments. Usually how it works with "embedded-rust" is that crates start as separate projects and if/when they become popular enough, they get moved...

11:41 <re_irc> ... to "embedded-rust" so it could be maintained even if the main author is gone. The question is how much code can be shared so that both parties (UEFI and embedded-rust) have interest in co-maintaining

12:17 <re_irc> <David Rheinsberg> chemicstry: Cortex-A and RISCV would be two excellent examples of target architectures for UEFI which rust-embedded is also interested in. The UEFI PEI-stage could share the same board-setup crates even. But I am not so much looking for a home for UEFI crates, but rather a home to discuss work on rustc (e.g., curating the uefi targets, working on porting core/std) and documenting the status quo.

18:15 <re_irc> <James Munns> If any of y'all want a fun mnemOS PR: smash together adamgreig's LEDC code, and make a driver service for it (the UART send DMA is a good example for this, and add it to the demo env :D

18:15 <re_irc> <James Munns> Wrong room 😅, but having fun with the Allwinner D1 :D

18:17 <re_irc> <dirbaio> nerdsnipe-driven development, hmmm? :D

18:18 <re_irc> <James Munns> Yeah, pretty much!

18:18 <re_irc> <James Munns> "let everyone else do the fun PRs"

21:15 <re_irc> <thalesfragoso> Did someone already mentioned here that &UnsafeCell isn't dereferenciable anymore ?

21:15 <re_irc> <thalesfragoso> &mut UnsafeCell still is though, but I think the only way to get a &mut to a RegBlock is through the raw ptr, right ?

21:16 <re_irc> <thalesfragoso> CC adamgreig for svd2rust insight

21:28 <re_irc> <dirbaio> how can you match all cortex-m using cfgs?

21:32 <re_irc> <dirbaio> ilke "cfg(target_arch = "arm")" but matching only cortex-m arms

21:36 <re_irc> <dirbaio> you can't match entire targets, like "cfg(target = "thumbv7em-none-eabi")"?

21:39 <re_irc> <dirbaio> I know there's the "build.rs" trick, but I need this in a proc-macro

21:40 <re_irc> <dirbaio> alternatively, is there a way to get the target from a proc macro?

21:48 <re_irc> <mabez> dirbaio: AFAIK, its not possible but I hope someone has a solution. I had to use features on the proc macro crate which were enabled by another crate: https://github.com/esp-rs/esp-hal/blob/224e84d9dcbf286431375b62cc2ec1b0a47272d8/esp-hal-procmacros/src/lib.rs#L217-L225

21:49 <re_irc> <dirbaio> yeah that's sort of what I have now, would like to remove it D:

21:49 <re_irc> <mabez> also I have no idea what I'm doing with proc macros, just bumbling along until something works :D

21:49 <re_irc> <dirbaio> same here lol

21:51 <re_irc> <dirbaio> the issue is here https://github.com/embassy-rs/embassy/blob/master/embassy-macros/src/macros/main.rs#L104

21:51 <re_irc> <dirbaio> currently it assumes cortex-m (if features "std" and "wasm" aren't enabled)

21:52 <re_irc> <dirbaio> but I'd like it to emit "#[cortex_m_rt::entry]" or "#[riscv_rt::entry]" or "#[xtensa_lx_rt::entry]"or nothing (for std) automatically...

21:57 <re_irc> <mabez> What about if you added the "cfg_attr" in your proc macro? and let the compiler do the work for you. e.g

21:57 <re_irc> quote! {

21:57 <re_irc> #[cfg_attr(target_arch = "arm", cortex_m_rt::entry]

21:57 <re_irc> #[cfg_attr(target_arch = "xtensa", xtensa_lx_rt::entry]

21:57 <re_irc> ... long message truncated: http://localhost:8008/_matrix/media/r0/download/psion.agg.io/0d543f332eb314e0e12ab87dbca8cafc65ba429cd539ca5e53e78ed648c458e1 (14 lines)

21:57 <re_irc> <dirbaio> that would add "#[cortex_m_rt::entry]" for non-embedded ARM though

21:57 <re_irc> <mabez> Then the proc macro doesn't need to know the arch, because the compiler will resolve it once the code is emitted?

21:57 <re_irc> <mabez> Ah I see, arm is the tricky one

21:58 <re_irc> <dirbaio> raspi linux, or macos m1/m2

21:58 <re_irc> <dirbaio> perhaps with target_os 🤔

21:59 <re_irc> <dirbaio> that'd also fail for riscv32 linux (not that it's very common..)

21:59 <re_irc> <dirbaio> "#[cfg_attr(all(target_arch = "riscv32", not(unix), not(windows)), riscv_rt::entry]" 🤪

21:59 <re_irc> <dirbaio> (is macos "unix"?)

21:59 <re_irc> <mabez> Yeah "target_os = "none"" along with the arch _should_ filter out everthing right?

22:00 <re_irc> <dirbaio> ah "none" is a thing?

22:00 <re_irc> <mabez> indeed!

22:00 <re_irc> <dirbaio> oooh :D

22:52 <re_irc> <almindor> http://localhost:8008/_matrix/media/r0/download/matrix.org/PGejYQmlsRwEDZSyOxXIcNan/dc_races_spi.png

22:52 <re_irc> <almindor> does anyone know how something like https://www.klgrth.io/paste/tve5y could produce this racing pin output?

22:53 <re_irc> <almindor> somehow the DC pin is set in the middle of the SPI transfer. In this capture I used the "displayinterface" abstraction and the DC is set smack in the middle of the 2 command bytes. When I used raw SPI like in the code, it's set even sooner, before the 1st byte is even done transmitting

23:04 <re_irc> <9names (@9names:matrix.org)> maybe the spi write returns once all data is in a fifo, not when all data has finished transmitting?

23:06 <re_irc> <almindor> we're doing a manual loop over each byte tho, it's a 32bit register with 8bit data field for the data, so when we're doing this spi.write it translates( in software) into loop of reg_write(u8)

23:07 <re_irc> <almindor> i guess if the register write returns before the data is actually output, we could race it here, issue is, I don't see how to check that anywhere in the spec (e310/hifive board), there's just the "full" bit AFAICS

23:08 <re_irc> <almindor> maybe we need to wait for "full" to be 0 before returning from the byte push itself

23:12 <re_irc> <9names (@9names:matrix.org)> a bit surprising that they don't have a fifo empty flag.

23:12 <re_irc> maybe you could set the transmit watermark to 1, then check the interrupt pending register to see if txwm is set.

23:14 <re_irc> <almindor> hmm good point I didn't think about using that

23:21 <re_irc> <almindor> http://localhost:8008/_matrix/media/r0/download/matrix.org/AMiOVoYjsjDEfzxJiEqIMJNJ/dc_races_txmark.png

23:21 <re_irc> <almindor> this is so odd, doing while "spi.ip.read().txwm().bit_is_clear()" (with txmark being 1) delays the DC set to high smack in the middle of the 2nd byte transfer

23:24 <re_irc> <almindor> * "while spi.ip.read().txwm().bit_is_clear() {}"

23:34 <re_irc> <almindor> inserting an artificial delay after each transfer is done (say reading a csr couple times) make it "work"

23:36 <re_irc> <James Munns> mabez: I used this to notch out my panic handler when I'm building with "--all-features"