<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
<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
<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]