search

probe-rs / rtt-target

Target side implementation of the RTT (Real-Time Transfer) I/O protocol
MIT License
123 stars 30 forks source link

asm breakpoint style handler #8

Closed jacobrosenthal closed 4 years ago

jacobrosenthal commented 4 years ago

I'm sure youve seen probe-run https://ferrous-systems.com/blog/probe-run/ utilizing this crate heavily. In all their docs they're using a locally defined panic_handler which simply rprintln and asm breaks. 

// if an panic happens, print it out and signal probe-run to exit
#[panic_handler]
fn panic(info: &core::panic::PanicInfo) -> ! {
    rprintln!("{}", info);
    loop {
        cortex_m::asm::bkpt() // halt = exit probe-run
    }
}

I could publish a separate crate dependant on this one, but they could go out of sync. Any thoughts on keeping this internally?

mvirkkunen commented 4 years ago

It looks like their "defmt" system which will probably be used a lot has their own RTT implementation which is incompatible with rtt-target. If this is still useful it could be added - do you think it should be a separate crate (kinda heavy) or a feature? I'm not sure if it's a good idea to bkpt unless we know something will handle it.

jacobrosenthal commented 4 years ago

Seem fine, user brought it in after all. Same as halting. I agree they'll use defmt but for simple use cases I find it a bit heavy to configure. Not to mention it's not released. I'll be using rtt-target and probe-run for non space constrained examples personally.

jacobrosenthal commented 4 years ago

Looks like theyre preparing to have a feature on probe-rs for this, since thats the other best place for that to live, ill close this for now https://github.com/knurling-rs/probe-run/commit/ef45f6f4fe1a8b5ff37ccf178cdcd8048898aeef