fabic has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
fabic has quit [Quit: Leaving]
fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
<re_irc> <@luojia65:matrix.org> I uploaded all public slides and articles of my recent speeches related to RustSBI, embedded Rust and bare metal RISC-V into this repository: https://github.com/rustsbi/slides
<re_irc> <@luojia65:matrix.org> The missing 'RustSBI Implementation Under Asymmetric Multiprocessors, Jan 2022' pdf file
<re_irc> <@oddstr13:matrix.org> dirbaio:matrix.org: Looks like I never put a license on that repo, but I did use the knurling-rs stuff as a starting point, which looks to be dual licensed with a choice between Apache 2 & MIT.
<re_irc> <@oddstr13:matrix.org> Of those two, I'm inclined to pick MIT just for it's simplicity, personally. Looks like Apache is better suited for commercial use tho, due to the explicit patent grant.
<re_irc> <@oddstr13:matrix.org> Any opinions there, dirbaio henrikssn ? Could just copy over the dual license if that's preferred.
<re_irc> <@dirbaio:matrix.org> lots of rust code is dual licensed so that'd be the most "compatible". Apache and MIT are almost the same anyway, so I don't think it makes much of a difference in practice though
<re_irc> <@oddstr13:matrix.org> Apache has the additional permission of patent use, requirement of stating changes, and limitation on trademark use, but otherwise they look to be equivalent
<re_irc> <@oddstr13:matrix.org> but, if the rust norm is Apache + MIT, I'll just do that
<re_irc> <@dirbaio:matrix.org> not sure how "norm" is, just MIT is fine too
<re_irc> <@dirbaio:matrix.org> but it's your code after all, so choose the license you prefer! :D
<re_irc> <@oddstr13:matrix.org> I honestly don't care that much for this particular repo, if I cared more I'd likely lean in to the more strongly copyleft licenses requiring disclosure of source – it's more of a template / tutorial / example style repo, which I tend to consider to be more appropriate for the unlicense or similar public domain, but seeing as I started out with code from ferrous systems, I'd need their permission to remove..
<re_irc> ... the MIT/Apache files (whoops…)
<re_irc> <@oddstr13:matrix.org> I see that nrf-hal is also dual MIT & Apache, so I'll just apply that
<re_irc> <@oddstr13:matrix.org> it's pretty tightly integrated with that repo after all :P
<re_irc> <@henrikssn:matrix.org> Oddstr13: Apache is better for commercial use, due to the explicit patent grant, so I'd either go with that or dual license. Thanks!
<re_irc> <@oddstr13:matrix.org> henrikssn:matrix.org: Yep, I just copied the dual license from the ferrous template repo
<re_irc> <@oddstr13:matrix.org> should be all good now :)
<re_irc> <@luojia65:matrix.org> Hello! I published crate `xuantie` version 0.0.2. This crate is a low level access to T-Head Xuantie processors, including xuantie extended instructions (cache refresh & invalid, NMI interrupt), CSR registers (cache control, TLB error handling, cpuid), page table entry and debug modules. This crate is used in Rust powered bootloader of Allwinner D1/D1s chip (with Xuantie C906 RISC-V core inside) as...
<re_irc> ... production use. Please star the repository: https://github.com/luojia65/xuantie
<re_irc> <@luojia65:matrix.org> It uses latest core::arch::asm! macro, and would be built under stable Rust (future 1.59.0)
<re_irc> <@9names:matrix.org> my lychee RV turned up today so that's great timing :D
<re_irc> <@luojia65:matrix.org> :D
<re_irc> <@dirbaio:matrix.org> why do these impls conflict?
<re_irc> <@dirbaio:matrix.org> ```rust
<re_irc> <@dirbaio:matrix.org> trait Foo { type Output; }
<re_irc> <@dirbaio:matrix.org> trait Bar {}
<re_irc> <@dirbaio:matrix.org> no type can impl both `Foo<Output=u32>` and `Foo<Output=u64>` :(
<re_irc> <@dirbaio:matrix.org> is it one of those cases of "it's correct but rust isn't smart enough to see that"? :(
<re_irc> <@k900:0upti.me> You can implement Foo twice for the same T
<re_irc> <@dirbaio:matrix.org> how?
<re_irc> <@dirbaio:matrix.org> You'd have to do this, which is definitely not allowed
<re_irc> <@dirbaio:matrix.org> impl Foo for Wtf { type Output = u32; }
<re_irc> <@dirbaio:matrix.org> struct Wtf;
<re_irc> <@dirbaio:matrix.org> ```rust
<re_irc> <@dirbaio:matrix.org> impl Foo for Wtf { type Output = u64; }
<re_irc> <@k900:0upti.me> Oh wait, `Output` is an associated type, not a generic parameter
<re_irc> <@burrbull:matrix.org> dirbaio:matrix.org: https://github.com/rust-lang/rust/issues/20400
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@bradleyharden:matrix.org> Could `bare_metal::Mutex::borrow` return `&'cs mut T` instead of `&'cs T`? If you successfully entered the critical section, doesn't that imply you have exclusive control over the resource? With `&'cs T`, you have to introduce interior mutability, so you end up with nested instances of `UnsafeCell`. Am I misunderstanding something?
<re_irc> <@xiretza:xiretza.xyz> bradleyharden:matrix.org: you can nest multiple critical sections: https://github.com/rust-embedded/cortex-m/issues/224
<re_irc> <@dirbaio:matrix.org> bradleyharden:matrix.org: std mutex does 2 things: "interior mutability" + "convert Send into Sync"
<re_irc> <@dirbaio:matrix.org> cortex-m mutex just does "convert Send into Sync", it's up to you to do the interior mutability
<re_irc> <@dirbaio:matrix.org> with Cell/RefCell
<re_irc> <@dirbaio:matrix.org> one cool consequence is `Mutex<Cell<u32>>` is the same size as u32, while std `Mutex<u32>` is bigger
<re_irc> <@dirbaio:matrix.org> while std `Mutex<u32>` is bigger
<re_irc> <@dirbaio:matrix.org> if you want `&mut` to the contents then use RefCell which does have 1 byte of overhead, but the cool thing is you don't *have* to
<re_irc> <@bradleyharden:matrix.org> I wasn't concerned about the overhead. It just didn't make sense to me that you would need ref counting here. I hadn't considered nested critical sections though
<re_irc> <@bradleyharden:matrix.org> Isn't `Mutex` a misnomer then? Borrowing it doesn't actually give you exclusive access
<re_irc> <@bradleyharden:matrix.org> Couldn't you add some sort of global `AtomicBool` to guarantee only one critical section at a time? I guess that wouldn't work for `thumbv6`, but wouldn't it work for `thumbv7`?
<re_irc> <@dirbaio:matrix.org> it gives the current "thread" exclusive access vs other threads
<re_irc> <@dirbaio:matrix.org> it's just that you can get two `&` within the current thread, so it can't be `&mut`
<re_irc> <@dirbaio:matrix.org> disallowing nested critical sections would be annoying, if within a CS you call some library function that also takes a CS, it'll explode
<re_irc> <@bradleyharden:matrix.org> Hmm, this seems like a good use case for that new `context` or `capability` feature I saw recently
<re_irc> <@bradleyharden:matrix.org> Where the critical section token would be an implicit argument, so you don't have to pass it down through all libraries
<re_irc> <@dirbaio:matrix.org> and disallowing nested critical sections still doesn't allow `&mut` in Mutex: you can take ONE cs then use its token to borrow the same mutex twice
<re_irc> <@dirbaio:matrix.org> and making the token non-Copy is not a solution, as it'd disallow borrowing multiple mutexes inside the same CS
<re_irc> <@bradleyharden:matrix.org> Instead of returning `&mut T`, couldn't you return a `MutexGuard`, like `std`?
<re_irc> <@bradleyharden:matrix.org> Wait no, that doesn't help I think
<re_irc> <@dirbaio:matrix.org> MutexGuard derefs to &mut
<re_irc> <@dirbaio:matrix.org> same issue, you can borrow the mutex twice to get two MutexGuards then deref them to two &muts
<re_irc> <@bradleyharden:matrix.org> Ok, I think I see. To get it to work, you would need a per-`Mutex` lock
<re_irc> <@bradleyharden:matrix.org> Same as `std`
<re_irc> <@bradleyharden:matrix.org> Which increases size, as you said above
<re_irc> <@dirbaio:matrix.org> yup, in the end it'd be like making `Mutex<T>` be the current `Mutex<RefCell<T>>`
tafa has quit [Quit: ZNC - https://znc.in]
<re_irc> <@dirbaio:matrix.org> RefCell has the "locked flag"
<re_irc> <@bradleyharden:matrix.org> Are there many use cases for `Mutex` without interior mutability though?
<re_irc> <@dirbaio:matrix.org> vs with the current design you can opt out of it, using `Mutex<Cell<T>>`
<re_irc> <@dirbaio:matrix.org> that's still interior mutability
<re_irc> <@bradleyharden:matrix.org> Oh you meant the space savings
<re_irc> <@dirbaio:matrix.org> yeah
<re_irc> <@bradleyharden:matrix.org> I guess. A byte doesn't seem like a lot to me though :p
<re_irc> <@dirbaio:matrix.org> or also `Mutex<MyStruct>` and MyStruct contains Cells/RefCells
<re_irc> <@bradleyharden:matrix.org> Yeah, I guess it's more flexible at the cost of more verbose code
tafa has joined #rust-embedded
<re_irc> <@dirbaio:matrix.org> forcing refcell with the wasted byte on everyone would certainly be unpopular
<re_irc> <@dirbaio:matrix.org> but it's not just the wasted byte, it's the possibility of failing runtime
<re_irc> <@dirbaio:matrix.org> Cell get/set can't fail
<re_irc> <@bradleyharden:matrix.org> I wonder if it would be worth adding some inherent `impl` blocks to `bare_metal` for `Mutex<RefCell<T>>`, to cut down on some of the verbosity. Basically make it act like `std::Mutex`
<re_irc> <@dirbaio:matrix.org> ooh that's an interesting idea
<re_irc> <@bradleyharden:matrix.org> `.borrow(cs).borrow_mut()` is a bit obnoxious
<re_irc> <@bradleyharden:matrix.org> Who maintains `bare_metal`?
<re_irc> <@bradleyharden:matrix.org> Maybe I could make a PR
<re_irc> <@bradleyharden:matrix.org> Looks like korken89 is on the list
<re_irc> <@dirbaio:matrix.org> have fun, bare-metal is at 1.0 but the whole ecosystem is still at 0.2
<re_irc> <@bradleyharden:matrix.org> That wouldn't be breaking though, would it?
<re_irc> <@bradleyharden:matrix.org> I see several issues discussing the `Mutex` API, haha. I'm not the only one confused. We (and by we I mean someone else 😛) should probably document all these counter arguments somewhere
<re_irc> <@adamgreig:matrix.org> Writing it up in the embedded book would be neat
<re_irc> <@adamgreig:matrix.org> The answer might be to delete Mutex though idk
<re_irc> <@adamgreig:matrix.org> It's kind of troublesome
<re_irc> <@dirbaio:matrix.org> there's the "it's unsound" too
<re_irc> <@adamgreig:matrix.org> Doesn't work for multi core or unprivileged mode cortex-m
<re_irc> <@bradleyharden:matrix.org> It is?
<re_irc> <@dirbaio:matrix.org> cortex_m::interrupt::free I mean, sorry
<re_irc> <@adamgreig:matrix.org> The whole collection of safety invariants around interrupts on cortex-m is a bit rickety maybe
<re_irc> <@adamgreig:matrix.org> We make it unsafe to enable an interrupt in cortex-m because various other crates need that to maintain their own safety invariants but it turns out that's not enough in the face of multiple cores or unprivileged mode, and also breaks things like nrf softdevice that require some interrupts stay enabled
<re_irc> <@adamgreig:matrix.org> The single core privileged mode use case is overwhelmingly common among at least hobbyist developers though, who are people that need a simple and safe abstraction for sharing things between interrupts...
<re_irc> <@dirbaio:matrix.org> adopt critical-section, make cortex-m-rt supply the impl?
<re_irc> <@dirbaio:matrix.org> presumably unprivileged binaries will use something custom instead of cortex-mr-t
<re_irc> <@adamgreig:matrix.org> At least it gives them an option to do something yea
<re_irc> <@adamgreig:matrix.org> Or fails to build if nothing done, instead of thinking it worked and just being crazy ub instead
<re_irc> <@dirbaio:matrix.org> the status quo is everyone uses `cortex_m::interrupt::free`, then you have to fork every lib that does if it doesn't work for you lol
<re_irc> <@dirbaio:matrix.org> like when using softdevice, multicore, or unprivileged
<re_irc> <@dirbaio:matrix.org> or if you want to use riscv heh
<re_irc> <@dirbaio:matrix.org> everything assumes cortex_m
<re_irc> <@dirbaio:matrix.org> defmt for example
<re_irc> <@dirbaio:matrix.org> https://github.com/knurling-rs/defmt/pull/640
<re_irc> <@bradleyharden:matrix.org> dirbaio, I'm looking at `critical-section` now. Wouldn't it make sense for `with` to be defined as
<re_irc> <@bradleyharden:matrix.org> ```rust
<re_irc> <@bradleyharden:matrix.org> pub fn with<F, R>(f: F) -> R) -> R
<re_irc> <@bradleyharden:matrix.org> where
<re_irc> <@dirbaio:matrix.org> > you wouldn't be able to manually specify R.
<re_irc> <@dirbaio:matrix.org> what do you mean?
<re_irc> <@bradleyharden:matrix.org> If you use `impl Trait` anywhere in the arguments list, you can't use the turbofish to specify the type parameters
<re_irc> <@bradleyharden:matrix.org> It's a weird limitation right now
<re_irc> <@bradleyharden:matrix.org> I'm trying to find the issue now
<re_irc> <@dirbaio:matrix.org> TIL that's a limitation
<re_irc> <@dirbaio:matrix.org> I've never had to specify R there thoguh
<re_irc> <@bradleyharden:matrix.org> Yeah, it's a real pain and very unintuitive
<re_irc> <@bradleyharden:matrix.org> Well, you rarely have to specify types in general
<re_irc> <@dirbaio:matrix.org> you can change that code into `let x: u32 = with(|| 0);`
<re_irc> <@bradleyharden:matrix.org> True
<re_irc> <@dirbaio:matrix.org> but yeah I guess there's no downside in changing it to remove the `impl`
<re_irc> <@bradleyharden:matrix.org> I guess since it's the return position, that would always work
<re_irc> <@dirbaio:matrix.org> it'd technically be a breaking change though
<re_irc> <@bradleyharden:matrix.org> Would it?
<re_irc> <@bradleyharden:matrix.org> You couldn't have specified `R` manually right now
<re_irc> <@dirbaio:matrix.org> aah, true 🤣
<re_irc> <@dirbaio:matrix.org> hahaha
fabic has joined #rust-embedded
<re_irc> <@bradleyharden:matrix.org> https://github.com/rust-lang/rust/issues/83701
<re_irc> <@bradleyharden:matrix.org> Tracking issue
<re_irc> <@bugadani:matrix.org> sometimes I feel like every time a question pops up, there's a tracking issue about a relevant feature
<re_irc> <@bgamari:matrix.org> dirbaio do you need anything from me on https://github.com/embassy-rs/embassy/pull/561?
<re_irc> <@dirbaio:matrix.org> haven't had time to look yet
<re_irc> <@bgamari:matrix.org> no worries (I also just noticed that I'm not in #embassy; apologies)
<re_irc> <@adamgreig:matrix.org> dirbaio: do you think it could make sense for bare-metal to gain the methods from critical-section?
<re_irc> <@dirbaio:matrix.org> I guess, why not
<re_irc> <@dirbaio:matrix.org> I've always found the `bare_metal` crate name very "non-descriptive" thoguh
<re_irc> <@dirbaio:matrix.org> and critical-section works on std, wasm too
<re_irc> <@dirbaio:matrix.org> which is quite handy, it allows lazy porting of code (if you don't care about multithreading performance)
<re_irc> <@adamgreig:matrix.org> in which case would it make sense for bare-metal to lose CriticalSection and just define it inside critical-section?
<re_irc> <@adamgreig:matrix.org> not like it's a huge problem to have both but it feels like one thing split in two atm
<re_irc> <@dirbaio:matrix.org> yeah that'd make more sense I guess
<re_irc> <@dirbaio:matrix.org> I'm not sure what bare_metal is supposed to be
<re_irc> <@adamgreig:matrix.org> and.... Mutex?
<re_irc> <@dirbaio:matrix.org> 0.2 -> 1.0 removed `Nr` and `Peripheral`
<re_irc> <@adamgreig:matrix.org> it turned out Nr wasn't sufficiently common as a u8
<re_irc> <@adamgreig:matrix.org> and Peripheral never became used
<re_irc> <@dirbaio:matrix.org> so now it's just Mutex and the CS token :D
<re_irc> <@dirbaio:matrix.org> and no one is using 1.0 anyway
<re_irc> <@adamgreig:matrix.org> it's "Abstractions common to bare metal systems" but perhaps an argument could be made they should each get their own crate
<re_irc> <@adamgreig:matrix.org> or in the case of Nr it became clear it was actually arch-dependent
<re_irc> <@dirbaio:matrix.org> +1 to each their own crate
<re_irc> <@dirbaio:matrix.org> so you can break one without having to major-bump the otehrs
<re_irc> <@adamgreig:matrix.org> but perhaps Mutex would live with critical-section in that case
<re_irc> <@adamgreig:matrix.org> there's also the somewhat unloved mutex-trait
<re_irc> <@josfemova:matrix.org> Having those abstractions in a single crate sounds good imho. On their own they can be left unloved, like the mutex trait
<re_irc> <@dirbaio:matrix.org> if they don't see love it's because people don't use them because they're not useful, putting them in a single crate doesn't fix that
<re_irc> <@josfemova:matrix.org> And a hal implementation can provide a list of the common abstractions that they implement
<re_irc> <@josfemova:matrix.org> And iirc, the mutex trait started as _something_ because of shared-bus, which is kind of popular
<re_irc> <@josfemova:matrix.org> Nah it does sounds better like different crates, but I still think some sort of list should be provided so a hal can provide information on that
fabic has quit [Quit: Leaving]
<re_irc> <@dirbaio:matrix.org> suggestions on binary serialization formats that
<re_irc> <@dirbaio:matrix.org> - extensible (can add fields, still deserialize old data)
<re_irc> <@dirbaio:matrix.org> - can serialize/deserialize from both Go and Rust
<re_irc> <@dirbaio:matrix.org> - no string field names
<re_irc> <@dirbaio:matrix.org> ?
<re_irc> <@dirbaio:matrix.org> all I can think of is protobuf, capnproto
<re_irc> <@dirbaio:matrix.org> they're both a bit meh, requiring external tool and custom language
<re_irc> <@adamgreig:matrix.org> msgpack or cbor with enum/integer keys in a mapping?
<re_irc> <@dirbaio:matrix.org> hehe
<re_irc> <@dirbaio:matrix.org> how do you deserialize these without alloc?
<re_irc> <@adamgreig:matrix.org> You didn't say anything about that :p but perhaps you could stream the key/value pairs? Less convenient for going directly to a struct for sure..
<re_irc> <@dirbaio:matrix.org> yeah... I have the feeling "deserialize to struct then use struct in business logic" will lead to code bloat
<re_irc> <@dirbaio:matrix.org> protobuf does that, and the generated code is mega bloated
<re_irc> <@dirbaio:matrix.org> the idea of capnproto/flatbuffers sounds nice
<re_irc> <@dirbaio:matrix.org> flatbuffers-rust has this scary warning telling you not to use it to deserialize untrusted data... yikes
<re_irc> <@dirbaio:matrix.org> maybe capnproto.. but ugh
<re_irc> <@dirbaio:matrix.org> or continue hand-rolling it 🤣
<re_irc> <@dirbaio:matrix.org> I'm just tired of hand-rolling it >_<
<re_irc> <@ruabmbua:matrix.org> Had to evaluate different frameworks for a embedded project with very constrained hw, and the standard flatbuffers implementation was the most flexible one.
<re_irc> <@ruabmbua:matrix.org> I can really recommend flatbuffers (from C / C++ side)
<re_irc> <@ruabmbua:matrix.org> Could use it more / less comfortable on linux, and the C library was very adaptable for the small embedded device.
bpye has quit [Quit: The Lounge - https://thelounge.chat]
bpye has joined #rust-embedded
<re_irc> <@mathias_koch:matrix.org> serde-cbor is no_std & no_alloc, perhaps that could be an option?
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc> <@josfemova:matrix.org> I'm playing around with the svd tools. but I'm having problems parsing bitRange
<re_irc> <@josfemova:matrix.org> SEL:
<re_irc> <@josfemova:matrix.org> description: Channel Selection. 0=CH0, 1=CH1
<re_irc> <@josfemova:matrix.org> bitWidth: 1
<re_irc> <@josfemova:matrix.org> bitOffset: 1
<re_irc> <@josfemova:matrix.org> how am I supposed to specify that value?
<re_irc> <@josfemova:matrix.org> Caused by:
<re_irc> <@josfemova:matrix.org> 0: Adding peripheral `ADC`
<re_irc> <@josfemova:matrix.org> 2: `bit_range` must be initialized
<re_irc> <@josfemova:matrix.org> 1: `Build error: `bit_range` must be initialized
<re_irc> <@josfemova:matrix.org> bitOffset and bitWidth work ok, but feels more comfy to work directly in ranges
<re_irc> <@adamgreig:matrix.org> Hmm, I'd expect that to work when quoted but for whatever reason offset and width are the usually used versions