05:28 <re_irc> <@rmja:matrix.org> Here are some thoughts on the new slice based api that limits some use cases for writing drivers for cc1101 and cc1200 rf transceivers:

05:28 <re_irc> <@rmja:matrix.org> 1. The new api removes the ability to have the sequence assert + read length byte n + read n bytes + deassert

05:29 <re_irc> <@rmja:matrix.org> 2. The wakeup from sleep sequence: assert + delay 2ms + query status byte deassert

06:31 <re_irc> <@codec_abc:matrix.org> : Thanks !

12:37 <re_irc> <@ithinuel:matrix.org> Not specificially embedded related but I figured someone here might know why this does not work: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b12d3ecc4b8d6e38fcebe188a1b5b19f

13:02 <re_irc> <@ryan-summers:matrix.org> My best guess is simply the argument type signature of `rest`

13:02 <re_irc> <@ithinuel:matrix.org> * https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b12d3ecc4b8d6e38fcebe188a1b5b19fEDIT: it turns out it works if I replace `tt` with `path`

13:03 <re_irc> <@ithinuel:matrix.org> Indeed, I usually use tt as a catch-all but it seems like it does not quite work there for some reasons.

13:03 <re_irc> <@ryan-summers:matrix.org> https://doc.rust-lang.org/rust-by-example/macros/variadics.html seems to indicate the variadic type is the same as the base type

13:10 <re_irc> <@ithinuel:matrix.org> Oh that might have been because ok the "matching delimiter" part of the rule that my previous usage of tt worked as intended

13:10 <re_irc> <@ithinuel:matrix.org> +(https://doc.rust-lang.org/reference/macros-by-example.html)

13:11 <re_irc> <@ithinuel:matrix.org> Since there's not delimiter pairs here, tt is only matching 1 single token and expect the comma to follow, not a :: token.

13:12 <re_irc> <@wassasin:matrix.org> : removing the comma from the "tt" span, and the comma at the end of the example https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=53e076390b15bff3f616c9572fe3f550

13:13 <re_irc> <@ithinuel:matrix.org> * no

13:13 <re_irc> <@ithinuel:matrix.org> Yes that makes sense too since the comma then is yet another token in whatever follows.

13:13 <re_irc> <@ithinuel:matrix.org> Thank you all!! I learnt something today :)

13:14 <re_irc> <@wassasin:matrix.org> And consumed in the first match yes

14:44 <re_irc> <@korken89:matrix.org> Did anyone figure out how to get defmt working again since it broke?

15:35 <re_irc> <@ithinuel:matrix.org> : when did it break? 😲

