<re_irc> <firefrommoonlight> Seconding that cube is great for Stm clocks. The RMs have the info, but cube is interactive and gives you realtime feedback and errors
<re_irc> <adamgreig> the PREDIV register is only available on the connectivity line F1 as well, I don't think f1xx-hal currently knows how to use it when computing clock freqs
<re_irc> <adamgreig> but even with it, it doesn't seem possible to get 72MHz from 25MHz HSE
<re_irc> <adamgreig> I think with F1 it was most common to use 8MHz HSE
<re_irc> <adamgreig> with newer stm32s you can use 25MHz fine, but the clocking was less flexible then
<re_irc> <adamgreig> any particular reason for an f1? i guess you have to take whatever you can get these days :P
<re_irc> <adamgreig> and they're sort of second sourcable from the various clones too...
cr1901_ is now known as cr1901
<cr1901> adamgreig: I'm self-imposing a rust-embedded break for like a week or something, but I wonder if adding try_borrow_mut() to the Mutex<RefCell<T>> inherent impl would be feasible after a trial period
<cr1901> and do something similar for Mutex<OnceCell<>>, which is also common
<cr1901> (in my code*)
<re_irc> <adamgreig> hmm, interesting
<re_irc> <adamgreig> I don't see why we couldn't have try_borrow_mut as well
<cr1901> Tbf, I'm using try_borrow_mut because Rust won't opt away formatting code otherwise
<re_irc> <adamgreig> I worry a tiny bit that we're missing some problem by having these extra impls but I don't see what it would be
<cr1901> B/c that's still a problem (yes I opened an issue/found the actual commit where it was introduced)
<re_irc> <adamgreig> maybe we release a 1.1.0-alpha.1 and give it a try and perhaps then add in try_* and maybe OnceCell before 1.1?
<cr1901> works for me- no rush
<cr1901> >I worry a tiny bit that we're missing some problem
<cr1901> This is of course a deliberately abrasive tweet, but it has been "free real estate" in my head since I read it.
<re_irc> <adamgreig> lol
<re_irc> <adamgreig> no comment on the entire map_or discourse that sprung up
<re_irc> <adamgreig> i feel like the names in the recent bare-metal pr are ok tho
<cr1901> Ehhh, I'm guilty of what Lexi says in her tweet, depending on whether I want to "learn" or want to "do". And "learning" means I'm not (concretely) "doing".
<cr1901> adamgreig: Sure, I agree. I just couldn't resist
<re_irc> <adamgreig> heh
<re_irc> <adamgreig> cr1901: how do you use OnceCell? the std one or the crates.io one? on nightly?
<cr1901> The crates.io one on nightly
<cr1901> I have no idea why two exist
<cr1901> nightly compiler*, I don't think I use nightly features
<re_irc> <adamgreig> I think once_cell (the crate) is moving into std? in std::lazy https://doc.rust-lang.org/core/lazy/struct.OnceCell.html
<re_irc> <adamgreig> ah indeed
<re_irc> <adamgreig> I'm a bit less keen on including a dependency in bare-metal, even optional
<cr1901> B/c peripherals have interior mutability, and the costs (LLVM annotations) that come with it, there is no reason to use a RefCell for bare peripherals.
<re_irc> <adamgreig> yea, makes sense, but can't use Cell because need to move into it?
<cr1901> Hmmmm, I don't know actually
<cr1901> I guess I never tried
<cr1901> adamgreig: Rain check on this one... I'll have to try and see what happens
<re_irc> <adamgreig> yea, no rush :P
<cr1901> adamgreig: Ahh right, Peripherals and members don't impl Copy
<cr1901> so there's no Cell::get()
<cr1901> Although I'm trying to move to stable, msp430 already requires nightly. So I'm willing to try the core::oncecell. But would rather stay w/ the crate b/c I'm trying to _remove_ unstableness (slowly!)
<re_irc> <adamgreig> makes sense, I don't know what the timeline is for stabilising it
fabic has joined #rust-embedded
tokomak has joined #rust-embedded
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 245 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
fabic has joined #rust-embedded
sknebel has quit [Ping timeout: 256 seconds]
sknebel has joined #rust-embedded
Guest261 has joined #rust-embedded
<re_irc> <Robert Gałat> I have a simple question, I need to pass an mut array of u8 to a function, and it has to have `static lifetime. (link to function from github https://github.com/nrf-rs/nrf-hal/blob/577a9f387c1a034c428aa858bed709b9a71e0aff/nrf-hal-common/src/uarte.rs#L318), How to create such array? In C I would just create global static, but I just can not figure out how to create such object in rust :(
<re_irc> <K900> You can use a static
<re_irc> <K900> But it will be unsafe to access because Rust doesn't know you're in an environment with no threads
<re_irc> <Robert Gałat> exactly, this was my last error :(
<re_irc> <Robert Gałat> I try to creatre simple embedded app, and I will not use threads, How can I do this the right way ?
<re_irc> <K900> You can wrap it in a mutex, or just use unsafe here
<re_irc> <adamgreig> K900: Even interrupts count as threads here so it's fair of the compiler to not know, but if you only access the static from one place it's sound (so you still have to write unsafe because the compiler can't prove it's ok, but it won't cause problems)
<re_irc> <adamgreig> In C every time you access a static you have to ensure the same thing to prevent problems, just you don't have to write anything special
<re_irc> <adamgreig> But the rules for when it's ok are (essentially) the same as C: it's only ok if no one else could be accessing it at the same time, either because you use some kind of lock (like a critical section or disabling interrupts) or because you can be sure due to the nature of your program (no other reference to it, or only from code that can't be running at the same time, maybe because it's at the same interrupt priority...
<re_irc> ... level)
<re_irc> <adamgreig> (if you're using this static for DMA as in that function you linked Robert Gałat it's a bit more fiddly because you need to be sure you don't access it at the same time as the DMA, but the HAL should hopefully be taking care of that for you)
<re_irc> <Robert Gałat> OK, so it would be better to wrap it in mutex ? Now I wonder If I ever should use unsafe in similar cases, If logic of my application ensure only one access to the buffer, then I will never have to wait for a mutex, so it is zero cost abstraction, that will ensure correct memory access in the future. Now I think that mutex should be only option. Am I right ?
slugbyte has quit [Quit: WeeChat 3.4]
<re_irc> <Robert Gałat> adamgreig: I tried to wrap this array in mutex, and now I struggle with passing it to the function that I need, This is what I have done :
<re_irc> use cortex_m::interrupt::Mutex;
<re_irc> static mut tx_buf: Mutex<[u8;256]> = Mutex::new([0; 256]);
<re_irc> static mut rx_buf: Mutex<[u8;1]> = Mutex::new([0; 1]);
<re_irc> How to convert this to tx_buf: &'static mut [u8]?
<re_irc> <Robert Gałat> I do not get it, in this mutex, there is only borrow function, but it requires Critical section. I can not force this mutex to live for 'static lifetime :( so does it mean I need to use unsafe ? but, adamgreig said, that the interrupts are treated like threads, so there is a risk of multiple access to this buffer. I feel like I'm too stupid for this :(
<re_irc> <adamgreig> It's hard in this case because the HAL function holds on to the static and you can't tell when it will be used, so you can't just use an occasional critical section indeed
<re_irc> <adamgreig> I would really suggest just using an unsafe block to give the HAL a &'static mut reference like it wants
<re_irc> <adamgreig> You can declare the static inside a function which restricts its scope to just that function, so now it's safe so long as you only call this function once ever
<re_irc> <adamgreig> For example, because it's the entry function (which can't be called besides once at startup)
<re_irc> <adamgreig> I can't find a uarte example in that repo but if you can find one maybe an example would make it clearer, maybe you could ask in #nrf-rs:matrix.org (https://matrix.to/#/#nrf-rs:matrix.org) how it should be used?
<re_irc> <adamgreig> Robert Gałat: The Mutex won't be zero cost in this case: every time you use a critical section to enter it, it disables all other interrupts for the duration of the critical section
<re_irc> <Robert Gałat> Oh thanks for the help, I will try to use unsafe, but from a noob perspective it feels like a bad design of the HAL (or at lest very hard to understand) :(
<re_irc> <danielzfranklin> Is there a natural type for a UTC timestamp? "embedded-time"'s "Instant" is in relation to a specific hardware clone. For context, I'm writing a driver for a gps and want a suitably interoperable type to return.
<re_irc> <danielzfranklin> * clock.
<re_irc> <adamgreig> Robert Gałat: I think the requirement is driven by the nrf using DMA for all its peripherals and DMA requires a stable memory address for the buffer, so there may be technical reasons for it
<re_irc> <adamgreig> But maybe it could be made simpler somehow? I don't know much about nrf really
<re_irc> <adamgreig> danielzfranklin: There's Rtcc but it's not really a perfect fit, otherwise perhaps the time crate? https://docs.rs/time/latest/time/
<re_irc> <danielzfranklin> Thanks, I didn't realize "time" was no-std
<re_irc> <adamgreig> I'd be tempted to do your own simple type that fits your data (like maybe you want separate year month day hour min second fields to map to what you parse from the gps, and not something that requires a bunch of maths to work out the number of seconds since 1970), and then you could support converting to a type from time as an optional dependency that's only brought in when wanted
<re_irc> <adamgreig> (the time crate can convert from yymmddhhmmss to its time format for you, but it's still more code if the end user just wants to get back the hhmmss or whatever)
<re_irc> <adamgreig> But if you want to keep it simple I think the types from time would be a good fit
<re_irc> <danielzfranklin> My gps gives my a u32 unix timestamp, which I'm guessing time's type is just a wrapper around. So no parsing would be necessary, but it'd add a required dependency. Does that change your opinion adamgreig ?
<re_irc> <adamgreig> Cool, what gps is it? What does it do for leap seconds lol
<re_irc> <adamgreig> That certainly reduces the cost of using time and probably is more convenient for your users if they want to do anything with the timestamp except look at it and diff two of them
<re_irc> <danielzfranklin> It's from adafruit, I think it's a GTOP A11
<re_irc> <danielzfranklin> It's got a mode where it logs to it's own memory and then you can periodically ask it for a core dump. Right now I'm writing a parser for that core dump
<re_irc> <danielzfranklin> I'd guess it's gps time (the docs are mostly "contact us if you have questions"), which wikipedia says doesn't have leap seconds. Not sure how to handle that
<re_irc> <danielzfranklin> It's from adafruit, I think they're reselling a GTOP A11
<re_irc> <adamgreig> gps time is traditionally a week number and a number of seconds/milliseconds into the week, rather than seconds since 1970 ("unix time")
<re_irc> <adamgreig> so if it is giving you "UTC" or "unix time" it's hopefully already accounting for leap seconds
<re_irc> <danielzfranklin> The entirety of the docs is a cpp sample that uses "gmtime" to parse it
<re_irc> <adamgreig> :D
<re_irc> <danielzfranklin> And that the variable is called UTC
<re_irc> <adamgreig> probably it is "unix time" and I guess it just means you'll get the same timestamp twice during a leap second
<re_irc> <danielzfranklin> Thanks!
<re_irc> <adamgreig> on the bright side, probably won't be another leap second for ages anyway
<re_irc> <danielzfranklin> Some unspecified part/all breaks on the 2038 week rollover anyway
<re_irc> <adamgreig> that will be fun for everyone
<re_irc> <adamgreig> by the way, "time" uses julian day, hours, minutes, seconds internally, so the conversion does require a couple of divisions but nothing more than that: https://docs.rs/time/latest/src/time/offset_date_time.rs.html#136-161
<re_irc> <danielzfranklin> I'm reading the hexdump as comma-separated ascii hex over uart, so that won't be noticable :)
<re_irc> <adamgreig> 👍️
Guest261 has quit [Ping timeout: 256 seconds]
fabic has quit [Ping timeout: 256 seconds]
fabic has joined #rust-embedded
Guest212 has joined #rust-embedded
tokomak has quit [Ping timeout: 240 seconds]
fabic has quit [Ping timeout: 250 seconds]
fabic has joined #rust-embedded
<re_irc> <thejpster> Anyone having docs.rs issues with latest svd2rust output?
<re_irc> <thejpster> rp2040-pac git:(main) cargo +nightly doc
<re_irc> Documenting rp2040-pac v0.3.0 (/home/jonathan/Documents/github/rp-rs/rp2040-pac)
<re_irc> thread 'rustc' panicked at 'no entry found for key', src/librustdoc/passes/collect_intra_doc_links.rs:929:16
<re_irc> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
<re_irc> <thejpster> $ rp2040-pac git:(main) cargo +nightly doc
<re_irc> Documenting rp2040-pac v0.3.0 (/home/jonathan/Documents/github/rp-rs/rp2040-pac)
<re_irc> thread 'rustc' panicked at 'no entry found for key', src/librustdoc/passes/collect_intra_doc_links.rs:929:16
<re_irc> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
<re_irc> <xiretza> which is probably a dupe of https://github.com/rust-lang/docs.rs/issues/1630
Lumpio- has joined #rust-embedded
<re_irc> <Benjamin Wilhelm> Hey guys, currently i am writing a small rtos (yet another rtos.. :p) for an stm32f407vet6 board, if you might be interested take a look at :
<re_irc> the project is in a really early stage, but it will grow! :) i know there are much better and highly optimizied crates for that already, but I guess it might be good if the embedded community
<re_irc> shares it's stuff... :)
Guest212 has quit [Ping timeout: 256 seconds]
<re_irc> <adamgreig> cool!
fabic has quit [Ping timeout: 256 seconds]
<re_irc> <Lachlan Sneff> James Munns: Is there any way I can enforce at compile time that postcard must be able to _always_ serialize a struct to some number of bytes or less?
<re_irc> <Lachlan Sneff> The "to_vec" method takes a const parameter, but can fail to stuff things down into the buffer at runtime.
<re_irc> <Lachlan Sneff> James Munns: Is there any way I can enforce at compile time that postcard must be able to _always_ serialize a struct to some number of bytes or fewer?
<re_irc> <James Munns> Lachlan Sneff not currently, but korken89 and I have some ideas on how to calculate this, but it would be some work.
<re_irc> <James Munns> tl;dr: a trait that calculates "max serialized size", impl it for most primitives in postcard itself, provide a derive macro that calculates it for aggregate types
<re_irc> <Lachlan Sneff> That would be sweet.
<re_irc> <James Munns> I don't have time planned to do it, but would be very open to a PR, and willing to mentor!
<re_irc> <Lachlan Sneff> I'll take a look
<re_irc> <James Munns> Feel free to ping me anywhere on matrix if you wanna chat about it (DMs, here, anachro, ovar, etc.)
<re_irc> <Lachlan Sneff> Will do!
<re_irc> <James Munns> Oh, and impl it for things like "heapless::Vec" and "heapless::String". It wont work for types that contain "&'a [u8]" for example, though you could maybe add a "#[max_len(32)]" inner attribute or something that causes this to fail at ser/deser if it's violated, but even without that it would be useful (and could be added later)
<re_irc> <James Munns> Could always be done downstream with a wrapper type and a custom ser/de impl if really necessary
<re_irc> <James Munns> also, since I'm brain dumping, the only "weird"/"hard to calculate" part would be the use of varints for enums and array lengths, BUT you could either do fancy macro things to calculate that, or take the worst case scenario
<re_irc> <ryan-summers> James Munns: check out the "Miniconf::get_metadata()" - this does that calculation of serialization size recursively on structs: https://github.com/quartiq/miniconf/blob/develop/src/lib.rs#L290
<re_irc> <James Munns> CC Lachlan Sneff, who I think is working on this right now :D
<re_irc> <ryan-summers> Although it's serialization of a deterministic path string and not necessarily the data container now that I'm thinking about it more
<re_irc> <ryan-summers> But the main structure should be there
<cr1901> Is yanking to prevent a soundness bug and then making a breaking API change considered a major semver bump?
<re_irc> <Lachlan Sneff> James Munns: Submitted the PR!
<re_irc> <James Munns> Lachlan Sneff: Nice! I'll try to take a look this week!
<re_irc> <James Munns> Took a quick looks, overall LGTM, it might be good to have some more max size tests, especially for vecs/strings of size 127, 128, 16383, 16384, etc., and I want to see how bad the proc macro errors are with things like borrowed data, but I'll probably merge it and iterate on docs/tests in the main branch
<re_irc> <Lachlan Sneff> I'm happy to fix those things before merging!