06:12 <ian_rees[m]> I'm working on updating a crate that uses timer::Periodic from embedded-hal 0.2 - that seems to not be present in embedded-hal 1.0, is there a recommended replacement?

06:12 <ian_rees[m]> * I'm working on updating a crate that uses timer::Periodic from embedded-hal 0.2, to use embedded-hal 1.0 . The timer module seems to not be present in embedded-hal 1.0, is there a recommended replacement?

06:38 <M9names[m]> there is no replacement

06:51 <ian_rees[m]> aha, [DelayNs](https://docs.rs/embedded-hal/latest/embedded_hal/delay/trait.DelayNs.html) looks like it'll work for this purpose

09:59 <thejpster[m]> > Future processor designers can view the unedited commit history for Hazard3 and learn from Luke’s development process, including his mistakes and how he corrected them. Students studying processor design can develop and test software workloads on RP2350, then look at the Hazard3 source, modify the processor to include their own custom instructions, then test their new version on an FPGA.

09:59 <thejpster[m]> https://embeddedcomputing.com/technology/open-source/risc-v-open-source-ip/raspberry-pi-launches-new-rp2350-mcu-and-pico-2-dev-board-with-risc-v-support

09:59 <thejpster[m]> That’s a very good point. You can now buy silicon, run some code on it, and then look at the actual Verilog that just executed your instructions. You can’t change the Verilog, sure, but that’s a hell of a lot cheaper and quicker to get going than an FPGA set-up if you’re just getting started.

11:01 <whitequark[cis]> i think one of the first chips that enabled this was Propeller

11:03 <whitequark[cis]> there's been a few early OR32 implementations, but i don't think you could (easily or at all) buy silicon with any of them and run stuff on it

11:03 <whitequark[cis]> RP2350 is certainly one of the most accessible ones, probably more so than SiFive's?

11:39 <thejpster[m]> Is there an FPGA framework with Hazard3 as a CPU option? I don't know what the cool kids are playing with - I've only heard of LiteX.

11:41 <thejpster[m]> I wonder how it compares to VexRiscv or Picovr32

11:50 <whitequark[cis]> not that i know personally

11:51 <whitequark[cis]> i'm (obviously) using Amaranth, though i haven't personally integrated Hazard3 into it

12:08 <thejpster[m]> ah, of course. Heard of it but haven't used it.

12:08 <thejpster[m]> /me looks at pile of FPGA dev boards

13:47 <whitequark[cis]> we have a nice manual now! not quite on the level of the Rust book but i put a lot of effort into it

13:47 <whitequark[cis]> https://amaranth-lang.org/docs/amaranth/latest/guide.html this is the language guide

13:48 <whitequark[cis]> it works well when combined with the playground https://amaranth-lang.org/play/

13:48 <whitequark[cis]> and then when you want to use it together with a physical board, the I/O primitives are documented here https://amaranth-lang.org/docs/amaranth/latest/stdlib/io.html

13:49 <whitequark[cis]> for everything else just ask on #amaranth-lang:matrix.org

13:50 <whitequark[cis]> in general (this is not restricted to Amaranth, applies to learning any HDL) i would recommend starting with the simulator, which the Amaranth playground makes single-click easy

13:50 <whitequark[cis]> you can even do printf debugging if you want! m.d.sync += Print(x, y, Format("{:08b}", z)) is a valid statement

13:52 <whitequark[cis]> the parts of the system that are the least documented right now are the boundary between your code and the external world, so if you're confused about anything at all there just ask. almost everything else should be covered by at least one type of docs, though we strive for having guide-level and reference-level docs for every concept

15:52 <andar1an[m]> Anyone mess with Nordic NRF chips? Do you enjoy?

15:57 <JamesMunns[m]> They're probably some of the most widely used chips in embedded rust

15:57 <JamesMunns[m]> Also some of the nicest to work in (relatively few complex gotchas), IMO.

15:58 <andar1an[m]> I like the indoor positioning and more recent Bluetooth

15:58 <andar1an[m]> Is there anything similar to meshtastic written in Rust?

15:58 <JamesMunns[m]> embassy-nrf has relatively complete support for the whole nrf52 family, I know some folks are actively using the nrf91 family, I think the 53 and 54 series have some support, but I'm less familiar

15:59 <JamesMunns[m]> Not sure what meshtastic is, but im pretty sure the nrf-softdevice crate supports ble mesh

16:00 <andar1an[m]> Firmware for loRa device p2p networks

16:00 <andar1an[m]> I guess software too

16:00 <andar1an[m]> If you have seen the H1 or R1 LoRa devices they run meshtastic

16:01 <andar1an[m]> https://muzi.works/

16:01 <JamesMunns[m]> There's the lora-rs stuff for Lora, unsure how much coverage there is for p2p Lora vs lorawan

16:01 <JamesMunns[m]> https://github.com/lora-rs/lora-rs

16:01 <andar1an[m]> I only learned about meshtastic today, so I am not sure what their guts are

16:02 <andar1an[m]> But there are esp32 and nordic Rok boards

16:02 <mameluc[m]> lora p2p works but no mesh stuff afaik

16:02 <JamesMunns[m]> Mameluc knows much more than I do about Lora stuff :)