15:41 <re_irc> <@ithinuel:matrix.org> oh is it related to the recent changes in probe-rs? (like this issue (https://matrix.to/#/!zbjndUiYJDvhDRkPGw:matrix.org/$A9ERRkCyDA2UDKWzazugtmGEa2SbNKNYJfH8SsSwxAw?via=matrix.org&via=boiler.social&via=community.rs))

15:54 <re_irc> <@korken89:matrix.org> : No, they did a breaking wire format update and the working probe-run was yanked

15:56 <re_irc> <@korken89:matrix.org> Alright, there has been a new release :D

16:21 <re_irc> <@halfbit:matrix.org> Has infineon released some code for their psoc6 for rust?

16:22 <re_irc> <@halfbit:matrix.org> I saw a post saying it was supported

16:22 <re_irc> <@jamesmunns:beeper.com> I saw it mentioned here: https://www.infineon.com/cms/en/product/promopages/rust/

16:22 <re_irc> <@jamesmunns:beeper.com> > PSoC and AURIX TC4x support will follow in the second half of 2023

16:23 <re_irc> <@halfbit:matrix.org> yeah exactly but looking at github there wasn't much at github.com/infineon

16:23 <re_irc> <@jamesmunns:beeper.com> I think most of it is behind a "call us for evaluation kit" sort of barrier.

16:23 <re_irc> <@halfbit:matrix.org> right, I wonder how much of it will be rust wrappers around C code as well

16:24 <re_irc> <@jamesmunns:beeper.com> Dunno! If anyone gets access without an NDA, I'd love to hear more :D

16:24 <re_irc> <@halfbit:matrix.org> or blobs for things like the radio

16:39 <re_irc> <@vollbrecht:matrix.org> some infos are in the comment section from shahzeb who is marked as employee

16:39 <re_irc> quote :

16:39 <re_irc> " Since PSoC is an ARM device, the standard Rust Arm toolchain can be used but we haven't released the Peripheral Access Crates (PACs) yet. PSoC support is planned for later this year, our immediate focus is on TRAVEO and AURIX devices. Modus Toolbox support is also planned.

16:39 <re_irc> On MCUs i.e. Embedded Targets like PSoC or TRAVEO, mostly no_std is used, which means features like multithreading, vectors etc. are not available. There are options like RTIC available.

16:39 <re_irc> Additional references:

16:39 <re_irc> https://embeddedonlineconference.com/session/Safe_Rust_Multi_Core_Development_on_PSoC_Microcontrolle...

16:39 <re_irc> https://ferrous-systems.com/blog/embedded-concurrency-patterns/#cooperative-tasks-asyncawait

16:39 <re_irc> Some RTOSes/RTOS-like libraries are currently under development (e.g. OxidOS, Veecle NOS). Also, since Rust/C interop is possible, there are efforts underway to support Rust development on standard RTOSes like FreeRTOS.

16:39 <re_irc> For C to Rust conversion, there is C2Rust. But Rust/C interop is another option if you want to reuse C code in Rust. "

16:39 <re_irc> quote end

16:47 <re_irc> <@therealprof:matrix.org> I think I've seen SVD files for PSoC6 float around a long while ago so those shouldn't be a big issue for bare minimum support.

16:53 <re_irc> <@therealprof:matrix.org> Yepp, they're in here: https://github.com/Infineon/cmsis-packs/raw/master/PSoC6_DFP/Infineon.PSoC6_DFP.1.4.0.pack

16:56 <re_irc> <@therealprof:matrix.org> Interesting, they also exist for PSoC4... however the more interesting PSoC5 is still nowhere to be found...

17:11 <re_irc> <@halfbit:matrix.org> I'm not that familiar with the PSoC series other than the PSoC 6 ble part

17:16 <re_irc> <@therealprof:matrix.org> The interesting detail about the PSoC5 is that they have a rather flexible pinout routing and built-in UDB which allow to implement a lot of fancy functions in best CPLD manner directly in hardware.

17:17 <re_irc> <@halfbit:matrix.org> oh, I think this is the part that supports capsense pads?

17:17 <re_irc> <@halfbit:matrix.org> through the little bit of programmable logic on there, though psoc6 has something like flexcomm/flexio/pio doesn't it?

17:17 <re_irc> <@halfbit:matrix.org> could probably do something similar?

17:18 <re_irc> <@therealprof:matrix.org> Not sure really.

17:18 <re_irc> <@halfbit:matrix.org> quicklogic seems like it'd be nicer to work with if I needed like an M core + programmable logic part, could use the open tools and all that

17:25 <re_irc> <@therealprof:matrix.org> Well, I did play around a little bit with PSoC5 before I even knew Rust. UDB was a rather unique and interesting feature which got me hooked. Now we have the RP2040 with their SIO peripheral which allows to do similarly cool things but without the closedness of PSoC5...

21:13 <re_irc> = note: rust-lld: warning: section type mismatch for .uninit.rtic0

21:13 <re_irc> <@dngrs:matrix.org> trying out RTIC2 (with nightly, because TAIT), what fresh hell is this?

21:13 <re_irc> >>> /tmp/cargo/thumbv7em-none-eabihf/release/deps/f4_rtic2_ewgui-ed4b9595488210b5.f4_rtic2_ewgui.6d495053-cgu.0.rcgu.o:(.uninit.rtic0): SHT_PROGBITS

21:13 <re_irc> >>> output section .uninit: SHT_NOBITS

21:13 <re_irc> rust-lld: warning: section type mismatch for .uninit.rtic1

21:13 <re_irc> >>> /tmp/cargo/thumbv7em-none-eabihf/release/deps/f4_rtic2_ewgui-ed4b9595488210b5.f4_rtic2_ewgui.6d495053-cgu.0.rcgu.o:(.uninit.rtic1): SHT_PROGBITS

21:13 <re_irc> >>> output section .uninit: SHT_NOBITS

21:13 <re_irc> rust-lld: warning: section type mismatch for .uninit.defmt-rtt.BUFFER

21:13 <re_irc> >>> /tmp/cargo/thumbv7em-none-eabihf/release/deps/f4_rtic2_ewgui-ed4b9595488210b5.f4_rtic2_ewgui.6d495053-cgu.0.rcgu.o:(.uninit.defmt-rtt.BUFFER): SHT_PROGBITS

21:13 <re_irc> >>> output section .uninit: SHT_NOBITS

21:13 <re_irc> rust-lld: warning: section type mismatch for .got

21:13 <re_irc> >>> <internal>:(.got): SHT_PROGBITS

21:13 <re_irc> >>> output section .got: SHT_NOBITS

21:13 <re_irc> rust-lld: warning: section type mismatch for .got.plt

21:13 <re_irc> >>> <internal>:(.got.plt): SHT_PROGBITS

21:13 <re_irc> >>> output section .got: SHT_NOBITS

21:13 <re_irc> rust-lld: warning: section type mismatch for .got

21:13 <re_irc> >>> <internal>:(.got): SHT_PROGBITS

21:13 <re_irc> >>> output section .got: SHT_NOBITS

21:13 <re_irc> rust-lld: error: undefined symbol: _critical_section_1_0_acquire

21:13 <re_irc> >>> referenced by lib.rs:180 (/Users/ace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/critical-section-1.1.1/src/lib.rs:180)

21:13 <re_irc> >>> /tmp/cargo/thumbv7em-none-eabihf/release/deps/f4_rtic2_ewgui-ed4b9595488210b5.f4_rtic2_ewgui.6d495053-cgu.0.rcgu.o:(core::ptr::drop_in_place$LT$rtic_common..dropper..OnDrop$LT$rtic_time..TimerQueue$LT$rtic_monotonics..systick..Systick$GT$..delay_until..$u7b$$u7b$closure$u7d$$u7d$..$u7b$$u7b$closure$u7d$$u7d$$GT$$GT$::h9cd011a6d274373a)

21:14 <re_irc> >>> referenced by lib.rs:180 (/Users/ace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/critical-section-1.1.1/src/lib.rs:180)

21:14 <re_irc> >>> /tmp/cargo/thumbv7em-none-eabihf/release/deps/f4_rtic2_ewgui-ed4b9595488210b5.f4_rtic2_ewgui.6d495053-cgu.0.rcgu.o:(f4_rtic2_ewgui::app::__rtic_internal_async_0_prio_dispatcher::h054543b9644612bb)

21:14 <re_irc> >>> referenced by lib.rs:180 (/Users/ace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/critical-section-1.1.1/src/lib.rs:180)

21:14 <re_irc> >>> /tmp/cargo/thumbv7em-none-eabihf/release/deps/f4_rtic2_ewgui-ed4b9595488210b5.f4_rtic2_ewgui.6d495053-cgu.0.rcgu.o:(SysTick)

21:14 <re_irc> >>> referenced 1 more times

21:14 <re_irc> rust-lld: error: undefined symbol: _critical_section_1_0_release

21:14 <re_irc> >>> referenced by lib.rs:197 (/Users/ace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/critical-section-1.1.1/src/lib.rs:197)

21:14 <re_irc> >>> /tmp/cargo/thumbv7em-none-eabihf/release/deps/f4_rtic2_ewgui-ed4b9595488210b5.f4_rtic2_ewgui.6d495053-cgu.0.rcgu.o:(core::ptr::drop_in_place$LT$rtic_common..dropper..OnDrop$LT$rtic_time..TimerQueue$LT$rtic_monotonics..systick..Systick$GT$..delay_until..$u7b$$u7b$closure$u7d$$u7d$..$u7b$$u7b$closure$u7d$$u7d$$GT$$GT$::h9cd011a6d274373a)

21:14 <re_irc> >>> referenced by lib.rs:197 (/Users/ace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/critical-section-1.1.1/src/lib.rs:197)

21:14 <re_irc> >>> /tmp/cargo/thumbv7em-none-eabihf/release/deps/f4_rtic2_ewgui-ed4b9595488210b5.f4_rtic2_ewgui.6d495053-cgu.0.rcgu.o:(f4_rtic2_ewgui::app::__rtic_internal_async_0_prio_dispatcher::h054543b9644612bb)

21:14 <re_irc> >>> referenced by lib.rs:197 (/Users/ace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/critical-section-1.1.1/src/lib.rs:197)

21:14 <re_irc> >>> /tmp/cargo/thumbv7em-none-eabihf/release/deps/f4_rtic2_ewgui-ed4b9595488210b5.f4_rtic2_ewgui.6d495053-cgu.0.rcgu.o:(f4_rtic2_ewgui::app::__rtic_internal_async_0_prio_dispatcher::h054543b9644612bb)

21:14 <re_irc> >>> referenced 4 more times

21:14 <re_irc> flip-link: the native linker failed to link the program normally; please check your project configuration and linker scripts

21:14 <re_irc> <@dngrs:matrix.org> ah there's apparently a ferrous article (https://ferrous-systems.com/blog/defmt-rtt-linker-error/) on that, reading…

21:14 <re_irc> <@dngrs:matrix.org> oh it's the critical-section update

21:14 <re_irc> <@dngrs:matrix.org> never had to bother with that until now

21:15 <re_irc> <@dngrs:matrix.org> cool, fixed

23:56 <re_irc> <@dngrs:matrix.org> hm. How to best convert an "u32" into an "f32" in the range -1.0 .. 1.0? "n as f32 / (u32::MAX as f32 / 2.) - 1.0" works but I'm not sure about performance & precision