<re_irc> <@adamgreig:matrix.org> dirbaio:matrix.org: should be (*const T, usize) right?
<re_irc> <@adamgreig:matrix.org> that layout is guaranteed https://rust-lang.github.io/unsafe-code-guidelines/layout/pointers.html
<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> <@thebutlah:matrix.org> * Elite-C (ATmega32u4)
<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> <@jamesmunns:beeper.com> Also wrt softdevice: https://github.com/embassy-rs/nrf-softdevice
<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> <@thebutlah:matrix.org> jamesmunns:beeper.com: dirbaio
<re_irc> <@thebutlah:matrix.org> I really can't get away from targetting the pro micro as it is the microcontroller that all mech keyboards target
<re_irc> <@thebutlah:matrix.org> and the nice!nano is the best bluetooth one and has good rust support
<re_irc> <@thebutlah:matrix.org> so I can start with those two boards for now
<re_irc> <@9names:matrix.org> of course you can! you're writing the software
<re_irc> <@adamgreig:matrix.org> #avr-rust_Lobby:gitter.im might also be a good place to ask about AVR stuff
<re_irc> <@adamgreig:matrix.org> (and https://github.com/avr-rust)
<re_irc> <@adamgreig:matrix.org> (and https://book.avr-rust.com/)
<re_irc> <@thebutlah:matrix.org> I thought rustc avr support was merged and that its tier3 now
<re_irc> <@josfemova:matrix.org> last I knew they were dealing with some compiler issues
<re_irc> <@josfemova:matrix.org> https://reviews.llvm.org/D114611
<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 struct Dut<IN: InputPin, OUT: OutputPin>{
<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> So I think the specs are:
<re_irc> <@angelonfira:matrix.org> - SPI
<re_irc> <@angelonfira:matrix.org> - Mode 4
<re_irc> <@angelonfira:matrix.org> - Send data
<re_irc> <@angelonfira:matrix.org> I was looking into `embedded-hal`, is this the right direction to go?
<re_irc> <@k900:0upti.me> Uhh
<re_irc> <@k900:0upti.me> SPI doesn't _have_ a mode 4
<re_irc> <@k900:0upti.me> There's only 4 modes and they're 0-based
<re_irc> <@angelonfira:matrix.org> I'll check with him
<re_irc> <@dirbaio:matrix.org> angelonfira:matrix.org: embedded-hal just defines traits for SPI
<re_irc> <@dirbaio:matrix.org> You'll have to use it together with a HAL for the chip you're using, which will provide implementations of the traits
<re_irc> <@k900:0upti.me> Also those numbers are inconsistent and you should really just ask him for the CPOL/CPHA values
<re_irc> <@angelonfira:matrix.org> This is just running on a raspberry pi, so I think it shouldn't be too complex?
<re_irc> <@k900:0upti.me> Then you probably want https://docs.rs/spidev/latest/spidev/
<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 uh
<re_irc> <@k900:0upti.me> I don't really know what to tell you
<re_irc> <@angelonfira:matrix.org> Sorry for CDN link
<re_irc> <@k900:0upti.me> Because the last argument to those ioctls should be a pointer
<re_irc> <@k900:0upti.me> And the things you are passing in are VERY MUCH NOT POINTERS
<re_irc> <@angelonfira:matrix.org> I'll try it with 3 and see how it works I guess?
<re_irc> <@k900:0upti.me> Also there is still no mode 3
<re_irc> <@k900:0upti.me> So hopefully all of those actually just EINVAL
<re_irc> <@k900:0upti.me> And nothing actually gets configured
<re_irc> <@k900:0upti.me> And you're not just stomping all over memory at address 8
<re_irc> <@k900:0upti.me> (which is a very bad address to be stomping all over)
<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
<re_irc> <@angelonfira:matrix.org> Also I was trying `armv7-unknown-linux-gnueabihf`
<re_irc> <@k900:0upti.me> Depends on the Pi model
<re_irc> <@angelonfira:matrix.org> Pi 0 I think
<re_irc> <@k900:0upti.me> The original or 2/2W?
<re_irc> <@angelonfira:matrix.org> "pi zero w 2, it's really new"
<re_irc> <@dirbaio:matrix.org> they're still shipping 32bit OS even for 64bit rpis
<re_irc> <@dirbaio:matrix.org> so yes `armv7-unknown-linux-gnueabihf` is the correct one
<re_irc> <@k900:0upti.me> They are? I think Pi4s are aarch64 at least
<re_irc> <@dirbaio:matrix.org> the *hardware* can run both armv7 and aarch64
<re_irc> <@dirbaio:matrix.org> the *OS* they give you is armv7
<re_irc> <@k900:0upti.me> I mean with the stock Raspbian
<re_irc> <@dirbaio:matrix.org> and an armv7 kernel can't run aarch64 userspace binaries
<re_irc> <@angelonfira:matrix.org> [package]
<re_irc> <@angelonfira:matrix.org> name = "aidan-tree"
<re_irc> <@angelonfira:matrix.org> version = "0.1.0"
<re_irc> <@angelonfira:matrix.org> ```rust
<re_irc> <@angelonfira:matrix.org> This is my build file
<re_irc> <@angelonfira:matrix.org> cargo.toml*
<re_irc> <@k900:0upti.me> Do you actually have an `arm-linux-gnueabihf-gcc`
<re_irc> <@angelonfira:matrix.org> Linker you mean/
<re_irc> <@angelonfira:matrix.org> I'm on arch, so I'm not 100% sure
<re_irc> <@dirbaio:matrix.org> AngelOnFira: post the full error please
<re_irc> <@k900:0upti.me> Try `pacman -S lld` and setting `linker = "lld"` then
<re_irc> <@k900:0upti.me> That's probably the easiest option
<re_irc> <@angelonfira:matrix.org> error: linking with `cc` failed: exit status: 1
<re_irc> <@angelonfira:matrix.org> |
<re_irc> <@angelonfira:matrix.org> = note: "cc" "/home/forest/Documents/git/aidan-tree/target/armv7-unknown-linux-gnueabihf/release/deps/aidan_tree-8fca58edaf71a188.aidan_tree.70b7c687-cgu.0.rcgu.o" "/home/forest/Documents/git/aidan-tree/target/armv7-unknown-linux-gnueabihf/release/deps/aidan_tree-8fca58edaf71a188.aidan_tree.70b7c687-cgu.1.rcgu.o"...
<re_irc> ... "/home/forest/Documents/git/aidan-tree/target/armv7-unknown-linux-gnueabihf/release/deps/aidan_tree-8fca58edaf71a188.aidan_tree.70b7c687-cgu.2.rcgu.o" "/home/forest/Documents/git/aidan-tree/target/armv7-unknown-linux-gnueabihf/release/deps/aidan_tree-8fca58edaf71a188.aidan_tree.70b7c687-cgu.3.rcgu.o"...
<re_irc> <@angelonfira:matrix.org> I just tried the lld linker swap, and I think that didn't work
<re_irc> <@dirbaio:matrix.org> hm, for some reason it isn't picking up your linker, it's still running `cc`
<re_irc> <@angelonfira:matrix.org> linker options are suppose to be in cargo.toml right?
<re_irc> <@angelonfira:matrix.org> oops
<re_irc> <@dirbaio:matrix.org> no, in `.cargo/config.toml`
<re_irc> <@angelonfira:matrix.org> |
<re_irc> <@angelonfira:matrix.org> error: linking with `arm-linux-gnueabihf-gcc` failed: exit status: 1
<re_irc> <@angelonfira:matrix.org> = note: "arm-linux-gnueabihf-gcc" "/home/forest/Documents/git/aidan-tree/target/armv7-unknown-linux-gnueabihf/release/deps/aidan_tree-8fca58edaf71a188.aidan_tree.70b7c687-cgu.0.rcgu.o" "/home/forest/Documents/git/aidan-tree/target/armv7-unknown-linux-gnueabihf/release/deps/aidan_tree-8fca58edaf71a188.aidan_tree.70b7c687-cgu.1.rcgu.o"...
<re_irc> ... "/home/forest/Documents/git/aidan-tree/target/armv7-unknown-linux-gnueabihf/release/deps/aidan_tree-8fca58edaf71a188.aidan_tree.70b7c687-cgu.2.rcgu.o" "/home/forest/Documents/git/aidan-tree/target/armv7-unknown-linux-gnueabihf/release/deps/aidan_tree-8fca58edaf71a188.aidan_tree.70b7c687-cgu.3.rcgu.o"...
<re_irc> <@dirbaio:matrix.org> aw
<re_irc> <@angelonfira:matrix.org> So I guess I need to get the linker properly now
<re_irc> <@dirbaio:matrix.org> even if you install arm-linux-gnueabihf tools, you still need a sysroot
<re_irc> <@dirbaio:matrix.org> setting that up manually is a pain
<re_irc> <@dirbaio:matrix.org> just use https://github.com/rust-embedded/cross
<re_irc> <@k900:0upti.me> Also an option
<re_irc> <@angelonfira:matrix.org> Oooh this looks cool
<re_irc> <@dirbaio:matrix.org> `cargo build --target` usually Just Works but for only "pure rust" crates
<re_irc> <@dirbaio:matrix.org> and spidev uses nix/libc which uses C
<re_irc> <@dirbaio:matrix.org> so at that point I always give up and use `cross` lol
<re_irc> <@angelonfira:matrix.org> WOW this is cool!
<re_irc> <@angelonfira:matrix.org> Binary created, testing now
<re_irc> <@angelonfira:matrix.org> IT WORKS!!!!
<re_irc> <@angelonfira:matrix.org> Trying some fun stuff now
<re_irc> <@angelonfira:matrix.org> Thanks for the help <3
<re_irc> <@k900:0upti.me> What was the right SPI configuration?
<re_irc> <@angelonfira:matrix.org> I think so
<re_irc> <@k900:0upti.me> No I mean like
<re_irc> <@k900:0upti.me> What _was_ it
<re_irc> <@angelonfira:matrix.org> I made it 0
<re_irc> <@angelonfira:matrix.org> And it didn't *not* work I think
<re_irc> <@k900:0upti.me> That's a good sign
tokomak has joined #rust-embedded
smach has quit [Read error: Connection reset by peer]
<re_irc> <@angelonfira:matrix.org> I'm visualizing it with Nannou
<re_irc> <@dirbaio:matrix.org> wow, that's *big*!