16:03 <andar1an[m]> ❤️ LoRa, especially in a more uncertain world.

16:03 <andar1an[m]> Wish this existed camping when I was younger haha

16:04 <mameluc[m]> Rust LoRa/LoRaWAN 🔌

16:04 <andar1an[m]> https://meshtastic.org/docs/hardware/devices/

16:06 <JamesMunns[m]> You're *probably* less likely to find "whole board support" in a single project, but very likely to find support for the MCU and radio for a given board, which is a huge part of the job done.

16:07 <andar1an[m]> I don't have time or money to tinker yet. Just got excited learning

16:09 <andar1an[m]> General first thought is "can I use a Rust crate" lol

19:08 <takkaryx[m]> question. I'm noticing I keep trying to fall back to patterns I'm used to in C when attempting to do Rust things, for example, Initialize a peripheral in it's module, but then have a global struct that is then accessed to get information from that peripheral. something like an RTC.

19:08 <takkaryx[m]> ATM I noticed I'm trying to generate a static variable to hold the RTC peripheral that I can then pull time out of, but that seems,,, un-rust like? but at the same time, It seems silly that I would instead need to pass the reference to the peripheral or wrapper trait to every module/function that needs the RTC, since it's a global thing.

19:08 <takkaryx[m]> Is there somewhere I could look for examples, or does anyone have some thoughts on better ways to do this?

19:09 <ryan-summers[m]> takkaryx[m]: > <@takkaryx:matrix.org> question. I'm noticing I keep trying to fall back to patterns I'm used to in C when attempting to do Rust things, for example, Initialize a peripheral in it's module, but then have a global struct that is then accessed to get information from that peripheral. something like an RTC.... (full message at

19:09 <ryan-summers[m]> <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hnlycXDDagWYYLiwUusshjnF>)

19:10 <takkaryx[m]> so, I'm using embassy with async tasks, but the RTC is just a clock that's already running it's own counter, having an async task own a counter ticking seems silly..

19:10 <ryan-summers[m]> But what I usually do:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/qLHyooYoCMkYLqXKYyZGFJUb>)

19:11 <ryan-summers[m]> For an example of what I mean, this is the general pattern: https://docs.rs/embedded-nal/latest/embedded_nal/struct.SharableStack.html

19:12 <takkaryx[m]> awesome, I'll take a look, thanks for your input!

19:12 <EthanGardner[m]> Are there any simple bldc 6 step trapezoidal commutation libraries

19:14 <ryan-summers[m]> Yeah the general idea I like is to keep it as a true singleton in some global *Cell and create things that reference said singleton via synchronization primitives (i.e. mutexes)

19:16 <takkaryx[m]> yea, I was thinking to do something like a static_cell, or a singleton, so I could control access, but static_cell seems incorrect?

19:18 <JamesMunns[m]> <EthanGardner[m]> "Are there any simple bldc 6 step..." <- https://docs.rs/ramp-maker/latest/ramp_maker/ does the ramp profile calculation, but doesn't do commutation

19:20 <JamesMunns[m]> Ah that may not help for non-step based drivers? I guess you need more "speed at regular intervals" than "delta t between discrete steps"

19:20 <JamesMunns[m]> (I've used it for stepper motors, but not for BLDC motors)

19:21 <EthanGardner[m]> Thanks i'll take a look, was hoping there would be an off the shelf BLDC lib. The main thing i need is to control the commutation speed (ESC) using PWM or even just manipulating the GPIO's for now

23:05 <NeMo[m]> Hi,

23:05 <NeMo[m]> is there a way to get a crate which uses `rp2040-hal` & `rp2040-pac` working in an embassy-rp environment?

23:05 <NeMo[m]> I’m wanting to use the `hub75_pio` crate, and use embassy for tasks / WiFi / BLE. Since that crate uses DMA & PIO to drive the display it’s coupled with its hal & pac more so than regular embedded_graphics drivers

23:18 <M9names[m]> you'll need to port the driver