02:06 <re_irc> < (@bradleyharden:matrix.org)> I'm seeing some strange behavior that I don't know what to make of. I'm using the "seq" and "paste" proc macros in our HAL, and I can successfully build it. But when I change to one of our BSP crates, which has the HAL as a "path" dependency, building fails with an error in the proc macros. As far as I can tell, I'm using the same features, settings, etc. when building from the BSP crate vs. the...

02:07 <re_irc> ... HAL directly. I can't figure out why it would fail in one place but not the other.

02:07 <re_irc> < (@bradleyharden:matrix.org)> Has anyone ever seen anything like this?

02:18 <re_irc> < (@bradleyharden:matrix.org)> Ah, never mind. I figured it out. The BSP crate was locked to an older version of "paste"

04:48 <re_irc> < (@nihal.pasham:matrix.org)> Just some info (and a note of appreciation). "Fridays with Rust" turned out to be an effective tool to promote "Rust" adoption at work. We managed to put together our first live-stream here (https://youtu.be/KtkEGfWoUQo?t=3929). Hoping this becomes a permanent thing. Appreciate all the support andre-richter - thank you.

04:51 <re_irc> < (@nihal.pasham:matrix.org)> PS: its a bit unstructured but the video is time-coded, "Rust" part is towards the end.

05:22 <re_irc> < (@russruss:matrix.org)> hello, I'm trying to upgrade an rtic 0.5 project to 1.0. I'm following the guide (https://rtic.rs/1/book/en/migration/migration_v5.html) but I'm not understanding the new scheme for "monotonic". I was using "monotonic = rtic::cyccnt::CYCCNT" in 0.5. Is this the same as

05:22 <re_irc> #[monotonic(binds = SysTick, default = true)]

05:22 <re_irc> In 1.0?

05:22 <re_irc> type MyMono = DwtSystick<{ SYSCLK_FREQ_HZ }>;

05:50 <re_irc> < (@burrbull:matrix.org)> You need to use timer which implements rtic Monotonic https://crates.io/search?q=rtic%20monotonic

05:54 <re_irc> < (@burrbull:matrix.org)> there is also rtic room https://matrix.to/#/#rtic:matrix.org

08:39 <re_irc> <derk1> anyone from sweden here? looking to put together a talk or workshop around rust on embedded

09:35 <re_irc> < (@fragadaleta:matrix.org)> if i have a board that collects sensor data, processes them and has to make such data available to a client, what wired communication is adviced between UART and I2C ?

09:41 <re_irc> <andre-richter> : thanks. Quite the high quality recording you got there, nice 👍

09:58 <re_irc> < (@nihal.pasham:matrix.org)> andre-richter: a smartphone is all we need (I guess) 😅. But we're getting mixed observations with the audio (hope you didn't hear any reverb).

10:03 <re_irc> < (@nihal.pasham:matrix.org)> -But we're getting mixed observations with the audio (hope you didn't hear any reverb).

10:08 <re_irc> < (@korken89:matrix.org)> Has anyone here tried the CH32Vxx RISC-V MCUs with Rust? If so what was your experience?

10:10 <re_irc> < (@korken89:matrix.org)> It's finally RISC-V MCUs with sane interrupt controller so I'm thinking about RTIC support for them

10:21 <re_irc> < (@9names:matrix.org)> I think there's a bunch of different CH32V families, do they all have the same interrupt controller?

10:24 <re_irc> < (@korken89:matrix.org)> Indeed

10:24 <re_irc> < (@korken89:matrix.org)> Or, they have the features needed for RTIC to work at full efficiency

10:25 <re_irc> < (@korken89:matrix.org)> There are some minor differences from what I can see when comparing the different MCU families, but even the smallest CH32V003 has a good interrupt controller

10:25 <re_irc> < (@korken89:matrix.org)> Just a bit unfortunate that they run their own proprietary interface for the debug port...

10:26 <re_irc> < (@xiretza:xiretza.xyz)> not even JTAG?

10:26 <re_irc> < (@korken89:matrix.org)> For the V003 it's some 1-wire protocol, for the larger ones the names are the same as for SWD but it's more like I2C

10:26 <re_irc> < (@korken89:matrix.org)> +(SWDIO/SWCLK)

10:27 <re_irc> < (@korken89:matrix.org)> Some reverse engineering has been done on the SWD-like stuff https://github.com/fxsheep/openocd_wchlink-rv/wiki/WCH-RVSWD-protocol

10:27 <re_irc> < (@korken89:matrix.org)> I did not find anything for the V003 yet of reverse engineering

10:28 <re_irc> < (@korken89:matrix.org)> Would be nice to add support for these 2 protocols to the rusty probe in the end :)

10:29 <re_irc> < (@9names:matrix.org)> i love how people calls their debug interface "one wire" when it has two because so many people call SWD "single-wire debug"

10:29 <re_irc> < (@korken89:matrix.org)> There is effort happening from what I can see though, so it's only a matter of time

10:29 <re_irc> < (@korken89:matrix.org)> The V003 has a single wire though :)

10:29 <re_irc> < (@korken89:matrix.org)> They call it 1-wire SWD

10:30 <re_irc> < (@korken89:matrix.org)> It's probably only their SWD protocol over 1-wire

10:30 <re_irc> < (@korken89:matrix.org)> Or so would be my guess :P

