<re_irc>
<James Munns> Maybe try driving directly instead of through the Lora driver?
<re_irc>
<James Munns> Like just send a byte or something manually?
<re_irc>
<ub|k> Users of "embedded-sdmmc-rs", anyone experiencing often getting stuck at "TRACE: Enter SPI mode, attempt: 0." >
<re_irc>
<ub|k> ?
<re_irc>
<ub|k> Users of "embedded-sdmmc-rs", anyone experiencing often getting stuck at "TRACE: Enter SPI mode, attempt: 0."
<re_irc>
<ub|k> Users of "embedded-sdmmc-rs", anyone experienced often getting stuck at "TRACE: Enter SPI mode, attempt: 0."
<re_irc>
<henrik_alser> ub|k: What spi clock freq are you running? Note that many controllers require some phases to run at a lower speed
<re_irc>
<henrik_alser> SEGFAULT: Yeah maybe try and just connect mosi to miso and do a transfer to see if the problem is with the spi peripheral itself or if it’s something in the lora driver
bjc has joined #rust-embedded
<re_irc>
<ub|k> henrik_alser: 400kHz
<re_irc>
<ub|k> That should be low enough, right?
<re_irc>
<SEGFAULT> James Munns: Thanks, I figured it out in the end, the spi was fine, my logic probe is broken :(
<re_irc>
<henrik_alser> ub|k: Definately…
<re_irc>
<henrik_alser> Is it just random?
<re_irc>
<henrik_alser> What hardware are you using?
<re_irc>
<ub|k> it seems so. sometimes it works ok 2 times in a row. sometimes it just stops working for large periods. it's a rpi pico.
<re_irc>
<henrik_alser> How is it connected to the sd controller?
<re_irc>
<henrik_alser> Could it be some intermittent breadboard situation?
<re_irc>
<ub|k> it's actually soldered
<re_irc>
<ub|k> just wires directly from the sd adapter to the mcu
<re_irc>
<ub|k> of course everything works fine once I plug in the logic analyzer :|
<re_irc>
<ub|k> heisenbug
<re_irc>
<ub|k> but like... every. single. time
<re_irc>
<ub|k> hm... maybe some pull-up resistors missing?
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<ub|k> ok, so, if I attach a probe to MISO, it just works
<re_irc>
<ub|k> probe off, problems
<re_irc>
<chemicstry> do you have correct pullups?
<re_irc>
<chemicstry> oh sorry, missed your message :D well MISO definitely needs a pullup
<re_irc>
<dirbaio> but yeah in practice it doesn't happen anyway
<re_irc>
<dirbaio> and there were talks in some Rust issues about not marking references to interior-mutable data as "dereferenceable" which would fix the issue for svd2rust and other PACs using VolatileCell
<re_irc>
<dirbaio> (I still think using raw pointers all the way is cleaner though. It avoids some other issues with provenance, for example)
<re_irc>
<Tom> does volatile register work this way as well or does it have the deref issue?
<re_irc>
<Tom> I don't have an svd file to generate a regmap from :-)
<re_irc>
<dirbaio> volatile read/write on raw pointers is the way to go for mmio regs, yes
<re_irc>
<dirbaio> the issue on svd2rust pacs is it uses stuff like "&vcell::VolatileCell<u32>"
<re_irc>
<dirbaio> * "&vcell::VolatileCell<u32>", then when actually reading/writing it converts it to "*mut u32" and then does a volatile read/write
<re_irc>
<dirbaio> the problem is using references ("&"), because when rust lowers them to LLVM IR it marks them as "dereferenceable"
<re_irc>
<Tom> I get all of that, I guess I'm now wondering if I could maybe make a little code gen on top of chiptool then without needing svd's
<re_irc>
<Tom> I mean I guess I could just write xml... but who wants to do that
<re_irc>
<dirbaio> it supports a yaml format too, a bit nicer to write than XML
<re_irc>
<dirbaio> you can convert yaml to rust with "chiptool gen-block"
<re_irc>
<dirbaio> for a single peripheral only
<re_irc>
<dirbaio> generating a "full" PAC is only possible straight from SVD right now, with "chiptool generate"
<re_irc>
<dirbaio> you can use chiptool as a lib too to script whatever, or to use it from build.rs", this is what "stm32-metapac` does
<re_irc>
<dirbaio> * build.rs, this is what "stm32-metapac"
<re_irc>
<Tom> awesome, thanks!
<re_irc>
<Tom> seems like a significant improvement over svd2rust
<re_irc>
<Tom> now... I wonder if it could generate a pac for nxp's imxrt that wasn't close to 1mloc, which made svd2rust semi-useless
<re_irc>
<Tom> because yeah, like 10m to compile a register access crate was unacceptable
<re_irc>
<Trevor Gross> I brought up ArrayVec in core yesterday, here's the followup https://github.com/rust-lang/rfcs/pull/3316#issuecomment-1248430640. I don't think ArrayVec will actually happen, because the "Storage" API brought up there looks significantly more powerful. Which is awesome - it would let you do crazy things like use the "Vec" API within a fixed-length array/slice buffer (potentially including a qword DMA buffer?), keep a...
<re_irc>
... persistant hashmap in a fixed few kb of flash, something crazy like manipulating a string within a VLA, etc. Or skipping linked list allocators entirely if you use them, to keep Vec/HashMap/etc in a static (e.g. safety-critical needing definitive stack analysis)
<re_irc>
<Trevor Gross> Of course a lot of this is possible with "heapless"
<re_irc>
<Trevor Gross> But it's nice that "core" will likely gain this incredible abstraction
<re_irc>
<Trevor Gross> And the flexibility it brings is extremely powerful, another tier to abstraction
<re_irc>
<Trevor Gross> +memory
<re_irc>
<chemicstry> Trevor Gross: Really cool! This seems something what GPU people would also be interested in with GPU storage types, but I've been out of the loop for a while (since gfx deprecation)