Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to run host side code (rust?/bash?) before/after each test case #15

Open
t-moe opened this issue Dec 22, 2023 · 4 comments
Open
Labels
enhancement New feature or request

Comments

@t-moe
Copy link
Contributor

t-moe commented Dec 22, 2023

... for instance to start/stop a power analyzer.

I'm open to take design ideas...

Running a bash script could be pretty doable. Running rust code, would require to build it somehow and then load it as library into probe-rs?

@t-moe t-moe added the enhancement New feature or request label Dec 22, 2023
@Yatekii
Copy link
Member

Yatekii commented Dec 28, 2023

How would you tell the executor what bash script to run? Do you put it in the debug symbols? Because when you compile for the target, how would you run host code?

It would be insanely dope if you could mix and match host/target code ^^ but then you run into the problem of how to define deps etc :)

@t-moe
Copy link
Contributor Author

t-moe commented Dec 28, 2023

As a very basic first approach, we could even store the bash script on the target and transfer it together with the list of tests.

But yes... It would be really cool if would be able to mix host and target side rust code. We could auto-insert breakpoints on the target, to switch from the target executing to host....

@Yatekii
Copy link
Member

Yatekii commented Dec 28, 2023

The problem is how you configure the compilation (pull in crates). Maybe it could be a hack via cargo metadata where you can define deps like that. but r-a etc will not work :/

@ejpcmac
Copy link

ejpcmac commented Jul 9, 2024

Another use-case for running host-side code in the test runner would be to drive a counterpart. Like sending / receiving data via UART using a FTDI to test the UART HAL on the chip, or driving another MCU to check for GPIO states, and so on.

I was thinking recently how one could achieve that with linear-looking code, and had the idea of writing embed fragments in the code, like (pseudocode):

#[test]
fn test_gpio() {
    let counterpart = Counterpart::init();
    assert!(counterpart.gpio0.is_low());

    embedded! {
        let dp = Peripherals::take();
        let gpio0 = dp.GPIO0;
        gpio0.set_high();
    }

    assert!(counterpart.gpio0.is_high());
}

When compiling, all embedded! fragments would be extracted to be compiled for the target architecture in the test firmware, and replaced to an RPC call to the embedded firmware in the test runner.

So, from the test writer point of view, the test would be run from the host, except embedded! fragments which would be run on the embedded system. If status / data is needed, one could write:

let output = embedded! {
    let value_computed_on_embedded_side = some_computation();
    value_computed_on_embedded_side
};

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants