03:51 <andrewmorrow[m]> Has anyone used the USART on a SAMD in synchronous mode before? I've written a very simple driver to try to read scan codes from a PS/2 keyboard, but when the uC boots, it reads garbled scan codes off the USART until you've pressed 4 or 5 different keys (not the same key 4 or 5 times!) and then it begins reading correct data

03:51 <andrewmorrow[m]> I'm very confused because I can watch the bus with a scope and see that the scan codes coming off the keyboard are always correct, so I have no idea why the USART reads garbage until it's seen a sufficient variety of input bytes

03:52 <andrewmorrow[m]> pressing and releasing Q send 0x15, 0xF0, 0x15 on the bus, but the SAMD USART reads 0x21, 0xbf, 0xa1 every single time after reboot until I press a few different keys. Then it begins reading the correct values

05:16 <andrewmorrow[m]> I cross-posted to the atsamd-rs channel too but think I figured it out: you have to set the expected baud rate, even when running in synchronous mode with an external clock, or else the uC struggles to synchronize the clock input, which is bizarre but I guess a function of the oversampling

07:29 <therealprof[m]> <andrewmorrow[m]> "I cross-posted to the atsamd-..." <- I only read your post right now but if anything doesn't work as expected in SAMD, always check the clocks... I've had the weirdest problems in completely unrelated areas because I forgot to wait for the PLL lock on somewhere.

08:34 <sourcebox[m]> James Munns: There's "Digitone's Digitakt 2" on your users list, I have serious doubts on that. Also, it would have to be "Elektron Digitakt 2".

08:35 <sourcebox[m]> Yes, Elektron has had job offerings for Rust for years now, but I'm not aware that products using it are already out.

08:40 <JamesMunns[m]> Yeah, the citation for that was a Reddit post, so no official confirmation

08:40 <sourcebox[m]> The "Digitakt 2" is an evolution of the original "Digitakt", which is AFAIK a Coldfire design.

08:41 <JamesMunns[m]> I think some folks were saying that the Digitakt 2 was a new hardware platform?

08:42 <sourcebox[m]> It's not completely impossible that they replaced the platform, but I would really get that confirmed somehow.

08:42 <JamesMunns[m]> https://www.elektronauts.com/t/digitakt-ii-teardown/212476/23?page=2

08:42 <JamesMunns[m]> Seems to still be Coldfire and a SHARC DSP

08:43 <sourcebox[m]> Look at the 2 units: https://www.amazona.de/wp-content/uploads/2029/01/elektron-digitakt-i-vs-digitak-ii.jpg

08:43 <JamesMunns[m]> I mean you can change a lot of electronics and keep the same case design 😃

08:44 <sourcebox[m]> As a vendor, I would not do that for several reasons.

08:45 <JamesMunns[m]> But yeah still looks like coldfire: https://www.elektronauts.com/t/digitakt-ii-pcb/212504

08:45 <sourcebox[m]> But if you like to put synths on the list that use Rust, there are 2 I'm aware of.

08:46 <sourcebox[m]> https://supercriticalsynthesizers.com/redshift6/

08:46 <sourcebox[m]> There's one of the devs on the RustAudio discord who confirmed that.

08:47 <sourcebox[m]> https://www.tastychips.nl/product/gr-mega-granular-workstation-black/

08:48 <sourcebox[m]> I had an email conversation with one of the devs and also it was mentioned in a video some time ago.

09:25 <M9names[m]> <sourcebox[m]> "As a vendor, I would not do that..." <- What's worse, this or changing part number with a like-for-like replacement?

10:31 <sourcebox[m]> <M9names[m]> "What's worse, this or changing..." <- There's a good amount of business and maintainance issues to consider.

10:32 <sourcebox[m]> E.g. Elektron is known for having a very long support period for firmware updates with backporting new features.

10:37 <sourcebox[m]> When you do an mk2 version, you always have to estimate the market for it because a lot of users will not upgrade as they are satisfied with the original. So doing a complete redesign can be a risk.

10:38 <thejpster[m]> you all REALLY didn't like running QEMU on Windows, so...

10:38 <thejpster[m]> https://github.com/rust-embedded/cortex-ar/pull/23/commits/0963873a4286f63e1e8ed02ff7e18ee786dc43e7

