04:38 <re_irc> < (@tufelkinder:matrix.org)> Anyone with RP2040 experience that can provide some insight into what I'm doing wrong here? Trying to read from UART0 and write to UART1 at approximately the same time using interrupts to tell when there's data on UART0. After many hours of reading and research, I have cobbled together something like the code below but it crashes every time there's a UART0 RX interrupt:

04:38 <re_irc> type TUartC = UartPeripheral<Enabled, UART1, (Pin<Gpio4, Function<Uart>>, Pin<Gpio5, Function<Uart>>)>;

04:38 <re_irc> #[entry]

04:38 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/4FruEtwTClLj6v7MrBV3nuYSzVXAzlD3 (41 lines)

04:38 <re_irc> static mut UART_C: Mutex<RefCell<Option<TUartC>>> = Mutex::new(RefCell::new(None));

04:42 <re_irc> < (@tufelkinder:matrix.org)> Also, I'm very new to Rust, so any constructive criticism is welcome, even if it's not directly related to this issue.

04:43 <re_irc> < (@grantm11235:matrix.org)> You should be able to change "static mut UART_C" to just "static UART_C" since it is a mutex

04:43 <re_irc> < (@grantm11235:matrix.org)> Then you can get rid of a lot of "unsafe" code

04:44 <re_irc> < (@grantm11235:matrix.org)> I'm not sure if that is related to the problem that you are having

04:48 <re_irc> < (@tufelkinder:matrix.org)> Okay, well that is very helpful, much appreciated and that compiles just fine. Going to take me a minute to fully test

04:49 <re_irc> < (@tufelkinder:matrix.org)> In the case of this code, do I need to release UART_C when I'm done with it?

04:49 <re_irc> cortex_m::interrupt::free(|cs| {

04:49 <re_irc> let mut u_c = UART_C.borrow(cs).take().expect("No UART obj found!");

04:49 <re_irc> u_c.write_str(cur_data.as_str()).unwrap();

04:49 <re_irc> });

04:51 <re_irc> < (@tufelkinder:matrix.org)> In other words, if multiple interrupts are attempting to write to UART_C, does each one that completes a write need to "give up" UART_C so that another interrupt or function can then take it?

04:53 <re_irc> < (@grantm11235:matrix.org)> "cortex_m::interrupt::free" disables all interrupts so nothing else can access the mutex during the critical section, then it re-enables interrupts afterwards

04:55 <re_irc> < (@tufelkinder:matrix.org)> Do I need to reset the UART0 interrupt after it's been triggered?

04:55 <re_irc> < (@tufelkinder:matrix.org)> e.g., with the GPIO interrupts, it looks like you can to clear an interrupt

04:56 <re_irc> < (@grantm11235:matrix.org)> Probably, but I'm not sure. The datasheet should tell you

05:01 <re_irc> < (@tufelkinder:matrix.org)> So, after removing the unsafes, the issue still continues, but I am getting data transmission received and passed on once before things seem to crash.

05:03 <re_irc> < (@tufelkinder:matrix.org)> I had originally written this to use a message queue Vec that the interrupts wrote messages to and the main loop was the only thing writing to UART_C. That didn't work in the past, but it might with some of these changes.

05:05 <re_irc> < (@tufelkinder:matrix.org)> Would that be a better / more efficient overall structure?

05:18 <re_irc> < (@tufelkinder:matrix.org)> Unfortunately, I'm not able to find any references to clearing interrupts in the RP2040 datasheet.

05:20 <re_irc> < (@tufelkinder:matrix.org)> > The masked interrupt status is visible in the INTS registers; there is one bit for each channel. Interrupts are cleared by

05:20 <re_irc> > writing a bit mask to INTS. One idiom for acknowledging interrupts is to read INTS and then write the same value back,

05:20 <re_irc> > so only enabled interrupts are cleared.

05:21 <re_irc> < (@tufelkinder:matrix.org)> Sorry, there is this on page 98. https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf#page=98

05:28 <re_irc> < (@tufelkinder:matrix.org)> Thank you for your help, definitely cleaner and getting some additional results without all of the unsafes. Calling it quits for tonight.

06:17 <re_irc> < (@timbod7:matrix.org)> On a general note, what's peoples experience with rust on a RP2040? I've only used STM32 chips to date, and am curious.

06:17 <re_irc> <henrik_alser> : You take() the uart so you need to put it back in there or it will panic next time. Also you probably don’t wanna unwrap() your str::from_utf8 or it might also panic if you get some garbage data

06:23 <re_irc> <henrik_alser> So depending on how you want to handle that you could wrap the write part inside an "if let Ok(s) = from_utf8(&buffer)" block instead of unwrapping

06:26 <re_irc> <henrik_alser> (Also if you don’t need ownership you could probably borrow mutably instead of taking the uart)

07:15 <re_irc> <henrik_alser> : It's quite well supported, we have most of the stuff you'd ever need implemented both in rp2040-hal and embassy-rp now

07:18 <re_irc> <henrik_alser> https://github.com/embassy-rs/embassy/tree/master/examples/rp/src/bin

07:18 <re_irc> https://github.com/rp-rs/rp-hal/tree/main/rp2040-hal/examples

07:42 <re_irc> < (@jannic:matrix.org)> : Also, if you notice something is missing, let us know. There's always room for improvement. #rp-rs:matrix.org (https://matrix.to/#/#rp-rs:matrix.org) is a good place to get help. Questions at any experience level are welcome.

07:56 <re_irc> < (@timbod7:matrix.org)> henrik_alser: Nice. And I'm keen to give embassy a go as well. Too many cool tools, not enough projects!

07:56 <re_irc> < (@timbod7:matrix.org)> : Thanks.

