ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
cinemaSundays has quit [Quit: Connection closed for inactivity]
m5zs7k has quit [Quit: m5zs7k]
m5zs7k has joined #rust-embedded
cinemaSundays has joined #rust-embedded
cinemaSundays has left #rust-embedded [#rust-embedded]
jxsl has joined #rust-embedded
lehmrob has joined #rust-embedded
<SbastiendHerbais> dirbaio: Now that it's the morning, thanks again for your help, I ended up creating a custom build of probe-rs with the modified address map, however it gives a different error now:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/gPqqybxOwrjIBiBMrCMQGjBF>)
<SbastiendHerbais> I did however confirm that it knows about this address range using probe-rs chip info and it does show it correctly
<SbastiendHerbais> After changing some more things, I do see reference in the logs of the algo, and I added my own tracing::info call to print out the algorithm and it chooses the right one, however it still doesn't work with the same error as I had mentioned previously
<M9names[m]> usually with STM32 you need to use --connect-under-reset, are you doing that?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/cKgbGxMttAQLUxurvpKKDdkn>)
<danielb[m]> might be worth trying to change ap to 0. not sure why the pack contains ap: 1, but the reference manual has 0x00: AP0 - Cortex-M7 debug access port
<danielb[m]> * might be worth trying to change ap to 0 in core_access_options. not sure why the pack contains ap: 1, but the reference manual has 0x00: AP0 - Cortex-M7 debug access port
<dirbaio[m]> that's working in embassy HIL tho
<dirbaio[m]> or did it get changed 0->1 in the pack updates?
<danielb[m]> no I don't think it did
<danielb[m]> but 1 has a very cryptic explanation of "D3" next to it which is not the core 🤷‍♂️
<dirbaio[m]> 😵‍💫
<danielb[m]> your h7s3 might have some slightly different behaviour 🤷‍♂️
<dirbaio[m]> ¯\_(ツ)_/¯
<danielb[m]> i guess an st-link firmware update would also be worth a try
<danielb[m]> hm I guess `probe-rs info` is useful at this point as it scans through the APs, Dherse run that and paste its output somewhere, please
<danielb[m]> ugh
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
<SbastiendHerbais> >Sorry for answering later, I've had COVID since Thursday and I take naps quite often :|... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DaeRJeyGZlSbaOHZfkQZmThx>)
<SbastiendHerbais> * > Sorry for answering later, I've had COVID since Thursday and I take naps quite often :|... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/iIrhxERbmFyoMRiMXLjEHsRF>)
<SbastiendHerbais> * > Sorry for answering later, I've had COVID since Thursday and I take naps quite often :|... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LbZKVxREeVbpUvQEAVuhnOyh>)
<SbastiendHerbais> * > Sorry for answering later, I've had COVID since Thursday and I take naps quite often :|... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/sDIiaKUQWdUOqMXRWRNZSUFW>)
<SbastiendHerbais> When probing without the `--chip xxx --connect-under-reset`, I get the following which isn't much more useful:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uRvLHBDePcTSTLXznZEbDkPC>)
<SbastiendHerbais> * Sorry for answering later, I've had COVID since Thursday and I take naps quite often :|... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/UmAgLAwzawaVoXAzrlkXbFRe>)
<SbastiendHerbais> > might be worth trying to change ap to 0 in core_access_options. not sure why the pack contains ap: 1... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PHWjmRrUWwFIFJQUISJSslWE>)
<SbastiendHerbais> I realize that this is getting a bit spammy, sorry
<SbastiendHerbais> Ok, seeing the difference, I re-flashed the firmware of the ST-Link (using STM32 Cube programmer) and I get something that makes more sense now:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/mjecCpXQOVHGOCqEKxeRISvO>)
<danielb[m]> ty
<SbastiendHerbais> danielb: you're welcome, thank you for helping me!
<SbastiendHerbais> Ok, I did try a known-good firmware from STM32CubeIDE but flashed using probe-rs and it runs no problem. So clearly there's something wrong with my rust project too... At least with the changes I made, I can flash firmware now 🎉
<SbastiendHerbais> Ok, a bit of a dumb question, but why can't I load from GDB using probe-rs gdb? I can debug which is awesome (almost there), and is there of way of both: launching it with the RTT monitor (probe-rs run) and with a GDB server (probe-rs gdb)?
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]> <SbastiendHerbais> "Ok, a bit of a dumb question..." <- Because the `load` command is not implemented. Loading is done via `probe-rs flash` instead
<ryan-summers[m]> If you want to load the file into gdb, just use the file command instead
MathiasKoch[m] has joined #rust-embedded
<MathiasKoch[m]> What are my options for recursion without an allocator?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LlzbsdYBPvGsGPGtrOrOuisv>)
<ryan-summers[m]> MathiasKoch: Have you looked at https://crates.io/crates/miniconf yet? Its doing essentially that with a proc macro
<ryan-summers[m]> And its a recursive tree structure
<ryan-summers[m]> You could use that for inspiration or extend it if you want to add metadata etc to struct members
<MathiasKoch[m]> Interesting! I will take a look 👍️
<MathiasKoch[m]> Thanks
<ryan-summers[m]> The main driver behind miniconf is it lets you do something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/VfxwkrvkVSeYrpOGiEvYnKaX>)
<MathiasKoch[m]> That is super interesting.
<MathiasKoch[m]> Essentially i have a number of json structures of varying complexity, that I would like to be able to load and store in either EKV or sequential storage, in such a way the each leaf field (primitive types) becomes its own key-value entry. Would that be suitable for miniconf?
<MathiasKoch[m]> * key-value entry in a flattened way. Would
<ryan-summers[m]> Thats why we built it in the first place :) We do that in a crate we're developing for generic settings management via a serial interface: https://github.com/quartiq/stabilizer/tree/main/serial-settings
<ryan-summers[m]> So, yes. That's the intended use case of it. You can also use it for i.e. MQTT trees
<ryan-summers[m]> For example: https://crates.io/crates/miniconf_mqtt
<MathiasKoch[m]> Or similar
<ryan-summers[m]> Yup. The path is configurable too via types, so you could use JSON style paths like .foo.bar or whatever you like. It uses a generic Key trait
<ryan-summers[m]> So it's literally a key-value lookup for structs using serde. All the values are [u8] slices
<MathiasKoch[m]> Thats cool! I'll take a look, and get back if i have any questions :p
<MathiasKoch[m]> Much better than having to reinvent the full wheel :)
<ryan-summers[m]> Yeah it took us a long time to refine it properly. The docs are a bit rough right now because its a complex problem. Been meaning to clean them up and write a blog post on it for a while since I think miniconf is super useful
<ryan-summers[m]> But feel free to ping me if you have Qs, and that'll help me figure out how to reorg any of the docs too
<SbastiendHerbais> ryan-summers: that makes a lot of sense, thanks!
<MathiasKoch[m]> Thanks!
<SbastiendHerbais> OMG finally, I managed to run custom rust code on it from the OSPI flash! Apparently the examples from the embassy repo don't work on this model as it's the configuration of the core (RCC etc.) that was wrong and causing it to be in a bugged(?) state... Need to figure out what parameters work now
<dirbaio[m]> <SbastiendHerbais> "OMG finally, I managed to run..." <- what board and chip do you have?
<SbastiendHerbais> STM32H7S78-DK board with an STM32H7S7L8H6HU. I am re-implementing embassy_stm32::init myself to see which is the part that it doesn't like (proceeding via elimination)
<dirbaio[m]> it's probably the SMPS
<JamesMunns[m]> Very likely, the RCC setup assumes it is in the "reset state" when you call ::init, and by setting up RCC (and maybe other peripherals) for OSPI access, it is getting confused, or hanging because it is making in incorrect state transfer
<JamesMunns[m]> (that being said, defer to Dirbaio's knowledge over my guess 😅)
<dirbaio[m]> ah right it could be that too
<JamesMunns[m]> s/in/an/
<SbastiendHerbais> It's likely something like that indeed, hence why I'm trying to process via elimination since I don't know any better, but since embassy_stm32::init doesn't let me configure whether to do that or not, I guess I'll have to do it manually (for now)
<JamesMunns[m]> I wonder if an unsafe init_with_assumed_rcc(...) method would be a good idea, at least to start
<SbastiendHerbais> Indeed, in my case the RCC is handled by the "bootloader"
<SbastiendHerbais> * the "bootloader" from ST
<JamesMunns[m]> like, you have to manually give all the current RCC settings, which will initialize the various states/globals, then proceed from there. Not sure if that is reasonable tho
subtlename has joined #rust-embedded
subtlename has quit [Changing host]
subtlename has joined #rust-embedded
<dirbaio[m]> there is some defense against RCC being already initialized
<SbastiendHerbais> It stops working as soon as it hits this line:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/TBsEImhxrZfDhPkXpZXdJQEj>)
<dirbaio[m]> it switches back to HSI, then configures everything, then switches to the configured clocks
<JamesMunns[m]> SbastiendHerbais: > <@dherse-hpe:matrix.org> It stops working as soon as it hits this line:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/nQZHyEarJxguWveIPcmtLYNA>)
<dirbaio[m]> hm
<JamesMunns[m]> or at least, maybe change some clocks that could cause Fun and Unexpected Behavior?
<SbastiendHerbais> James Munns: would be a pretty big problem indeed 😅
<JamesMunns[m]> yeah, I don't remember offhand how much embassy resets, but if it touches any "load bearing" clocks or peripherals, that could be bad lol
<dirbaio[m]> syscfg is just random junk bits though
<SbastiendHerbais> That does cause me some headache, since I can't init time_driver as it is private in embassy_stm32
<SbastiendHerbais> so I am sort of stuck either way
<dirbaio[m]> i'd recommend you change embassy-stm32 to a path dep and edit it directly
<SbastiendHerbais> I can turn the LED on then the programs waits forever for a timer that isn't even enabled 😂
<dirbaio[m]> then when you find what's wrong we can fix it upstream
<dirbaio[m]> if you change that line to do enable_with_cs (not reset), does it worK?
<dirbaio[m]> s//`/, s//`/, s/worK/work/
<JamesMunns[m]> Correct me if I'm wrong dirbaio, but my understanding is:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/AZzMJFOvgDNxRrvftLUEeHUc>)
<dirbaio[m]> hmm
<dirbaio[m]> yes but
<JamesMunns[m]> (this is the reasoning behind my unsafe "set with the current state without actually changing any hw settings" suggestion)
<dirbaio[m]> one solution is the "assume init" you mention, which skips doing init
<dirbaio[m]> the other solution is to make init more robust against hw already being inited
<dirbaio[m]> there's no fundamnetal reason you can't just init everything again
<JamesMunns[m]> that makes sense to me! I don't know how reasonable/desirable that is, but it certainly would be better UX
<JamesMunns[m]> dirbaio[m]: you'd have to be *really* careful not to cut off any XIP type stuff, for one
<dirbaio[m]> the only exception is multicore, that you do need the 2nd core to assume_init because the 1st one is already running
<dirbaio[m]> but for single-core, the bootloader is not running anymore
<dirbaio[m]> so we can just reinit everything however we like
<JamesMunns[m]> CC diondokter, who I think is currently poking around multicore things and might have opinions or like to be informed here :D
<dirbaio[m]> currently init doesn't cut off qspi/ospi/xspi, it leaves it alone
<dirbaio[m]> it will change rcc config, that can break xspi if it makes it go too fast
<dirbaio[m]> so you'd have to check how is the BL configured the xspi and make sure your rcc config is compatible with that
<M9names[m]> could you also build up your config based on the current state, rather than assuming the initial state?
<M9names[m]> i assume this would be practically impossible beyond 1-2 layers deep in the clock tree but at least core clock + direct decendents?
<JamesMunns[m]> something like "check if the desired state is the current state, if so, just skip"?
<M9names[m]> that would be simpler
<JamesMunns[m]> and then I wonder about peripherals being in non-reset state, or shared peripherals for multicore? But that's kind of all spooky anyway?
<dirbaio[m]> M9names[m]: > <@9names:matrix.org> could you also build up your config based on the current state, rather than assuming the initial state?
<dirbaio[m]> > i assume this would be practically impossible beyond 1-2 layers deep in the clock tree but at least core clock + direct decendents?
<dirbaio[m]> yeah that's possible too, but it's more code. you'd need code both for "config struct -> registers" and "registers -> config struct". And separate out the code for "config struct -> frequencies". Currently it's a single big function that does "config struct -> registers, frequencies"
<dirbaio[m]> also if the config struct comes from registers, the compiler can't const-propagate anything, so it'd have worse code size
subtlename has quit [Ping timeout: 255 seconds]
diondokter[m] has joined #rust-embedded
<diondokter[m]> <JamesMunns[m]> "I wonder if an unsafe init_with..." <- Just note, I do have an open PR for a proper version of this: https://github.com/embassy-rs/embassy/pull/3158
<MathiasKoch[m]> ryan-summers: Hmm, am I doing something wrong, or is it not possible to use `get/set_json` functions on the root (the entire object)?
<ryan-summers[m]> Isn't that just serializing with serde-json-core?
<MathiasKoch[m]> Ehmm, might be yeah :p makes sense
<ryan-summers[m]> But in general, miniconf defines the data structure as a tree, composed of internal and leaf nodes. You can only get/set on leaf nodes, not on entire subtrees based from some internal node outward
<ryan-summers[m]> Could probably add that functionality if needed though
<ryan-summers[m]> * needed though, but might make trait bounds around ser/de complicated
<MathiasKoch[m]> Makes sense 👍️ I can make due with the leaf nodes
<ryan-summers[m]> You can define an entire complex json structure as a leaf node, something like {"foo": 1, "bar": {"baz": "a"}} can be an entire leaf node, but then you couldn't set bar.baz on its own, itd have to be done atomically with foo and bar
<SbastiendHerbais> <dirbaio[m]> "if you change that line to do ..." <- Which line? 🤔
<dirbaio[m]> <SbastiendHerbais> "It stops working as soon as it..." <- > <@dherse-hpe:matrix.org> It stops working as soon as it hits this line:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/EDpCJnvmQEuqvetwRxaSHdgk>)
<SbastiendHerbais> ah sorry I am dense today it's insane
<SbastiendHerbais> dirbaio[m]: There is no `enable_with_cs` for that type
<SbastiendHerbais> module *
<dirbaio[m]> ah, pft
<dirbaio[m]> or just comment it ouy
<dirbaio[m]> s/ouy/out/
<dirbaio[m]> the bootloader has already enabled it probably anyway
<SbastiendHerbais> There's another line that's causing issues (but that we expected):... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/bakrmCZPAPihijxYXJKaYWve>)
<dirbaio[m]> it's not expected, rcc init should be able to deal with rcc already being configured
<SbastiendHerbais> Ah okay
<dirbaio[m]> there's historically been bugs around this
<dirbaio[m]> but they're that, bugs
<dirbaio[m]> that we should fix
<SbastiendHerbais> I feel like all this stuff is very tricky to make truly generic
<dirbaio[m]> it is :(
<dirbaio[m]> try adding this to RCC config: config.rcc.supply_config = SupplyConfig::DirectSMPS;
<dirbaio[m]> it's a common issue with H7 to not enable the SMPS if the board needs it
<dirbaio[m]> and that h7s dk has is
<dirbaio[m]> s/is/it/
<SbastiendHerbais> If I don't init RCC then it panics when initializing the time_driver.
<SbastiendHerbais> If I do the configuration you suggested, it still leads to the debugger giving SwdApFault errors
<SbastiendHerbais> Ok, so, if I modify the RCC code (enable_and_reset_with_cs) and don't reset, that doesn't cause any issue (there at least)
<SbastiendHerbais> I also identified *what* in the `rcc:init(cs)` code makes it crash, it's when the HSI clock is set as the system clock (line 416):... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dyLJFiaeTWCpJbgWRLVcaUKx>)
<dirbaio[m]> how're you checking this? adding logs at every line?
<dirbaio[m]> or removing the lines?
<SbastiendHerbais> Early return; out of the function
<SbastiendHerbais> can't log in there for some reason
<dirbaio[m]> it should work if you enable the defmt feature
<dirbaio[m]> * it should work if you enable the defmt feature in embassy-stm32
<JamesMunns[m]> SbastiendHerbais: this is because probe-rs does a polling-based attach of RTT, the init is so fast after boot you crash before probe-rs has time to attach
<SbastiendHerbais> It is enabled
<SbastiendHerbais> JamesMunns[m]: That's what I figured as well, but since I can just early return I figured I wouldn't need to do anything fancy to wait for RTT to be ready
<SbastiendHerbais> I am just being selectively lazy 😄
<JamesMunns[m]> you could also do a huge cortex_m::asm::nop to give RTT enough time to init, something like 100ms
<JamesMunns[m]> (before calling init)
<dirbaio[m]> hah
<dirbaio[m]> so hsi is 64mhz on H7
<SbastiendHerbais> AFAIK yes
<SbastiendHerbais> Clock config from an ST example that is known good
<dirbaio[m]> is that the exact config the bootloader is setting?
<SbastiendHerbais> I am not sure, lemme check
<dirbaio[m]> I don't see how changing to HSI can break things, it's just slowing things down wo it can't be exceeding any limits
<JamesMunns[m]> I'm sure there's some appnote somewhere: "oops switching to HSI catches specifically OSPI on fire"
<dirbaio[m]> hahaha
<SbastiendHerbais> It doesn't let me open the IOC file, god I despise eclipse
<dirbaio[m]> xspi in the datasheet specifies just a max
<SbastiendHerbais> That's the bootloader's exact clock tree/config
<SbastiendHerbais> I don't see either why changing to HSI breaks things since it's already in HSI
<SbastiendHerbais> Well no, the SYSCLK uses the PLLCLK as a source
<SbastiendHerbais> which is at 600 MHz not 64
<dirbaio[m]> yea... so changing sysclk 600->64 should make everything after it like 10x slower
<dirbaio[m]> which should be fine ...? 🤷
<SbastiendHerbais> Yes, doing the change in the IOC file and it doesn't complain that anything is "too slow" or whathever
<dirbaio[m]> what's xSPI clocked from?
<SbastiendHerbais> Could it also be changing the pre-scale of the HSI for some reason? Since it doesn't seem to like (in the GUI right) when changing that?
<SbastiendHerbais> Lemme check
<SbastiendHerbais> Reading the datasheet's diagram: I have no idea, it's HCLK5 or ACLK or PLL2_S_CK or PLL2_T_CK????
<SbastiendHerbais> You can actually configure the mux
<SbastiendHerbais> So they're from PLL2S originally in the bootloader
<dirbaio[m]> aha
<dirbaio[m]> so changing sysclk back to HSI is not lowering that
<dirbaio[m]> and
<dirbaio[m]> RM says
<dirbaio[m]> > The XSPI AXI clock (xspi_aclk) has to be greater or equal than the XSPI kernel clock
<dirbaio[m]> (xspi_ker_ck).
<SbastiendHerbais> Hmm I see
<dirbaio[m]> how annoying
<SbastiendHerbais> That seems like a pretty tricky case to workaround
<dirbaio[m]> try changing it to hclk5 before rcc init
<dirbaio[m]> manual writes with the PAC
<dirbaio[m]> * with manual writes
<SbastiendHerbais> Ok, I'll try to do that, gimme a few minutes, this is a bit out of my wheelhouse so-to-speak 😅
<dirbaio[m]> RM0477 page 396
lehmrob has quit [Remote host closed the connection]
<dirbaio[m]> pac::RCC.ccipr1.modify(|w| w.set_xspi1sel(...))
<SbastiendHerbais> Damn you're much faster than me
<SbastiendHerbais> Except that ccipr1 doesn't exist it seems
<SbastiendHerbais> ```rs
<dirbaio[m]> these are readonly bits telling you the state
<SbastiendHerbais> 🤦‍♂️
<dirbaio[m]> ah wtf
<dirbaio[m]> it's AHBPERCKSELR
<dirbaio[m]> OCTOSPI1SEL
<dirbaio[m]> the SVD has different names as the RM
<dirbaio[m]> thanks, ST
<thejpster[m]> dirbaio: i just wanted to let you know your keyboard is broken. Those last few messages were nonsense.
<thejpster[m]> :rofl:
<dirbaio[m]> that's ST for you
<dirbaio[m]> that's how they name registers. they have a room full of cats and keyboards.
<SbastiendHerbais> Now I get the delightful error message:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/upSubBhTIERDZijVYnMDehIq>)
<dirbaio[m]> 🥲
<SbastiendHerbais> If I place it post HSI initialization (inside of init) then it "works"
<SbastiendHerbais> and by works I mean it says nothing but also does nothing
<dirbaio[m]> lol
<SbastiendHerbais> This board really doesn't want to boot 😠
<dirbaio[m]> well if you violate clock constraints things can crash in fun unpredictable ways
<dirbaio[m]> I wouldn't read much into it
<dirbaio[m]> like, getting the error is not necessarily better or worse than getting just a hang
<dirbaio[m]> IIUC to not violate clocks we should switch xspi before switching sysclk..
<dirbaio[m]> to not violate the "bus clock must be faster than xspi clock" thing
<SbastiendHerbais> I think it's fair to say that skipping clock (re-)configuration would be preferable in the end?
<dirbaio[m]> hmhmhmhm
<dirbaio[m]> I dunno 🥲
<dirbaio[m]> it could be. config.rcc.assume_init = true;, then it won't do any rcc register writes but still calculate the freqs based on the settings you've set
<dirbaio[m]> then it's on you to pass the exact same config that the bootloader set, otherwise frequencies might be wrong (e.g uart or spi going too slow/fast)
<SbastiendHerbais> That seems like the most reasonable case, to be fair this is a bit of an edge case and I wouldn't necessarily expect embassy to take that into account
<dirbaio[m]> well this is a recurring problem
<dirbaio[m]> so it does need some fix
<dirbaio[m]> also multicore is a similar issue
<SbastiendHerbais> I was gonna use an STM32H747 initially but multicore just seemed like too much of a pain tbh
<dirbaio[m]> the old h7's also have many fun DMA gotchas that h7rs doesn't have
<dirbaio[m]> h7rs is not a bad option
<dirbaio[m]> if only we can get to boot it lol
<dirbaio[m]> * if only we can get it to boot lol
<SbastiendHerbais> I am also hoping to be able to write a nice slint backend for the onboard "GPU" to get some nice GUIs going on
<SbastiendHerbais> 🎉 🎉 IT BLINKS 🎉 🎉
<SbastiendHerbais> At the wrong speed
<SbastiendHerbais> but IT BLINKS
<SbastiendHerbais> 🎉
<SbastiendHerbais> Sorry, I am getting overly excited 😂
<dirbaio[m]> 🥳
<dirbaio[m]> what was it
<SbastiendHerbais> I'll end up writing a tutorial somewhere otherwise in six months I'll have forgotten how I got this thing to work 😂
<SbastiendHerbais> Quick question: which one in the IOC is the timer prescaler?
<SbastiendHerbais> I guess it's the /3 before the "To TIPU"?
<dirbaio[m]> > the timer
<dirbaio[m]> there's many many timers
<dirbaio[m]> which one do you want? the one used for embassy-time?
<SbastiendHerbais> I mean it's called Rcc::timer_prescaler :-p
<SbastiendHerbais> yes
<dirbaio[m]> timer_prescaler is the "X2" at the top right, in "to APBx timers"
<SbastiendHerbais> Ok nice, thanks!
<dirbaio[m]> then that clock goes to the actual TIMx
<dirbaio[m]> and the TIMx itself has another divider
<SbastiendHerbais> BTW, this statement is false for this mode:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/KTQkyCENILHknqxTmyZZOlTN>)
<SbastiendHerbais> * BTW, this statement is false for this model:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/cIETAKLXpJhQttHOBEooXlqe>)
<SbastiendHerbais> But it causes a panic :/
<SbastiendHerbais> It blinks at the right speed now
<SbastiendHerbais> Thank you so much for all the help
<SbastiendHerbais> :D
<dirbaio[m]> what's the list of things you changed?
<dirbaio[m]> i'd like to get it working, to add an example for using external flash to the repo
<dirbaio[m]> (well if you want to do that and send a pull request that'd be even more awesome)
<SbastiendHerbais> lots of if !config.assume_init and this condition, I'll push on a fork so that you can take a look, I don't mind opening a PR either if you'd like that, but likely tomorrow/Wednesday
<dirbaio[m]> ah you did the actual assume_init thing
<SbastiendHerbais> yep
<dirbaio[m]> okay
<SbastiendHerbais> Mind you I also have a modified probe-rs *
<SbastiendHerbais> With the memory-range thing
<SbastiendHerbais> External main mem, as initialized by the bootloader also works, so dirbaio my hats off to you, you're amazing :D
<SbastiendHerbais> Do you have a GH sponsor button?
subtlename has joined #rust-embedded
subtlename has quit [Changing host]
subtlename has joined #rust-embedded
subtlename has quit [Ping timeout: 276 seconds]
<SbastiendHerbais> dirbaio: How would I report issues in stm32-data-generated/stm32-metapac? I found that it doesn't implement traits it should (for Ethernet)
<dirbaio[m]> <SbastiendHerbais> "Do you have a GH sponsor button?" <- not currently, no
<dirbaio[m]> <SbastiendHerbais> "dirbaio: How would I report..." <- in the stm32-data repo
<dirbaio[m]> that's the source
<SbastiendHerbais> Yeah that's what I did, basically it's missing all ETH mode pins
<SbastiendHerbais> Don't know why 🤷‍♂️
<SbastiendHerbais> The solution however, is cursed (in embassy-stm32):... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/rvzXwpUEJQQTbgEfLqogRAxB>)
<dirbaio[m]> hm
<dirbaio[m]> well that's annoying. they've just changed the pin naming
<SbastiendHerbais> Huh, that would explain the issue, I am also not sure whether 11 is the right alternate mode
<SbastiendHerbais> Since it's not working...
<SbastiendHerbais> So adding them to the list before would be a more robust way of doing it then
<dirbaio[m]> well, ideally stm32-data would have consistent names
<dirbaio[m]> so
<JamesMunns[m]> so, how do we get dirbaio hired to ST, just to fix their internal data sources and data stability guarantees, just to quit 3 months later?
<dirbaio[m]> (sorry fixed link)
<dirbaio[m]> do some kind of find-and-replace to convert the new names into the old ones
<dirbaio[m]> for example if you get ETH_RMII_TX_EN, return ("ETH", "TX_EN") instead of ("ETH", "RMII_TX_EN")
<SbastiendHerbais> JamesMunns[m]: Please!
<dirbaio[m]> it's a bit annyoing because old had just ETH_TX_EN, and new one has ETH_MII_TX_EN, ETH_RMII_TX_EN, both on the same pin :|
<dirbaio[m]> even though the MII pins are a superset of the RMII pins
pronvis has joined #rust-embedded
<SbastiendHerbais> Maybe just supporting the MII is fine then, but I would expect that they're maybe planning on dropping MII from newer chips?
<SbastiendHerbais> Hence the distinction they now make
pronvis has quit [Ping timeout: 252 seconds]
rom4ik1 has quit [Quit: Ping timeout (120 seconds)]
rom4ik1 has joined #rust-embedded
<SbastiendHerbais> I got networking, RNG, & DHCP working, so getting there :D
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]> A little heads up, I've started pushing the beginnings of support for Rust within Zephyr (in upstream): https://github.com/zephyrproject-rtos/zephyr/pull/75904