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
SunClonus has joined #rust-embedded
SunClonus has quit [Remote host closed the connection]
SunClonus has joined #rust-embedded
SunClonus has quit [Quit: Leaving]
SunClonus has joined #rust-embedded
Sea[m] has joined #rust-embedded
SunClonus has quit [Quit: Leaving]
<Ralph[m]> <M9names[m]> "That's not the real price though" <- it's the price shown to me by aliexpress because it'd be my first order there (classic "special price, just for you my friend!" experience 😄)
<Ralph[m]> <Sea[m]> "Greetings, talents!..." <- it'd be helpful if you could provide information on the location (if it's on-site) or remote-options so that people know whether this might be something for them
<Sea[m]> Ralph[m]: Yes, it is remote
<Sea[m]> * be working remotely on various
<thejpster[m]> <Sea[m]> "Yes, it is remote" <- Where do people go to learn more, and what’s the salary and compensation package like?
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
AdamHott[m] has joined #rust-embedded
<AdamHott[m]> I ordered what I thought was a cortex 10-pin debug connector cable, but I ordered the wrong cable. I'm sorry, can someone point me in the right direction of the correct part number on Mouse or DigiKey?
<AdamHott[m]> s/Mouse/Mouser/
<M9names[m]> can you give us a hint what we're connecting to just in case what you got was the right cable, but your target isn't the same?
<M9names[m]> this is what I expect you're talking about
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 255 seconds]
<M9names[m]> ^ this part is available at digikey if that's what you're after
<AdamHott[m]> thanks for responding! It's the rusty-probe, and I'm trying to connect it to the NRF52840-DK
<AdamHott[m]> M9names[m]: I ordered this one, but it's too big
marmrt[m] has joined #rust-embedded
<marmrt[m]> 1.27mm pitch is too big?
<AdamHott[m]> It's the width of the connector, the pins on the rusty-probe and the NRF52840 are more of a square, the cable I got has a rectangular shape for the headers
<AdamHott[m]> marmrt[m]: It seems like it, but I'm not sure
<marmrt[m]> The header used on rusty-probe is 1.27mm pitch, so the linked connector should work
<marmrt[m]> s/connector/cable/
<M9names[m]> that looks right. the cable connector is wider than the pins.
<marmrt[m]> that's a 2.00mm pitch connector
<marmrt[m]> for forbidden metric pin headers
<M9names[m]> oof
<AdamHott[m]> ah gotcha, so the 1.27" pitch is what I need right, the one linked?
<barnabyw[m]> 1.27mm, not inches! but yes
<AdamHott[m]> ah ok thanks all!
<JamesMunns[m]> 1.27mm/0.05" pitch
<AdamHott[m]> that matches this one: https://www.sparkfun.com/products/15364
<AdamHott[m]> looks like I'll place an order for this later today.
IlPalazzo-ojiisa has joined #rust-embedded
Guest7282 has joined #rust-embedded
<AdamHott[m]> The Board Support Package for the Raspberry Pi Pico, should that also work for the Pico W (wifi capabilities)? Here is the process I believe I should follow: https://github.com/rp-rs/rp-hal-boards/tree/main/boards/rp-pico
<AdamHott[m]> Is that correct?
<M9names[m]> If you want wifi on pico-w, use embassy-rp
<AdamHott[m]> If I want to test without wifi for now, will that Board Support Package work for a simple test on the pico w?
<dirbaio[m]> the Pico has almost nothing on the board
<dirbaio[m]> so the BSP does almost nothing
<dirbaio[m]> the only relevant thing it does is rename "Gpio25" to "led", because that's the pin the LED is on
<dirbaio[m]> but on the Pico W the LED is not connected to GP25, it's connected to the wifi chip
<dirbaio[m]> so the one feature the BSP has will not work
<dirbaio[m]> just use the HAL directly, you don't need a BSP. Either embassy-rp or rp2040-hal
<dirbaio[m]> but you need the wifi driver to blink the LED on the board
<michaeldesilva[m> <dirbaio[m]> "1000005838.jpg" <- Wow. I spy
<michaeldesilva[m> * I spy UniFi... sweet setup. Have you shared how you manage that? Using a hypervisor or...?
<AdamHott[m]> <dirbaio[m]> "but you need the wifi driver..." <- thanks so much!
cr1901_ is now known as cr1901
Guest7282 has left #rust-embedded [Error from remote client]
jannic[m] has joined #rust-embedded
<jannic[m]> <dirbaio[m]> "so the one feature the BSP has..." <- Well IMHO the most important feature of the rp-pico BSP is including the BOOT2_FIRMWARE. That can be tricky especially for beginners as it involves some linker attributes, and getting it wrong doesn't cause a compiler error but silently produces a broken firmware image.
<jannic[m]> But other than that, I agree, the BSP is of little value and it's easy to use the HAL directly.
Guest7282 has joined #rust-embedded
<JamesMunns[m]> is there a reason this is a "BSP thing" and not a "HAL thing", like it is in embassy-rp?
<JamesMunns[m]> (not judging, just wondering).
<JamesMunns[m]> It is a little subtle - embassy-rp achieves it by one line of the `build-rs` you are expected to copy + paste into your project
<explodingwaffle1> iirc boot2 can depend on the qspi flash used, which is board specific
<jannic[m]> I think both are valid choices. With the embassy approach, I don't see what you need to do if you want a custom boot2 image. But I probably miss something obvious. And personally I consider the feature selection more complicated than selecting the BSP.
<jannic[m]> But the expectation that every board needs a BSP doesn't make sense. It's of very little use, and just doesn't scale. Look at the number of boards in https://github.com/rp-rs/rp-hal-boards/.
Guest7282 has left #rust-embedded [Error from remote client]
cajt[m] has joined #rust-embedded
<cajt[m]> <thejpster[m]> "Where do people go to learn more..." <- What is competetive pay for remote work anyways? A timezone, or legislative context might help.
Guest7282 has joined #rust-embedded
Guest7282 has left #rust-embedded [Disconnected: Replaced by new connection]
Ranhir has joined #rust-embedded
PauCarrCardona[m has joined #rust-embedded
<PauCarrCardona[m> Hello, I was wondering if anybody would be able to recommend me a fast serialization library that works on rust for ESP32 ( ideally with low memory consumption )
mali[m] has joined #rust-embedded
<mali[m]> <PauCarrCardona[m> "Hello, I was wondering if..." <- I would recommend postcard.
<jannic[m]> <explodingwaffle1> "microbit uses the leds in the..." <- Indeed! That's a nice trick.
<mali[m]> Ping James Munns
<JamesMunns[m]> Pong mali ⚡️
<dirbaio[m]> most useful pings ever
<mali[m]> I wasn't actually expecting a millisecond response. 😳
ello has quit [Read error: Connection reset by peer]
ello has joined #rust-embedded
<JamesMunns[m]> Yeah but I have notifications for mentions on my phone and I'd like to keep them enabled for when someone really needs help, which is why I get grumpy about tagging sometimes.
<thejpster[m]> maybe we could have a matrix bot that chats to people new to the room and lets them know the rules?
<thejpster[m]> I think the Arm Discord (ugh) does this.
ChristofPetig[m] has joined #rust-embedded
<ChristofPetig[m]> Dan Gohman just created a proposal for a PWM WIT interface (WebAssembly interface types) modeled after e-hal at https://github.com/sunfishcode/hello-embedded/issues/2. I remembered that there was some specific need for `fully_on` and `fully_off` as zero and max duty cycle don't necessarily include both fully variants.
<ChristofPetig[m]> The STM implementation in embassy seems to not need these variants, so I wonder if someone still has a link or hint to the original problem solved by fully_on, or can confirm that now indeed set_duty_cycle alone would be sufficient.
<dirbaio[m]> t"duty=0 is fully off, duty=max is fully on"
<dirbaio[m]> s/t/it's not needed because you can always specify /
<dirbaio[m]> and if the chip doesn't work like that, the implementations can always adapt with ifs
<dirbaio[m]> for example if a hardware PWM is 8bit (0..255) and duty is d/256, you get "0=fully off" for free, but 255 is not fully on
<dirbaio[m]> but the impl can always set max = 256 (instead of 255) and then do an if to do something else to do fully on when the user does set_duty(256)
<dirbaio[m]> so specifying the API this way is the simplest, and it can work for all hardware
<dirbaio[m]> (embedded-hal does have helper methods for fully_on, fully_of, but these are just helpers, which call set_duty with 0 or max)
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]> fun fact: the 16 bit stm timers don't need to have a special case like that as long as the max duty isn't u16::MAX + 1, which the e-h trait doesn't support anyways
dreamcat4 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Ping timeout: 256 seconds]