10:48 <JamesMunns[m]> Published my "Embedded Rust in Production" article: https://onevariable.com/blog/embedded-rust-production/

10:48 <JamesMunns[m]> (cc @thejpster!)

10:58 <JamesMunns[m]> Posted on LinkedIn and Reddit, we'll see if I get a bunch of "yes and"s or "well actually"s :D

11:01 <JamesMunns[m]> * and Reddit and BlueSky, we'll

11:21 <RobertJrdens[m]> James Munns: We've been shipping control systems for quantum technology applications for a decade now. They heavily rely on Embedded Rust and that has lead to several subtantial contributions to the ecosystem, for example `smoltcp`.

11:22 <RobertJrdens[m]> A bit surprised that would be omitted.

11:24 <RobertJrdens[m]> The majority of trapped ion based quantum technology applications (from optical atomic clocks to quantum computers both in academia and industry) worldwide use this.

11:24 <JamesMunns[m]> agh! I blame recency bias, I've had stabilizer et. al in my slide decks for years now :D

11:25 <JamesMunns[m]> Let me add it!

11:29 <JamesMunns[m]> How does:

11:29 <JamesMunns[m]> > The [Sinara Stabilizer] control system for trapped ion quantum technlogy, used for atomic clocks and quantum computers both in research and in industry use Rust on STM32 based devices

11:29 <JamesMunns[m]> sounds @Robert Jördens ?

11:30 <RobertJrdens[m]> Stabilizer is just one outcrop of that entire ARTIQ/Sinara community. The bulk and the original driver for Rust there is ARTIQ https://github.com/m-labs/artiq

11:31 <RobertJrdens[m]> Not only STM32 but Rust on embedded Zynq/Vexrisc and mor1kx.

11:32 <RobertJrdens[m]> s/Vexrisc/Vexriscv/

11:32 <JamesMunns[m]> > The [ARTIQ] control system for trapped ion quantum technlogy, used for atomic clocks and quantum computers both in research and in industry use Rust on STM32 based devices like the [Sinara Stabilizer]

11:32 <JamesMunns[m]> works? Or feel free to propose an alternate one-sentence-y writing :)

11:33 <JamesMunns[m]> > The [ARTIQ] control system for trapped ion quantum technlogy, used for atomic clocks and quantum computers both in research and in industry use Rust on devices like the STM32 based [Sinara Stabilizer]

11:33 <JamesMunns[m]> works? Or feel free to propose an alternate one-sentence-y writing :)

11:36 <RobertJrdens[m]> In the [ARTIQ/Sinara] ecosystem Embedded Rust on VexRiscv, Zynq, and STM32 is used to control optical atomic clocks and quantum computers both in fundamental research and in industry.

11:36 <RobertJrdens[m]> Thanks!

11:38 <JamesMunns[m]> Very lightly edited, live now :)

12:08 <Ralph[m]> <JamesMunns[m]> "Posted on LinkedIn and Reddit..." <- do you have a link to your linkedin post (i want to re-share it for the nay-sayers in my connection 😉) - i can't seem to find you on linkedin 🤔

12:09 <JamesMunns[m]> Ralph[m]: https://www.linkedin.com/posts/james-munns-8a42b429_embedded-rust-in-production-2025-activity-7315687865441505283-HkqZ

12:15 <Ralph[m]> thanks! no clue why linkedin didn't want to find you when i searched your name + your company name (maybe i was too far removed from you for the algorithm to even pick you up? though that's the first time this has happened...). reposted it 🙂

12:37 <korbin[m]> <RobertJrdens[m]> "Not only STM32 but Rust on..." <- i too use rust on vexriscv

13:10 <ciakval[m]> <korbin[m]> "i too use rust on vexriscv" <- Is Rust the new Arch? 🤔

13:10 <ciakval[m]> I too use Rust BTW 😃

14:20 <balbi[m]> <ciakval[m]> "Is Rust the new Arch? 🤔..." <- dang, I use Arch and Rust BTW :D

14:30 <thejpster[m]> oof, assembly language is hard

14:31 <thejpster[m]> https://github.com/rust-embedded/cortex-ar/pull/27

14:31 <thejpster[m]> good job we can package it up into a crate so other people don't have to worry about it

