-
Notifications
You must be signed in to change notification settings - Fork 180
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
Discourage use of semihosting and mention viable alternatives #257
Comments
ITM is also a very nice option. |
Yes, ITM is also an option. It does require a more elaborate setup though and only works on Cortex-M3 and higher so it's less ubiquitous. We can and should mention it but the main reason to go for semihosting so far was that it's the only method which doesn't come with special prerequisites and is available everywhere. With RTT now we have a far superior method. |
Completely fair. |
is RTT available on non-segger debuggers? for some reason i had the idea it was proprietary to them :-/
i would love to see all the approaches listed with pros/cons perhaps? |
Yes, we have a very nice rusty solution for that working with any debugger.
Absolutely. At the moment we pretty much only have semihosting documented though and when people inevitably run into issue we say: "Hey, don't use semihosting!". I think we should have a bias towards good solutions which should be documented first and then point out the alternatives -- nothing wrong with that. |
So, I'm a rust newbie, (but an otherwise experience programmer and familiar with embedded development), and I saw this issue by chance as I was going through section 2.2 in the book. I spent about 30 minutes, and got rtt working with the stm32f303vctx that is used in the guide. Basic steps:
I ran This was way _way_easier than the semihosting approach currently in the guide, and that was without documentation on it being present in the embedded-book. Can't recommend this enough for supported chips (and the list seems quite large as I browse it today). |
For those who want an easy way to try rtt with the changes mentioned above, i have a fork of the quickstart that can be used as a drop-in-replacement for this chapter of the guide, just by running:
/cc maintainers, if there's anything I can do to help with documentation after a decision has been made, lmk. |
RTT works like a charm, specially with cargo-embed and probe-rs. However, if you want to use OpenOCD instead (e.g., with VS Code and cortex-debug) you will face some issues. Namely, OpenOCD only tries to open the RTT connection once at the very beginning, when the device hasn't started RTT yet. Thus, it fails. A quick workaround is to set a breakpoint right after initializing the RTT in the embedded device and retry opening the RTT connection manually in the OpenOCD console. See the following related issue. |
Is there a way to get RTT to work on qemu? I can use semihosting to log with qemu, but RTT does not seem to work? |
As far as I know, RTT logging is not supported by QEMU directly. QEMU does provide GDB stubs for remote debugging; semihosting is probably the easiest logging solution. |
Semihosting is a top contender for being the stumble block in embedded so we really should discourage its use with a big fat warning and a checklist what to look out for if a program uses semihosting and doesn't work. At the moment it's described in very peachy terms so people naturally try it, run into problems and then are told on matrix to not use semihosting -- not a great experience.
Instead of semihosting the better approach is to explain
cargo-embed
and RTT, which is similarly ubiquitous. And as a runner up serial is also a viable and less intrusive option.The text was updated successfully, but these errors were encountered: