<re_irc>
<@dirbaio:matrix.org> ooh it's guaranteed! TIL
<re_irc>
<@dirbaio:matrix.org> isn't the layout of `*const T` guaranteed to be the same as `usize` as well?
<re_irc>
<@adamgreig:matrix.org> if T is sized...
<re_irc>
<@adamgreig:matrix.org> "The sizes of &T, &mut T, *const T and *mut T are the same, and are at least one word.
<re_irc>
<@adamgreig:matrix.org> If T is a sized type then the size of &T is one word."
<re_irc>
<@dirbaio:matrix.org> hmhm you can't have a slice of unsized stuff can you?
<re_irc>
<@dirbaio:matrix.org> so I guess `(usize, usize)` should be fine..??
<re_irc>
<@dirbaio:matrix.org> I'll change it to `*const T` just to be safe heh
<re_irc>
<@dirbaio:matrix.org> thanks for the link! 👍️
<re_irc>
<@adamgreig:matrix.org> I don't see why you wouldn't make it (*const T, usize) but yea, pass on whether you can have a slice of unsized objects
<re_irc>
<@adamgreig:matrix.org> off the top of my head maybe you can't and so it would always be one word but not sure
<re_irc>
<@adamgreig:matrix.org> hmmm
<re_irc>
<@dirbaio:matrix.org> I was just being lazy, I was casting the ptr to usize later anyway
<re_irc>
<@adamgreig:matrix.org> heh
<re_irc>
<@adamgreig:matrix.org> without pointer receiver methods I don't think there's any better way to get the length from a *const[T]
<re_irc>
<@thebutlah:matrix.org> Question: I have never written any embedded software before, but I'm really interested in writing some mechanical keyboard firmware, like a rust version of QMK or ZMK. I wanted to know whether it is a good idea to do it from scratch with embedded-hal, use a rust rtos, or use something like embassy.
<re_irc>
<@thebutlah:matrix.org> I am hesitant to use anything but embedded-hal because I'm not seeing support for the chips that I need support for in embassy. I need to support the following boards:
<re_irc>
<@tholmie:matrix.org> Supporting all three of those will be annoying since they’re all different architectures
<re_irc>
<@thebutlah:matrix.org> how annoying is annoying? I am naively assuming that as long as they all implement embedded-hal it shouldn't be too bad
<re_irc>
<@9names:matrix.org> i mean, even just supporting your atmega32u4 will be difficult - avr support in rust is not stable, I don't even know if anyone has done USB with it yet
rardiol has quit [Ping timeout: 245 seconds]
<re_irc>
<@jamesmunns:beeper.com> Also, not to discourage you from writing your own, but you might want to peek at https://github.com/TeXitoi/keyberon
<re_irc>
<@thebutlah:matrix.org> jamesmunns:beeper.com: yeah just saw this, will definitely use it to whatever extent I can
<re_irc>
<@jamesmunns:beeper.com> I'm all for "rewrite the world because you want to"
<re_irc>
<@jamesmunns:beeper.com> just wanted to make sure that's what you actually wanted :)
<re_irc>
<@thebutlah:matrix.org> jamesmunns:beeper.com: these are async/await bindings which implies id be limited by embassy-rs platform support right?
<re_irc>
<@jamesmunns:beeper.com> IIRC it works with or without embassy
<re_irc>
<@jamesmunns:beeper.com> dirbaio would be the one to talk to tho
<re_irc>
<@thebutlah:matrix.org> jamesmunns:beeper.com: yes, although I want to at least accomplish the actual goal of a working keyboard
<re_irc>
<@jamesmunns:beeper.com> Also check with #nrf-rs:matrix.org
<re_irc>
<@josfemova:matrix.org> but seems it's close to being...fixed (?
<re_irc>
<@adamgreig:matrix.org> there's a tier3 target but it still requires nightly iirc
<re_irc>
<@9names:matrix.org> "Tier 3 targets are those which the Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work"
<re_irc>
<@9names:matrix.org> spoiler: it often doesn't work.
<re_irc>
<@thebutlah:matrix.org> adamgreig: dont mind needing nightly - embassyrs also needs nightly
<re_irc>
<@adamgreig:matrix.org> yep, should be OK then
<re_irc>
<@adamgreig:matrix.org> for sure today's nightly might sometimes break but you can stick with a given working nightly until you need to swap to a newer one for some reason and the avr-rust people seem pretty on the ball about it?
<re_irc>
<@adamgreig:matrix.org> it's not stable but it should be workable is my understanding... though i have not run any rust code on an avr so far
<re_irc>
<@9names:matrix.org> even when it compiles and runs, there's still a bunch of stuff that will result in panics.
<re_irc>
<@9names:matrix.org> really not recommended for embedded beginners, and certainly not recommended to be "commercially viable"
<re_irc>
<@adamgreig:matrix.org> depends on your tolerance for fixing things if they break and so on I guess. rust avr issues are tracked on https://github.com/rust-lang/rust/labels/O-AVR, it doesn't seem completely overwhelming
<re_irc>
<@9names:matrix.org> true. i'm sure the avr folks would appreciate compiler and library fixes, so if that's what you need to target: go ahead. just trying to give sufficient warning that it's really newbie friendly yet.
<re_irc>
<@adamgreig:matrix.org> you'll definitely have a harder time of it than a more well-supported target like cortex-m
<re_irc>
<@adamgreig:matrix.org> but yea, pretty much all the hobbyist keyboard boards are atmega32u4 for whatever reason huh
starblue has quit [Ping timeout: 252 seconds]
<re_irc>
<@9names:matrix.org> yeah, hobbyists and their AVRs :/
<re_irc>
<@9names:matrix.org> could be worse, they could have stuck with PICs
<re_irc>
<@thebutlah:matrix.org> yeah - also tbh stm32 is another target I would need to support
<re_irc>
<@thebutlah:matrix.org> but nrf52 and stm32 are both arm cortex-m
<re_irc>
<@thebutlah:matrix.org> so its not so bad
<re_irc>
<@thebutlah:matrix.org> avr is just the difficult one
<re_irc>
<@adamgreig:matrix.org> yea, both nrf52 and stm32 are well supported
<re_irc>
<@thebutlah:matrix.org> so with that in mind - that I also need to support avr, what do y'all think I would need to do? Just use embedded-hal?
starblue has joined #rust-embedded
<re_irc>
<@9names:matrix.org> are you just doing software, or hardware as well?
<re_irc>
<@thebutlah:matrix.org> Hardware is only a matter of soldering some stuff - im not designing new boards
<re_irc>
<@thebutlah:matrix.org> just attaching mcu to a shield/daughterboard
<re_irc>
<@adamgreig:matrix.org> embedded-hal doesn't provide any USB abstractions, so you'd need something else to make that generic - https://crates.io/crates/usb-device is the main one which is implemented for stm32 and nrf and most cortex-m targets, not sure about avr though
<re_irc>
<@adamgreig:matrix.org> you're probably still going to find yourself writing a meaningful amount of code for each platform, rather than purely gluing existing implementations to your application-level stuff
<re_irc>
<@thebutlah:matrix.org> hmm, yeah usb-device doesn't have avr support because it needs trait objects and avr doesn't compile correctly with trait objects
<re_irc>
<@thebutlah:matrix.org> I wonder if I just eliminate the need for the pro micro in the short term. The nice!nano is the same form factor and pin compatible, and eventually avr will be more stable. I just need to design with the assumption that I should not expect too many higher level libs to support it rn. I think I will try to use embedded-hal and usb-device for now as much as possible and avoid async
<re_irc>
<@thebutlah:matrix.org> is there any alternative to usb-device for usb avr support?
<re_irc>
<@9names:matrix.org> linking against a C library that handles USB?
smach has joined #rust-embedded
smach has quit [Remote host closed the connection]
chrisb has quit [Ping timeout: 245 seconds]
chrisb has joined #rust-embedded
smach has joined #rust-embedded
radens has joined #rust-embedded
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter has joined #rust-embedded
radens has quit [Quit: Connection closed for inactivity]
edm is now known as Blitzedm
<re_irc>
<@lidialiker:matrix.org> how can one measure elapsed time on the device?
rardiol has joined #rust-embedded
smach has quit [Quit: Leaving]
<re_irc>
<@lidialiker:matrix.org> ^ sorry nvm, I guess I need to use a timer
<re_irc>
<@eldruin:matrix.org> dbrgn:matrix.coredump.ch: An alternative might be to put all that decoding into a program and make it write everything into plain text logfiles. Then put the whole thing in a docker container and just not update anything. Just `docker run` in 2 years. A virtual machine might also be an option
<re_irc>
<@robgal519:matrix.org> Hej, I have struct to hold GPIO using embedded_hal for portability
<re_irc>
<@robgal519:matrix.org> pub use embedded_hal::digital::v2::InputPin;
<re_irc>
<@robgal519:matrix.org> pub use embedded_hal::digital::v2::OutputPin;
<re_irc>
<@robgal519:matrix.org> So to simplify this issue, let's consider an example Where I have struct with trait parameters, and in other file, I want to return such struct object. How to declare such return type? I can see that those Pins that I prepared, have correct functions for Output and Input Pin traits from embedded_HAL, that is why I do not understand why my code does not work :(
<re_irc>
<@robgal519:matrix.org> Or maybe I try to do something awkward ? How would you approach implementing low level access to provide embedded_HAL abstractions for an application ? (I would like to be able to select in Cargo for what board I build, and everything should just work )
<re_irc>
<@firefrommoonlight:matrix.org> You can't store generics. You need to make the struct field holes the pin struct
<re_irc>
<@robgal519:matrix.org> so the issue here is that I used an array, and not struct to agregate the buttons and LEDs ?
<re_irc>
<@firefrommoonlight:matrix.org> No
<re_irc>
<@firefrommoonlight:matrix.org> The issue is that you used an `embedded_hal` trait instead of the struct that implements it
<re_irc>
<@robgal519:matrix.org> Ok it does make sense, Thank you
rardiol has quit [Ping timeout: 240 seconds]
rardiol has joined #rust-embedded
smach has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<re_irc>
<@angelonfira:matrix.org> Hi! I'm trying to use Rust to interact with a cool light tree my friend set up. Here are the specs:
<re_irc>
<@angelonfira:matrix.org> This is the C code that works
<re_irc>
<@k900:0upti.me> Uhh
<re_irc>
<@k900:0upti.me> How in the FUCK
<re_irc>
<@dirbaio:matrix.org> ah, `linux-embedded-hal` uses `spidev` internally and impls the `embedded-hal` traits
<re_irc>
<@dirbaio:matrix.org> so the advantage of using `linux-embedded-hal` is it'd make porting to non-linux MCUs easier, otherwise it's probably the same
<re_irc>
<@k900:0upti.me> So you're saying this code runs
<re_irc>
<@k900:0upti.me> And works
<re_irc>
<@k900:0upti.me> Because IT REALLY REALLY EXTREMELY SHOULD NOT
<re_irc>
<@k900:0upti.me> I'm pretty sure it actually just EINVALs
<re_irc>
<@k900:0upti.me> And you're not checking the error code
<re_irc>
<@k900:0upti.me> Or he's not, anyway
<re_irc>
<@k900:0upti.me> Unless he also fixed it to be a real pointer
<re_irc>
<@k900:0upti.me> C, man
<re_irc>
<@k900:0upti.me> What a language
<re_irc>
<@k900:0upti.me> Oh also
<re_irc>
<@k900:0upti.me> For additional context
<re_irc>
<@k900:0upti.me> The SPI_IOC_WR_BLAH ioctls write blah
<re_irc>
<@k900:0upti.me> The SPI_IOC_RD_BLAH ioctls _read_ blah
<re_irc>
<@k900:0upti.me> And write it to the last argument
<re_irc>
<@k900:0upti.me> Which should be a pointer
<re_irc>
<@k900:0upti.me> (but is still extremely not a pointer)
<re_irc>
<@k900:0upti.me> It looks like your friend thinks they refer to the read side and write side of the connection
<re_irc>
<@k900:0upti.me> But that's not the case because those settings actually affect the entire bus in all directions
<re_irc>
<@k900:0upti.me> Also please keep us updated
<re_irc>
<@k900:0upti.me> I want to know how much of your friend's computer is on fire now
<re_irc>
<@angelonfira:matrix.org> Testing now :)
<re_irc>
<@angelonfira:matrix.org> 😂
<re_irc>
<@angelonfira:matrix.org> Just figuring out how to cross compile for the pi
<re_irc>
<@k900:0upti.me> You should be able to just `rustup target add aarch64-unknown-linux-gnu` followed by `cargo build --target aarch64-unknown-linux-gnu`
<re_irc>
<@angelonfira:matrix.org> I'm getting linker errors with that