Let print! and prinln! write to "/ext/flipperzero-rs-stdout" with a Feature

[cptpiepmatz]

While developing a FAP that is using uart, I have a hard time checking the logs of my fap that just ran. Normally I would just open the logs via the wifi dev board but it uses uart for the logs but I need them for my fap. So I cannot really use them.

I saw that run-fap reads the contents of /ext/flipperzero-rs-stdout and displays them. Wouldn't it be neat to have print! and println! automatically write into that file so that run-fap would display that? It should be kept under a feature so that the final release build doesn't do that but for development this could be nice.

[dcoles]

Hi @cptpiepmatz,

Thanks for creating this issue. To make sure I understand your request properly, the desired behaviour would be for the output from print! and println! to be shown when the app is launched using run-fap, correct?

Writing to /ext/flipperzero-rs-stdout was a workaround due to it not appearing to be possible to launch an app and get the log output, at least via the original CLI interface. Now there is a RPC-based mechanism, it would be worth seeing if this situation has changed.

[cptpiepmatz]

Thanks for creating this issue. To make sure I understand your request properly, the desired behaviour would be for the output from print! and println! to be shown when the app is launched using run-fap, correct?

Yeah, it's pretty much that. run-fap is such a nice utility but when I cannot use the devboard to see logs, it gets annoying to check for logs. This shouldn't be on by default and by using a feature it would be convenient to turn it on.

[str4d]

Writing to /ext/flipperzero-rs-stdout was a workaround due to it not appearing to be possible to launch an app and get the log output, at least via the original CLI interface.

Indeed. And a significant downside is that you can't get the log output until after your FAP has finished running. That happens to be fine for test binaries (which is what the workaround was originally implemented for), and it might still be useful for debugging, but it's not ideal in general.

Now there is a RPC-based mechanism, it would be worth seeing if this situation has changed.

I started trying to migrate to the RPC-based mechanism in #104 but ran into some issues, IIRC in part due to the RPC mechanism not really being documented upstream and its interaction pattern being somewhat heavily tied to how QT works. Now that the Flipper Zero SDK has reached 1.0, I might revisit this and see if the situation has improved.