ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
DepthDeluxe has quit [Quit: Leaving]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
<re_irc> < (@omar_u8:matrix.org)> Im experimenting with calling C from Rust and vice versa. In calling C from Rust, things are more or less direct. However, calling Rust from C is presenting a bit of a challenge especially with regards to types and the singleton pattern. For example, if I were to create a simple function in Rust that toggles a pin, a function parameter would need to be a (configured) GPIO peripheral type. As such, in...
<re_irc> ... calling the function in C, I would need to pass a peripheral as an argument. My question is, what would a non-primitive type like a peripheral type translate into in C?
<re_irc> < (@omar_u8:matrix.org)> I'm experimenting with calling C from Rust and vice versa. In calling C from Rust, I've found things to be more or less direct. However, calling Rust from C is presenting a bit of a challenge especially with regards to types and the singleton pattern. For example, if I were to create a simple function in Rust that toggles a pin, a function parameter would need to be a (configured) GPIO peripheral type....
<re_irc> ... As such, in calling the function in C, I would need to pass a peripheral as an argument. My question is, what would a non-primitive type like a peripheral type translate into in C?
id_tam has quit [Quit: Reconnect.]
<re_irc> < (@kaspar:schleiser.de)> : If C just needs a reference ("void gpio_toggle(struct gpio_pin *pin )"), if "gpio_toggle()" is an "extern "C" fn gpio_toggle(...)", from the C side, the gpio pin struct can be anonymous: "struct gpio_pin; void gpio_toggle(struct gpio_pin *pin); void main() { struct gpio_pin *pin = gpio_getpin(); gpio_toggle(pin); } ..."
<re_irc> <Félix | Totem> There is an endpoint defined as "alloc.interrupt(max_packet_size /* 8 */, 10)", but when I try do write in it (in a loop until it succeeds), it keeps returning "UsbError::WouldBlock". What can be the cause of this error? I think I poll correctly the USB: "usb_device.poll(&mut [usb_class])", so it should work correctly.
<re_irc> < (@omar_u8:matrix.org)> : I'll give it a shot. Thanks!
IlPalazzo-ojiisa has joined #rust-embedded
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
steew has quit [Remote host closed the connection]
steew has joined #rust-embedded
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc> <riskable> What's the latest & greatest chip that works with Rust and has excellent Bluetooth support? As in, I want to make keyboards, mice, and game controllers using it.
<re_irc> < (@chemicstry:matrix.org)> Félix | Totem: do you poll usb during your endpoint write loop? It could have a packet queued but will never transmit until you poll it
<re_irc> < (@dirbaio:matrix.org)> riskable: nrf52!
<re_irc> <Ralph> to my surprise i didn't find a description of the different abstraction levels (none / PAC / HAL / BSP) in the rust embedded documentation (book, Embedonomicon, etc.). did i just miss it or is this something which is truly missing? and if so: why?
<re_irc> i think it'd be nice if there'd be a simple listing of these different abstraction layers, the ideas behind that and maybe - if possible - links to crates.io with the correct search criteria filled in to (hopefully) find the right crates?
<re_irc> <riskable> : Yeah that's what I'm currently looking at 👍
<re_irc> < (@dirbaio:matrix.org)> with the "nrf-softdevice" crate for bluetooth
<re_irc> < (@dirbaio:matrix.org)> avoid the nrf52832 if you can, it's full of unfunny erratas, the others are better
dc740 has quit [Remote host closed the connection]
<re_irc> < (@firefrommoonlight:matrix.org)> Ralph: I wrote this article to break that down - https://www.anyleaf.org/blog/rust-embedded-ecosystem-and-tools
<re_irc> < (@burrbull:matrix.org)> it should be described in embedded book, but has not be in embedonomicon
<re_irc> < (@adamgreig:matrix.org)> there's https://docs.rust-embedded.org/book/start/registers.html