10:31 <re_irc> < (@korken89:matrix.org)> I need to get hold of some devboards :D

10:34 <re_irc> < (@9names:matrix.org)> ah they actually made theirs with only 1 signalling pin. impressive.

10:35 <re_irc> < (@korken89:matrix.org)> Yeah, quite smart IMO for really small stuff

10:35 <re_irc> < (@korken89:matrix.org)> As long as the protocol becomes open or reverse engineered I'm fine with it

10:36 <re_irc> < (@korken89:matrix.org)> Will probably be a bit slow, but I'd love to see how much "defmt" logging one can push over that :)

10:42 <re_irc> < (@9names:matrix.org)> i have a ch573f but they use a 2-wire debug interface, not sure if it's related at all to the v003 debug interface.

10:42 <re_irc> was planning on dumping the comms to see how complex it was but i don't know if it's related to the 1-wire one...

10:42 <re_irc> < (@9names:matrix.org)> guess it's still useful anyway

10:43 <re_irc> < (@9names:matrix.org)> kinda sad that SWD is proprietary, everyone just inventing their own debug interface to avoid dealing with cjtag :(

10:58 <re_irc> < (@9names:matrix.org)> https://psion.agg.io/_matrix/media/r0/download/matrix.org/iaCIVUKXaUfSMbNVhAQUrUkh/image.png

10:59 <re_irc> < (@9names:matrix.org)> i do love aliexpress translations

11:15 <re_irc> < (@korken89:matrix.org)> Indeed

12:28 <re_irc> < (@9names:matrix.org)> oh, reading the manual ch32v003 is RV32E. can't target that from rust, and since LLVM support isn't upstreamed yet you might be waiting a while.

12:39 <re_irc> < (@korken89:matrix.org)> Aw that's unfortunate

12:39 <re_irc> < (@korken89:matrix.org)> E, that I've never heard of I/M/A/C is the normal stuff

12:40 <re_irc> < (@9names:matrix.org)> I is the standard base ISA, E has half the number of registers

12:40 <re_irc> < (@korken89:matrix.org)> Right, an RV32I with less regs

12:41 <re_irc> < (@korken89:matrix.org)> Hope it comes as well to llvm :)

12:43 <re_irc> < (@korken89:matrix.org)> Nice, the larger ones are IMAC at least

12:47 <re_irc> < (@9names:matrix.org)> yes, they look like they're all IMAC. i think you want one with a RISC-V4A core, doesn't look like RISC-V3A has a vectored interrupt controller.

12:47 <re_irc> I guess those must be older if the RISC-V2 core from ch32v003 has the vectored mode.

12:47 <re_irc> < (@9names:matrix.org)> * RISC-V2a

13:36 <re_irc> < (@korken89:matrix.org)> Yeah, quite nice for such a small core

13:36 <re_irc> < (@korken89:matrix.org)> Even has the equivalent of BASEPRI in Cortex-M

13:37 <re_irc> < (@korken89:matrix.org)> I just hope all future RISC-V have the CLIC as interrupt controller

13:38 <re_irc> < (@korken89:matrix.org)> Then we won't need a custom "backend" for RTICs codegen per MCU

13:39 <re_irc> < (@korken89:matrix.org)> It's also more or less an NVIC copy, so we're happy

13:39 <re_irc> < (@korken89:matrix.org)> https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc

13:40 <re_irc> < (@chrysn:matrix.org)> : That's a pity, given that it looks like a convenient thing to implement on a chip (and on a softcore, hello picorv32). But at least it looks like things can progress in LLVM now that -e has been ratified.

13:41 <re_irc> < (@korken89:matrix.org)> There was an issue with -e before?

13:41 <re_irc> < (@korken89:matrix.org)> Or just "unused"?

13:43 <re_irc> < (@chrysn:matrix.org)> Apparently unsupported in LLVM, see https://reviews.llvm.org/D70401#3948829

13:43 <re_irc> (Or it's _not_ ratified yet ... don't know their precise procedures, but apparently things are in motion)

13:49 <re_irc> < (@korken89:matrix.org)> It's at least up for discussion :)

14:01 <re_irc> < (@korken89:matrix.org)> Btw is there any riscv room?

14:11 <re_irc> < (@9names:matrix.org)> Not really. The ewg riscv folks have historically been in #gd32v-rust:matrix.org (https://matrix.to/#/#gd32v-rust:matrix.org)

14:31 <re_irc> < (@korken89:matrix.org)> Okey!

17:00 <re_irc> < (@markfarnan:matrix.org)> Random high level Q (That I also asked the ESP32 folks), Starting to get into Rust for embeded seriously with a hobby project for the marine environment. I have a number of ESP32 boards, but also considering ST32 again, now chip's seem to becoming more available.

17:00 <re_irc> The project is IoT based in the marine environment. (Sensors etc, ) CAN (NEMA 2000), along with Wifi or bluetooth for Comms.

17:00 <re_irc> As a general guideline would folks recommend heading down std. or no_std path, and any good recommendations for base OS (Embassy and RTIC look interesting) ?

17:00 <re_irc> I'm not new to embeded, but am new to embeded Rust and Rust in general.

17:04 <re_irc> < (@korken89:matrix.org)> Both are good and used a lot

17:05 <re_irc> < (@korken89:matrix.org)> A bit different philosophy behind them