07:57 <re_irc> < (@9names:matrix.org)> not enough time for projects

08:24 <re_irc> < (@ryan-summers:matrix.org)> : See https://github.com/quartiq/idsp/blob/main/build.rs, build.rs used to generate the necessary LUTs :P

13:24 <re_irc> < (@aevir:matrix.org)> :q

14:14 <re_irc> <Alex> Hi, please direct me to the right place if necessary. I'm new here. I have a Teensy 3.2 and I cannot find a teensy 3.2 embedded hal implementation. Is anyone aware of one out there?

14:15 <re_irc> <Alex> I found https://github.com/mciantyre/teensy4-rs so I'm wondering if I can port that to 3.2

14:22 <re_irc> <Alex> I've also found this, which is a start https://github.com/rust-embedded/cortex-m maybe this is all I need? Not entirely sure just yet

14:36 <re_irc> < (@marmrt:matrix.org)> Teensy is the name of the dev board right?

14:36 <re_irc> If so you might have more luck if you search for support for the specific microcontroller it's using

14:46 <re_irc> <Alex> So I just found this. I initially ignored it because it seemed like there would be C++ stuff to pull in and it didn't seem to use embedded-hal. However, I've seen in their demos, they are actually using embedded-hal.

14:47 <re_irc> https://github.com/dfrankland/teensy3-rs

14:47 <re_irc> < (@sourcebox:matrix.org)> Teensy comparison: https://www.pjrc.com/teensy/techspecs.html

14:47 <re_irc> <Alex> And here's the demo

14:47 <re_irc> https://github.com/dfrankland/teensy3-rs-demo

14:48 <re_irc> <Alex> Not sure why they're pulling in C++ stuff atm

14:48 <re_irc> < (@sourcebox:matrix.org)> What you need is mostly a crate that supports the MCU. The cortex-m crate is for the core only, not the peripherals.

14:48 <re_irc> <Alex> : Yeah ok, that makes sense.

14:51 <re_irc> <Alex> This stuff is HARD MODE. But I refuse to go back to C++

14:51 <re_irc> <Alex> I mean, Rust is easy, but Rust embedded is hard mode

14:52 <re_irc> < (@mciantyre:matrix.org)> I'm not sure if there's overlap between the Teensy 3.2's MK20 peripherals and the Teensy 4's i.MX RT peripherals, so a perfect port might not be possible.

14:53 <re_irc> <Alex> : Yeah. Comparing things I decided that would make life even harder

15:00 <re_irc> <Alex> Looking at https://github.com/dfrankland/teensy3-rs-demo/blob/master/src/main.rs it seems like they're not even using their own crate and it should be possible for me to ignore teensy3-rs and just use mk20d7-hal directly

15:00 <re_irc> <Alex> Not sure. Will experiment

15:12 <re_irc> < (@xgroleau:matrix.org)> Hi all, so we've been working on a new product and are using rust and I've been wondering, to what extent to you test your code (with unit tests or integration)? I always feel like the type system prevents most cases and end up without really testing which I feel conflicted about. The only test we currently have are to test the bring up of a board and it's peripherals. And do you prefer...

15:12 <re_irc> ... on-device(defmt_test) or test on your dev machine?

15:24 <re_irc> < (@tufelkinder:matrix.org)> henrik_alser: henrik_alser: Thank you for that, very helpful. How do I "put it back" after take()? I appreciate the advice on more concise option handling, that looks much better. I was originally doing "UART_C.borrow(cs).borrow_mut()" but switched to "take()" when attempting to resolve some bugs, but I think I had other issues in my code. I'll switch back and see how it goes now.

15:26 <re_irc> < (@sourcebox:matrix.org)> : That's a really good question. I try to do unit testing for the parts that don't involve peripherals or other things that require specific hardware. I'm just simulating signals levels etc.

15:28 <re_irc> < (@sourcebox:matrix.org)> But to be honest, with C/C++ projects I did not even do that. Just running the code on the target machine and trying to simulate various conditions.

15:29 <re_irc> < (@sourcebox:matrix.org)> So Rust has the advantage that it provides a test runner that simplifies things.

15:34 <re_irc> < (@xgroleau:matrix.org)> Interesting, we did actually have more tests in c++ due to existing mocking library for embedded while rust doesn't seem to be the case.

15:36 <re_irc> < (@sourcebox:matrix.org)> There's a blog post here that may be interesting: https://ferrous-systems.com/blog/test-embedded-app/

15:38 <re_irc> < (@xgroleau:matrix.org)> I'll check it out thanks!

16:48 <re_irc> <henrik_alser> : When you take() it will be replaced with a None so you need to put it back in there just like you do when you initialize it (with replace), but yeah borrowing should be enough

19:17 <re_irc> <Ralph> : are you aware of https://crates.io/crates/embedded-hal-mock ? (but yes, this is very low-level mocking, if you want to e.g. mock an I2C device you'll have to do that on your own by writing a mock version of the driver you're using if you don't want to mock every single I2C transaction)

19:44 <re_irc> < (@xgroleau:matrix.org)> Ralph: I've looked it up and it looks nice for device drivers, but I was more talking about something similar to GMock/CMock or any std equivalent. Just seems that it was not developed for rust no_std for now.

19:44 <re_irc> But after some thinking, maybe doing tests on host is better (and CI is easier) and only test low level stuff on the device, similar to what the article by ferrous mentions. It's way easier to test and iterate and maybe the hal-mock will be handy

20:17 <re_irc> < (@jamesmunns:beeper.com)> Yeah: If you DON'T need hardware, do it on the host. If you DO want to do it on the target, you can use the "defmt-test" stuff in the linked article