14:31 <thejpster[m]> I am starting to wonder though if we should collapse cortex-r-rt and cortex-a-rt into cortex-ar-rt, because they are really similar now

15:27 <JamesMunns[m]> cortex-arrrrrrrt

15:29 <Noah[m]> XD

15:32 <thejpster[m]> cortex-ar-me-hearties

15:33 <thejpster[m]> Technically it’s aarch32-rt because it would run on an AArch32 core that wasn’t Cortex branded, like the ones in an early Snapdragon or Exynos

15:34 <thejpster[m]> And it would match aarch64-rt

16:12 <RobinMueller[m]> <thejpster[m]> "I am starting to wonder though..." <- any chance that cortex-a or cortex-r specific code might come back at a later stage? I was considering trying cortex-a-rt on this beaglebone I have lying around here. Need to solder a JTAG connector on it though...

16:14 <RobinMueller[m]> * this beaglebone black I have

17:31 <thejpster[m]> I mean, yeah, it's possible? I don't know enough to say for certain.

17:31 <thejpster[m]> one the one hand we have code duplication, on the other we have the risk of doing a bunch of work to merge it and then having to split it again.

17:32 <thejpster[m]> https://github.com/rust-embedded/cortex-ar/pull/27 almost broke me. Trying to get a spare register to work out if you're in T32 or A32 mode, for the undefined handler, but putting everything back exactly it was was quite difficult. I wanted to skip the SRS/RFE and do it manually, except I need a register to pop the CPSR into and I don't have one because all my registers are now pristine.

17:34 <thejpster[m]> I propose we leave -a-rt and -r-rt split for now.

17:44 <thejpster[m]> <RobinMueller[m]> "any chance that cortex-a or..." <- I have a 32-bit Raspberry Pi 2 (before they switched to the 64-bit chip from the Raspbery Pi 3). I might try that. I think it's quad Cortex-A7?

21:01 <Amit[m]> Hi all, a bit out of left field, but Tock is going to have it's annual get together semi-co-located with RustConf---specific venue TBD but it'll be Friday September 5th in Seattle after the main RustConf days (we're coordinating with the conf organizers a bit to make sure we don't step on the conference toes in any meaningful way). I'm wondering a couple related things:

21:01 <Amit[m]> (1) Is there going to be a contingent of general Rust embedded folks in and around RustConf (I know bartmassey obviously). I know many of you are outside the US, which makes Seattle both far and, shall we say, legally confusing to travel to atm (for example, while Leon and I really really enjoyed RustNL last year and the embedded wg unconf that followed, we are unlikely to join this year due to travel concerns).

21:01 <Amit[m]> (2) If so, would there be interest in piggy-backing on the organizing work we're doing anyway to have some sort of even for embedded Rust more generally

21:14 <bartmassey[m]> I'm happy to help with local arrangements for a thing if folks want to do one. I'm 3.5 hours drive away in Portland, so not so far.

21:15 <thejpster[m]> Having two Embedded Rust meet-ups per year - one attached to a North American conference and one attached to a European conference makes sense, and I would support that meet-up being broader than "just" the Embedded Devices Working Group (where's my Rust Society already?!) because it's important we all keep talking to each other.

21:15 <thejpster[m]> Unfortunately I won't be at either RustConf nor RustNL.

21:21 <thejpster[m]> I pulled on the thread some more: https://github.com/rust-embedded/cortex-ar/pull/27/commits/260ed0951fdf5527dd76b672e263d4619ac72b19

21:21 <thejpster[m]> There's dangerously little jumper left. Only a jumbled mess of yarn.

21:22 <balbi[m]> thejpster[m]: v1 looked so small and tidy

21:23 <thejpster[m]> but also it was wrong

21:23 <balbi[m]> sadly

21:23 <thejpster[m]> now we have more tests, which have revealed more bugs (mainly in documentation)

21:24 <thejpster[m]> I think it's all good now. All the functions are in the right order. Every exception handler has both a named asm trampoline, and PROVIDE'd default asm trampoline, a C function and a PROVIDED'd default C function.

21:37 <Mathias[m]> The Embedded contingent at RustConf last year was small. I was not planning on going (and instead focus more on RustWeek). I might reconsider if there more things planned.