<cr1901> dirbaio: Could you point me to an example of the HAL singleton approach you're using for metapac?
<cr1901> I could use some inspiration
<re_irc_> <@d​irbaio:m​atrix.org> (embassy-nrf doesn't really use stm32-metapac, it uses the normal nrf pacs, but it ignores the pac singletons. it's a better example because all the stm32 stuff is autogenerated so I can't link to any code, but it works the same way as nrf)
<re_irc_> <@d​irbaio:m​atrix.org> `peripherals!` defines the singletons and a Peripherals struct containing them all
<cr1901> yea I'm looking for the macro impl now
<re_irc_> <@d​irbaio:m​atrix.org> `embassy_nrf::init()` returns the `Peripherals`, it's the equivalent of `pac::Peripherals::take()`
<re_irc_> <@d​irbaio:m​atrix.org> the singletons are similar to what the PAC would have, with a few differences:
<re_irc_> <@d​irbaio:m​atrix.org> - GPIO pins already come split
<re_irc_> <@d​irbaio:m​atrix.org> - SPI0, SPIM0, SPIS0, TWI0, TWIM0, TWIS0 becomes just TWISPI0 so you can only use one at a time
<re_irc_> <@d​irbaio:m​atrix.org> - GPIOTE channels already come split
<re_irc_> <@d​irbaio:m​atrix.org> - PPI channels and groups already come split
<cr1901> Okay, so each peripheral has a steal() method
<cr1901> (and an unborrow() method, however that works)
<re_irc_> <@d​irbaio:m​atrix.org> normal usage is to get the peripherals from `embassy_nrf::init()`, you can optionally unsafely steal them
<cr1901> (Well take is implemented in terms of steal, so I was thinking of that)
<re_irc_> <@d​irbaio:m​atrix.org> `Unborrow` is used to allow creating drivers with owned or borrowed singletons, like in here https://github.com/embassy-rs/embassy/blob/master/examples/nrf/src/bin/twim_lowpower.rs#L37
<cr1901> Since PACs write everything in terms of the peripherals struct, not sure it's possible for me to extract singletons out of it per pin. Mulling over how to do my code golf without rewriting swaths of register blocks
hifi has quit [Remote host closed the connection]
hifi_ has joined #rust-embedded
<re_irc_> <@d​irbaio:m​atrix.org> yeah.. embassy-nrf does it by unsafely stealing the pac singletons
<re_irc_> <@d​irbaio:m​atrix.org> since it has the hal singletons to enforce ownership of stuff, it's fine
<re_irc_> <@d​irbaio:m​atrix.org> and embassy-stm32 uses stm32-metapac which simply doesn't have pac singletons :P
<cr1901> >since it has the hal singletons to enforce ownership of stuff, it's fine
<cr1901> So, AFAIU right now, this only works (safely) because you return all the hal singletons at once, in a single function (in other words, thread)
<re_irc_> <@d​irbaio:m​atrix.org> yep
<re_irc_> <@d​irbaio:m​atrix.org> the idea of the singletons is exactly the same, except they're defined in the HAL instead of the PAC
<cr1901> Well, you might get away with a bit more granularity, but the idea is if you could safely get one singleton in one thread, another singleton in another, and they share registers
<cr1901> congrats, you got a data race
<re_irc_> <@d​irbaio:m​atrix.org> yeah
<re_irc_> <@d​irbaio:m​atrix.org> nrf's gpio is very well designed, pins never "share" registers
<cr1901> I don't get that luxury
<re_irc_> <@d​irbaio:m​atrix.org> you can use P0_01 from thread A and P0_02 from thread B without races
<re_irc_> <@d​irbaio:m​atrix.org> stm32's gpio is not that well designed, and there's similar issues with RCC
<cr1901> Single thread data race is possible (iterator invalidation), but does that apply to a singleton data structure?
<cr1901> I can't visualize it if yes
<re_irc_> <@d​irbaio:m​atrix.org> currently embassy-stm32 ensures atomicity with critical sections, there's plans to move to bitbanding or atomics wherever possible
<re_irc_> <@d​irbaio:m​atrix.org> hm not sure what you mean, the singletons are zero-sized, they don't contain actual data
<cr1901> I... don't really understand how it works. I was told "single thread data races in Rust are possible"
<cr1901> i.e. "the same memory location can be used mutably by two different locations in your code in a single thread"
<cr1901> in the case of these singletons, that would be writing to the same register in two different locations
<re_irc_> <@d​irbaio:m​atrix.org> yep, so you have to ensure these writes are protected with critical sections or atomics or whatever
<re_irc_> <@t​halesfragoso:m​atrix.org> are singleton Sync ?
<cr1901> But that protects two different threads :P
<re_irc_> <@t​halesfragoso:m​atrix.org> the ones from the pac, I mean
<cr1901> I'm asking about a data race in a single thread
<cr1901> (i.e. interrupts off for your entire program, for instance)
<re_irc_> <@d​irbaio:m​atrix.org> within a single thread you won't be touching P0_02 and P0_03 at the same time
<re_irc_> <@d​irbaio:m​atrix.org> you'll be first configuring one, then the next
<re_irc_> <@t​halesfragoso:m​atrix.org> cr1901: how do you get those ?
<re_irc_> <@d​irbaio:m​atrix.org> unless you do weird stuff in the hal
<re_irc_> <@d​irbaio:m​atrix.org> maybe you're thinking of this? https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/
<cr1901> dirbaio: Well on msp430, P1.0 through P1.7 values are changed via the same register
<re_irc_> <@t​halesfragoso:m​atrix.org> you mean mutable aliasing ?
<re_irc_> <@d​irbaio:m​atrix.org> yeah, stm32 is the same
<re_irc_> <@d​irbaio:m​atrix.org> whenever you have to do something with that reg, you should: acquire CS, do it, release CS
<re_irc_> <@a​damgreig:m​atrix.org> Only because of interrupts though
<cr1901> thalesfragoso: Yes, that's the blog post I'm thinking of
<re_irc_> <@a​damgreig:m​atrix.org> If you only have a single thread (ie no interrupts...) you can't race yourself, right?
<cr1901> adamgreig: That is the question I'm asking.
<re_irc_> <@t​halesfragoso:m​atrix.org> cr1901: I don't think the singletons have mutable aliasing problems
<cr1901> This problem doesn't exist at peripheral-level granularity
<cr1901> but at pin-level granularity, you will then have mutable aliasing
<re_irc_> <@t​halesfragoso:m​atrix.org> you can't really get the &mut to anything inside the UnsafeCell
<re_irc_> <@d​irbaio:m​atrix.org> with a CS you can't race other threads, you can only race yourself
<re_irc_> <@t​halesfragoso:m​atrix.org> race yourself ?
<re_irc_> <@d​irbaio:m​atrix.org> AND if you write "yourself's code" correctly then you get full correctness
<re_irc_> <@t​halesfragoso:m​atrix.org> how do you race yourself ?
<re_irc_> <@d​irbaio:m​atrix.org> with the example on that blogpost
<cr1901> Will pin-level granularity cause UB or not in code where interrupts are disabled?
<re_irc_> <@d​irbaio:m​atrix.org> push an item to the vec, causing it to reallocate
<re_irc_> <@d​irbaio:m​atrix.org> create an iter on a vec
<cr1901> But peripherals aren't vecs
<re_irc_> <@d​irbaio:m​atrix.org> that's kinda "racing yourself"
<re_irc_> <@d​irbaio:m​atrix.org> which is the reason rust doesn't allow multiple &mut to the same thing even within the same thread
<re_irc_> <@t​halesfragoso:m​atrix.org> dirbaio: don't you need & to the vec which prevents pushing to it ?
<re_irc_> <@t​halesfragoso:m​atrix.org> Are we talking C ?
<re_irc_> <@d​irbaio:m​atrix.org> we're talking "if rust allowed single-thread shared mutability, it'd still break"
<re_irc_> <@t​halesfragoso:m​atrix.org> I'm lost, sorry
<re_irc_> <@t​halesfragoso:m​atrix.org> I haven't read the blog post ~_~
<re_irc_> <@d​irbaio:m​atrix.org> cr1901: no, it shouldn't cause UB
<re_irc_> <@d​irbaio:m​atrix.org> touching different regs from different threads is fine
<re_irc_> <@a​damgreig:m​atrix.org> I don't think any of the blog post examples apply to an mmio register like we have, do they?
<re_irc_> <@d​irbaio:m​atrix.org> touching the same reg from different threads is fine if you use CSs or atomics
<re_irc_> <@d​irbaio:m​atrix.org> yeah they don't
<re_irc_> <@a​damgreig:m​atrix.org> It doesn't seem like you should be able to race yourself doing something like modifying a gpio register
<cr1901> That is my intuition as well
<cr1901> Watch it be wrong :)
<re_irc_> <@t​halesfragoso:m​atrix.org> All our regs are inside UnsafeCell anyway
<re_irc_> <@d​irbaio:m​atrix.org> well
<re_irc_> <@a​damgreig:m​atrix.org> So single threaded code (no interrupts) could always directly access any register without any synchronisation
<re_irc_> <@d​irbaio:m​atrix.org> you could race yourself if you did stupid shit
<re_irc_> <@a​damgreig:m​atrix.org> Yea true
<cr1901> what is "stupid shit"?
<re_irc_> <@a​damgreig:m​atrix.org> Like if you read the value and then later rmw the reg and then after that write back your read value
<cr1901> thatlesfragoso: IIRC, unsafecell removes noalias
<cr1901> adamgreig: I don't follow :(
<re_irc_> <@t​halesfragoso:m​atrix.org> calling that race is stretchering
<cr1901> Do you have a more concrete example?
<re_irc_> <@a​damgreig:m​atrix.org> `let x = moder.read(); moder.set_pin5_output(); x |= 5; moder.write(x);`
<cr1901> well you can do that from safe code... so that's technically UB?
<re_irc_> <@a​damgreig:m​atrix.org> it's not UB because rust doesn't prevent all race conditions
<re_irc_> <@d​irbaio:m​atrix.org> it's not UB, it's just wrong
<re_irc_> <@a​damgreig:m​atrix.org> only data races which it's not
<cr1901> Oh, I thought that is a single-thread data race
<re_irc_> <@a​damgreig:m​atrix.org> calling it a race condition is definitely a stretch too really
<cr1901> like the ones mentioned in the blog posts
<re_irc_> <@a​damgreig:m​atrix.org> I'm not sure you can ever have a single-thread data race
<re_irc_> <@d​irbaio:m​atrix.org> its behavior is perfectly defined, it's just the wrong behavior :D
<re_irc_> <@a​damgreig:m​atrix.org> the blog post does not describe data races
<re_irc_> <@a​damgreig:m​atrix.org> just other forms of memory unsafety that would be caused by multiple aliasing mutable references
<re_irc_> <@a​damgreig:m​atrix.org> for a "data race" you need concurrency, e.g. not single thread
<re_irc_> <@a​damgreig:m​atrix.org> (and rust prevents data races, so they cannot occur in safe code and are ub in unsafe code)
<cr1901> Well in the context of GPIO pins, at least in STM32 HAL land, they are accessed via pointer deref, not a reference
<re_irc_> <@a​damgreig:m​atrix.org> i don't _think_ that's a material difference
<cr1901> so I guess the mutable reference problem doesn't apply
<cr1901> oh
<re_irc_> <@a​damgreig:m​atrix.org> also they are accessed by reference in stm32 hal land iirc
<re_irc_> <@a​damgreig:m​atrix.org> (because they are accessed by calling methods that receive `&self` on a RegisterBlock)
<cr1901> yes, but they use interior mutability
<cr1901> (... oh, which would allow that aliasing)
<re_irc_> <@a​damgreig:m​atrix.org> yes
<re_irc_> <@a​damgreig:m​atrix.org> but note Cell allows mutability at the cost of not being Sync and so you can't use it from multiple threads and therefore it doesn't let you data race
<re_irc_> <@a​damgreig:m​atrix.org> UnsafeCell (inside registers in mmio embedded stuff) requires you to use `unsafe` and promise you have exclusive access, to the same effect
<re_irc_> <@a​damgreig:m​atrix.org> so it basically works out
<cr1901> exclusive access being distinct (but related) to "shared mutation"
<re_irc_> <@a​damgreig:m​atrix.org> I guess I'd say the &mut system is one way of ensuring exclusive access
<re_irc_> <@a​damgreig:m​atrix.org> where 'exclusive' here means "won't be contested/raced by any other thread"
<cr1901> You mean static mut?
<cr1901> (I thought that was really screwy and upstream isn't even sure it works or SHOULD work)
<re_irc_> <@a​damgreig:m​atrix.org> I think the concern with static mut is that it's extremely difficult to actually use safely
<re_irc_> <@a​damgreig:m​atrix.org> but I don't think it makes a difference to this discussion about single-threaded racing
<cr1901> Basically I'm not sure how these two msgs are related:
<cr1901> (8:53:32 PM) re_irc_: <@a​damgreig:m​atrix.org> where 'exclusive' here means "won't be contested/raced by any other thread"
<cr1901> (8:53:18 PM) re_irc_: <@a​damgreig:m​atrix.org> I guess I'd say the &mut system is one way of ensuring exclusive access
<cr1901> If you taking something by &mut, chances are it's only visible to a single function (and thus thread)
<cr1901> And MMIO opted to use Cells
<re_irc_> <@a​damgreig:m​atrix.org> ah, I meant "if you know you currently have exclusive access to some memory, then you know you cannot have a data race", and "if you have &mut to memory, that counts as having exclusive access"
<cr1901> Ahhh
<re_irc_> <@a​damgreig:m​atrix.org> but there are other ways that count, like "being inside a critical section [on a single-core mcu]", and "having a Cell, since it's not Sync so can't be accessed by any other threads anyway", and "being the only thread in the whole system, regardless of the data, because there are no other threads"
<cr1901> Hmmm, sounds good
<cr1901> This was a good convo, even tho I wrote basically zero code today. Go figure...
<re_irc_> <@a​damgreig:m​atrix.org> rust provides a ton of powerful guarantees here that other languages do not
<re_irc_> <@a​damgreig:m​atrix.org> which is why it can promise 'no data races in safe rust'
<re_irc_> <@a​damgreig:m​atrix.org> unfortunately this leaves us trying to fit interrupts and critical sections etc into rust's execution model :P
<cr1901> (right, but anything useful ultimately requires unsafe somewhere, unless you want to want to do a math calculation and store it in RAM forever.)
<cr1901> adamgreig: I don't think the impedance mismatch of interrupts and critical sections vs OS threads is that dire.
starblue2 has joined #rust-embedded
<cr1901> (i.e. I wouldn't use "unfortunately")
<re_irc_> <@a​damgreig:m​atrix.org> yea, theoretically it seems fine, I guess I just mean rust doesn't already do it internally
<cr1901> Well, no surprises there. The general gist I got of Rust's attitude towards embedded- besides those doing embedded- is "since it's no GC, the ppl who aren't writing for Linux, Mac, or Windoze, will figure it out")
<re_irc_> <@a​damgreig:m​atrix.org> cr1901: idk, you could be operating on a Rust Machine that literally doesn't need any unsafe anywhere else and just provides a safe I/O api
<cr1901> how's the I/O being done safely? :)
<re_irc_> <@a​damgreig:m​atrix.org> who cares, the Rust Machine datasheet says it's fine :p
<re_irc_> <@y​atekii:m​atrix.org> adamgreig: i'd pay for this to happen :D
starblue1 has quit [Ping timeout: 265 seconds]
<re_irc_> <@a​damgreig:m​atrix.org> or the bits of unsafe code you need to rely on from stdlib could be formally proven to provide the same guarantees
<re_irc_> <@a​damgreig:m​atrix.org> of course a library you depend on could just do something wildly unsound in an unsafe block and ruin everything, lol
<re_irc_> <@y​atekii:m​atrix.org> couldn't you make an architecture where certain memory access is just atomic and volatile (for peripherals) and then you gucci?
<re_irc_> <@y​atekii:m​atrix.org> (not sure about the perf implications etc (guess there must be some otherwise all MCUs would do this??))
<re_irc_> <@a​damgreig:m​atrix.org> `macro_rules! very_safe { ($t:tt) => { unsafe! { $t } }` lol
<re_irc_> <@y​atekii:m​atrix.org> guess the pipeline would suck to design if you want to make this happen depending on address lol.
<re_irc_> <@y​atekii:m​atrix.org> adamgreig: me trying to use unsafe lol
<re_irc_> <@a​damgreig:m​atrix.org> 🥱 anyway bedtime here, goodnight!
<re_irc_> <@y​atekii:m​atrix.org> n8!
fabic has joined #rust-embedded
starblue3 has joined #rust-embedded
starblue2 has quit [Ping timeout: 250 seconds]
hifi_ is now known as hifi
emerent has quit [Ping timeout: 268 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
fabic has quit [Quit: Leaving]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
<re_irc_> <@n​ihal.pasham:m​atrix.org> quick question - is anyone using an apple m1 based machine for embedded-rust development? If yes, I'd like to know what works and what doesnt?
<re_irc_> <@n​ihal.pasham:m​atrix.org> more specifically - was wondering if `probe-rs` drivers for the usual probes (such as j-link, cmsis-dap, stlink) work well or if there is something that we need to be aware of
<re_irc_> <@t​iwalun:m​atrix.org> I haven't noticed any issues with probe-rs and M1 based machines so far.
<re_irc_> <@t​herealprof:m​atrix.org> dirbaio: It's a different tradeoff, not necessarily better or worse.
<re_irc_> <@j​amesmunns:m​atrix.org> As a firmware developer, it's certainly a lot less complicated to work with.
<re_irc_> <@j​amesmunns:m​atrix.org> There's a reason we use nrf52s in all our training material, even without wireless stuff.
<astroanax> Is a precompiled version of the rust toolchain for the esp32 available somewhere?
<re_irc_> <@j​amesmunns:m​atrix.org> If I had to explain global clock trees and pin muxes, I'd have to spend a ton more time
<re_irc_> <@j​amesmunns:m​atrix.org> But "here, in the gpio you turn it on, set mode, and good to go" is so nice
<re_irc_> <@j​amesmunns:m​atrix.org> astroanax: not afaik, atm you need to build it from source.
<re_irc_> <@t​herealprof:m​atrix.org> jamesmunns: Yes, I agree.
<cr1901> I thought of something while trying to sleep yesterday... if you imported two semver-incompatible versions of a crate, but they still have the same Peripherals singletons, haven't you just "safely" gotten access to the same memory locations from two threads w/o synchronization?
<cr1901> That works (as long as CORE_PERIPHERALS/DEVICE_PERIPHERALS isn't changed between semver-incompat versions).
tokomak has joined #rust-embedded
<re_irc_> <@j​ordens:m​atrix.org> Due to `no_mangle` it will cause a linker name collision in any case where there are two of them.
<cr1901> Oooh, the comment "used here to prevent linking different minor versions" also implies "used here to prevent linking different major versions"
<cr1901> meaning if a backwards-incompat changed removed that static, nothing good will happen
<re_irc_> <@a​damgreig:m​atrix.org> All the recent releases also use the cargo.toml links key which stops cargo even trying to link multiple versions together, except for our special semver hack versions which re-export peripherals from later releases to allow cross version compatibility
<cr1901> adamgreig: I suppose I should ask my real question
<cr1901> If I have a Peripherals struct from a PAC, with peripheral-level granularity for GPIO (not pin level), is the only recourse I have to safely get pin-level granularity to consume the peripheral and use GPIO::ptr() accesses from with the pin-level struct?
<cr1901> This is what STM32 does. I'd much rather code my own struct using the register block directly, but AFAICT, the minute I try to create a separate static that aliases registers from another struct, I can create data races
<cr1901> (and the Peripherals abstract gets around the data race problem by forcing you to take all peripherals at once in a single thread)
<re_irc_> <@a​damgreig:m​atrix.org> Have you seen the split() methods in lots of HALs?
<re_irc_> <@a​damgreig:m​atrix.org> Basically yes, by convention ownership of the GPIO struct instance implies exclusive access to the registers, so your new struct should somehow consume the PAC struct (eg in new) to prevent two existing at once
<re_irc_> <@a​damgreig:m​atrix.org> But after consuming it you could use the unsafe ptr methods to access fields so long as you do something else for synchronisation (like bitbanding or only using atomic registers (bit set etc) or critical sections)
<cr1901> Or using it from a single thread only :)
<re_irc_> <@a​damgreig:m​atrix.org> Indeed (with no interrupts ever allowed to access it, and the structs made not sync)
<re_irc_> <@a​damgreig:m​atrix.org> I guess also not send in this case
<cr1901> >and the structs made not sync
<cr1901> That's the default IIRC
<cr1901> and not send, I'm not sure... the peripherals themselves implement Send. Althought notably, Parts doesn't
<cr1901> adamgreig: Also, I forgot this, but... Deref for peripherals is implemented in terms the PTR. It's just that if you consume the peripheral, you have no way of returning a pin-level abstraction using Deref (because lifetimes for the pin regs will exceed the GPIO peripheral lifetime)
<cr1901> So you have to use the pointer/unsafe
fabic has joined #rust-embedded
<re_irc_> <@w​cpannell:m​atrix.org> Can I solicit a little advice for my HAL API? Basically, on my MCU the gpiox::into_analog equivalent functionality is controlled by the ADC peripheral. That peripheral must have its clock gated to it (handled by Adc<Disabled>::enable) before touching it, otherwise any read/write of the peripheral's registers...
<re_irc_> ... triggers a HardFault.
<re_irc_> <@w​cpannell:m​atrix.org> I'm looking at either leaving into_analog in the gpiox modules and checking if the Adc is enabled at runtime (effectively try_into_analog), or providing something like channel_to_analog in the impl Adc<Enabled> section. The former is a little gross. The latter feels pretty different from what all the other...
<re_irc_> ... HALs do.
<cr1901> What does the "PhantomData<*const ()>" in peripherals actually do? One thing I can think of is to prevent derivation of Send/Sync. But what else is it for?
<re_irc_> <@f​irefrommoonlight:m​atrix.org> I'd go with hardware consistency, and let the ADC configure the pin as Analog in its constructor or other setup fn.
<re_irc_> <@f​irefrommoonlight:m​atrix.org> I feel like letting the Gpio module do it would be surprising to people used to the MCU
<re_irc_> <@w​cpannell:m​atrix.org> Thanks, that makes a lot of sense
<re_irc_> <@y​ruama_lairba:m​atrix.org> hi, i'd like to know correpondance between a rust toolchain and a MPU/MCU
<re_irc_> <@y​ruama_lairba:m​atrix.org> specifically, i'd like to know wich toolchain i should use if i want to use a pi zero in a "bare metal" way
<re_irc_> <@g​damjan:s​podeli.org> yruama_lairba: https://docs.rust-embedded.org/book/intro/install.html
<re_irc_> <@g​damjan:s​podeli.org> now pi zero is a … ARM11 cpu?
<re_irc_> <@y​ruama_lairba:m​atrix.org> gdamjan: thanks, but it's only talk about Cortex family MCU/MPU
<re_irc_> <@r​yan-summers:m​atrix.org> The RPI is a broadcom BCM2835, which is a cortex family CPU - https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf
<re_irc_> <@y​ruama_lairba:m​atrix.org> yes, i just wonder if i could use a pi zero like as powerfull and cheap dev board
<re_irc_> <@r​yan-summers:m​atrix.org> The Rpi Zero*
<re_irc_> <@g​damjan:s​podeli.org> wikipedia says ARMv6Z, also https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/README.md says ARM1176 processor
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
<re_irc_> <@9​names:m​atrix.org> ryan-summers: ARM11 pre-dates cortex branding
<re_irc_> <@r​yan-summers:m​atrix.org> Ah, didn't know that. Thanks for the info
<re_irc_> <@r​yan-summers:m​atrix.org> The process from a rust-embedded perspective is almost identical for ARMv6 though
<re_irc_> <@r​yan-summers:m​atrix.org> Although I'm not sure if ARM11 == ARMv6?
<re_irc_> <@9​names:m​atrix.org> yes it does
<re_irc_> <@9​names:m​atrix.org> arm's old naming convention was pretty confusing, the newer one is a bit less likely to evoke that sort of confusion
<re_irc_> <@9​names:m​atrix.org> ARM9 was even worse, as it spanned both ARMv4 and ARMv5 ISAs
<re_irc_> <@y​ruama_lairba:m​atrix.org> but what kind of cortex bcm2835 is ?
<re_irc_> <@r​yan-summers:m​atrix.org> It's not a cortex as mentioned above - it is an ARMv6 architecture though
<re_irc_> <@y​ruama_lairba:m​atrix.org> crap, seems i need to build myself the toolchain if i want to try to do "bare metal" stuff with it
_whitelogger has joined #rust-embedded
agg has joined #rust-embedded
ni has joined #rust-embedded
vancz has joined #rust-embedded
dreamcat4 has joined #rust-embedded
agg is now known as Guest2863
Rondom has joined #rust-embedded
ni has quit [Client Quit]
Amanieu has joined #rust-embedded
dirbaio2 has joined #rust-embedded
ni has joined #rust-embedded
mrkajetanp has joined #rust-embedded
<re_irc_> <@y​atekii:m​atrix.org> We finally released probe-rs 0.11.0 🎉 https://probe.rs/blog/release-0-11-0/ Thanks everyone!
fabic has quit [Ping timeout: 252 seconds]
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Dude - I love probe-rs. Thank you for making the Rust embedded ecosystem as nice as it is. Probe-rs and Cargo-flash are outstanding critical infrastructure that make it such a nice experience
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Also, thank you to the Knurling team for building probe-run on top of it
<cr1901> So by default, the STM32 HALs return GPIO parts (from split()) in Input<Floating> mode. How does the HAL guarantee that any time split() is called, the pins will, in fact, be in that mode?
<re_irc_> <@d​irbaio:m​atrix.org> Theyre in that mode from cold boot
<re_irc_> <@t​halesfragoso:m​atrix.org> cr1901: Now that made me remember of one question, does reset in RCC really reset all registers to the reset values ?
<re_irc_> <@t​halesfragoso:m​atrix.org> cr1901: probably just for that
tokomak has quit [Read error: Connection reset by peer]
<re_irc_> <@y​atekii:m​atrix.org> firefrommoonlight: thanks! we try hard :)
<re_irc_> <@j​amesmunns:m​atrix.org> Psst, if you are looking for a rust-embedded job, I have been retweeting like crazy from this thread: https://twitter.com/HyblMatous/status/1407275874471321602
<re_irc_> <@j​amesmunns:m​atrix.org> Also reminder, if you are looking for a rust-embedded job, POST ABOUT IT ON TWITTER AND TAG THE `@rustembedded` account so I can retweet it!
<re_irc_> <@j​amesmunns:m​atrix.org> (or: if your company is *looking* to hire rust-embedded devs, make a job posting that mentions Rust, and tag rustembedded so I can retweet it!)
<re_irc_> <@j​amesmunns:m​atrix.org> My general policy is here: https://twitter.com/rustembedded/status/1403675307413065733
<re_irc_> <@j​amesmunns:m​atrix.org> I don't have a good solution for folks that can't make that info public (but I am open to ideas!), or for folks that don't have twitter, but if I can help, I'm always happy to.
<re_irc_> <@j​amesmunns:m​atrix.org> DMs always open (on twitter or here on Matrix), if you'd like to chat.
<re_irc_> <@j​amesmunns:m​atrix.org> Also, leaking information on twitter, as I am want to do:
<re_irc_> <@j​amesmunns:m​atrix.org> https://twitter.com/bitshiftmask/status/1408153112540557315
<re_irc_> <@d​irbaio:m​atrix.org> Thanks for the heads up, posted :)
<re_irc_> <@d​irbaio:m​atrix.org> gonna post it here too, in case someone is interested!
<re_irc_> <@d​irbaio:m​atrix.org> At Akiles (https://akiles.app/en) we're just now opening our first Rust firmware dev position. Remote, ideally EU timezone. We're a tiny team (3 engineers, all remote), you'd be the first firmware-only developer. DM me for details!
<cr1901> >dirbaio Theyre in that mode from cold boot
<cr1901> What prevents a user from changing the mode _before_ creating a HAL instance from split()? (Also, you can't get the original register block back once you split?)
<re_irc_> <@d​irbaio:m​atrix.org> hmmm
<re_irc_> <@d​irbaio:m​atrix.org> ....nothing?
<re_irc_> <@d​irbaio:m​atrix.org> 🤣
<re_irc_> <@d​irbaio:m​atrix.org> yeah you can totally use the raw regblock to change the mode, then do .split() and you get the pins in the wrong mode
<cr1901> Well, that's "safe" I guess, but feels rather undesirable :P
<cr1901> (And what if there's a hardware peripheral you could damage by the HAL assuming it's in one mode, but isn't actually in that mode? :P)
<re_irc_> <@j​amesmunns:m​atrix.org> Hanno Braun feels more strongly on this topic
<re_irc_> <@j​amesmunns:m​atrix.org> He basically thinks the hal should be responsible for taking periphs for this reason
<re_irc_> <@d​irbaio:m​atrix.org> hehe, what embassy does
<re_irc_> <@d​irbaio:m​atrix.org> who'd have thought
<re_irc_> <@d​irbaio:m​atrix.org> :D
<re_irc_> <@j​amesmunns:m​atrix.org> Makes sense
<cr1901> https://github.com/stm32-rs/stm32f4xx-hal/blob/master/src/gpio.rs#L270 But STm32 HAL _does_ take the GPIO peripheral?
<re_irc_> <@y​ruama_lairba:m​atrix.org> ouch, I didn't remember rtic was so long to compile
<cr1901> And doesn't do anything with it
<re_irc_> <@t​halesfragoso:m​atrix.org> Maybe the clock reset does reset the registers ?
<re_irc_> <@t​halesfragoso:m​atrix.org> jamesmunns: Don't they ?
<re_irc_> <@d​irbaio:m​atrix.org> yeah, he means "user takes peripherals from the HAL"
<re_irc_> <@d​irbaio:m​atrix.org> instead of the current "user takes peripherals from the PAC and then gives them to the HAL"
<re_irc_> <@t​halesfragoso:m​atrix.org> Oh
<cr1901> hmmmm
<re_irc_> <@d​irbaio:m​atrix.org> because in between these, the user can muck around with the raw regs
* cr1901 chews on this for a while
<re_irc_> <@d​irbaio:m​atrix.org> arguably the HAL should reset the peripheral though
<cr1901> I mean, this wouldn't be the only place in embedded Rust where "don't do that" is the correct advice
<re_irc_> <@d​irbaio:m​atrix.org> I think many stm32 hals do that for uart/spi/i2c/etc
<re_irc_> <@d​irbaio:m​atrix.org> and I think gpio ports can also be reset with rcc (?)
<cr1901> e.g. https://blog.japaric.io/brave-new-io/ The Peripherals singleton provides a method to _prevent_ the problem described in this post
<cr1901> but you can certainly still write code that opts-in to the problem described :P
<re_irc_> <@b​raincode:m​atrix.org> jamesmunns: Last commits from espressif/esp32-rust-example repo they were dockerizing it for easier DX, IIRC
<re_irc_> <@b​raincode:m​atrix.org> nihal.pasham: Works for me on stlink v2 cheap Aliexpress probe
<re_irc_> <@b​raincode:m​atrix.org> dirbaio: Cool product! Did you send a sample to the lockpicking lawyer? One of my recent favourite channels :P
<re_irc_> <@d​irbaio:m​atrix.org> hahaha
<re_irc_> <@d​irbaio:m​atrix.org> it has no keyholes to pick, it's electronic only
<re_irc_> <@d​irbaio:m​atrix.org> not sure if he picks suck things too
<re_irc_> <@b​raincode:m​atrix.org> He does too, low sec rfid access IIRC and thumbprint and Bluetooth ones too
<re_irc_> <@d​irbaio:m​atrix.org> ooh
<re_irc_> <@h​anno:b​raun-odw.eu> dirbaio: Good to know I'm not the only one feeling the need to re-invent that particular wheel 😁
<re_irc_> <@h​anno:b​raun-odw.eu> I really need to take a close look at embassy. I never took the time, but I keep hearing bits and pieces I totally agree with. Interrupts being something that an be owned, for example. Been saying that for years 😄
nohit has quit []
nohit has joined #rust-embedded
<re_irc_> <@y​ruama_lairba:m​atrix.org> hello, i there a trick to know parameters of a generic type ?
<re_irc_> <@y​ruama_lairba:m​atrix.org> i mean i'm starting to use RTIC and i want to share a resource where the type is a big generic
<re_irc_> <@d​irbaio:m​atrix.org> assign it to a u32 variable or something
<re_irc_> <@d​irbaio:m​atrix.org> then try to compile
<re_irc_> <@d​irbaio:m​atrix.org> rust will print the full type in the compile error
<re_irc_> <@y​ruama_lairba:m​atrix.org> ;( it's too ugly, it's take almost three lines
<re_irc_> <@d​irbaio:m​atrix.org> 🤷‍♂️
<re_irc_> <@d​irbaio:m​atrix.org> HAL writers love their generics
<re_irc_> <@d​irbaio:m​atrix.org> you can make it less ugly if you paste it in a type alias
<re_irc_> <@d​irbaio:m​atrix.org> but the type is what it is....
<re_irc_> <@d​irbaio:m​atrix.org> you can't magically shorten it
<re_irc_> <@y​ruama_lairba:m​atrix.org> type alias ? i don't rememenber the syntax,
<re_irc_> <@d​irbaio:m​atrix.org> `type MyThing = Foo<Bar, Baz<Blah, Alternate<OpenDrain<Alternate7>>;`
<re_irc_> <@d​irbaio:m​atrix.org> then you can simply write `MyThing` instead of the big type
<re_irc_> <@y​ruama_lairba:m​atrix.org> okay, d you have a concrete example ? it's just to see some used convention
<re_irc_> <@d​irbaio:m​atrix.org> can't think of a concrete example right now
Guest2863 is now known as agg
nohit has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
dirbaio2 has quit [*.net *.split]
rektide_ has quit [*.net *.split]
bpye has quit [*.net *.split]
agg has quit [*.net *.split]
jasperw has quit [*.net *.split]
mrkajetanp has quit [*.net *.split]
Amanieu has quit [*.net *.split]
Rondom has quit [*.net *.split]
hifi has quit [*.net *.split]
vancz has quit [*.net *.split]
Shell has quit [*.net *.split]
cr1901 has quit [*.net *.split]
cyrozap has quit [*.net *.split]
xnor has quit [*.net *.split]
Darius has quit [*.net *.split]
creich has quit [*.net *.split]
mightypork_ has quit [*.net *.split]
dkm has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
sauce has quit [*.net *.split]
re_irc_ has quit [*.net *.split]
Ekho has quit [*.net *.split]
njha has quit [*.net *.split]
Windfisch has quit [*.net *.split]
fooker has quit [*.net *.split]
richardeoin has quit [*.net *.split]
astroanax has quit [*.net *.split]
Rahix has quit [*.net *.split]
inara has quit [*.net *.split]
bendemctl has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
x56 has quit [*.net *.split]
astroanax has joined #rust-embedded
fooker has joined #rust-embedded
agg has joined #rust-embedded
cyrozap has joined #rust-embedded
x56 has joined #rust-embedded
cr1901 has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
bendemctl has joined #rust-embedded
inara has joined #rust-embedded
xnor has joined #rust-embedded
jasperw has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
bpye has joined #rust-embedded
creich has joined #rust-embedded
Rahix has joined #rust-embedded
richardeoin has joined #rust-embedded
mightypork_ has joined #rust-embedded
dirbaio2 has joined #rust-embedded
Darius has joined #rust-embedded
rektide_ has joined #rust-embedded
re_irc_ has joined #rust-embedded
Ekho has joined #rust-embedded
mrkajetanp has joined #rust-embedded
hifi has joined #rust-embedded
Rondom has joined #rust-embedded
Amanieu has joined #rust-embedded
vancz has joined #rust-embedded
Shell has joined #rust-embedded
sauce has joined #rust-embedded
njha has joined #rust-embedded
Windfisch has joined #rust-embedded
dkm has joined #rust-embedded
Lumpio- has joined #rust-embedded
nohit has joined #rust-embedded
<re_irc_> <@y​ruama_lairba:m​atrix.org> firefrommoonlight: i just copied the expected type
<re_irc_> <@f​irefrommoonlight:m​atrix.org> sweet
<re_irc_> <@y​ruama_lairba:m​atrix.org> otherwise it would be pain since my generic is recursively defined
<re_irc_> <@y​ruama_lairba:m​atrix.org> i mean it's a generic build with a generic build with a generic ...