Guide for doing embedded development in an IDE

[japaric]

From @japaric on February 26, 2018 15:57

We have instructions for doing embedded development from the command line but we are missing instructions for doing embedded development in an IDE.

I heard that VS Code plus the cortex-debug extension works nicely for embedded development but I have no first hand experience.

We are looking for someone who can help us write down some instructions.

Tasks

• [ ] Write instructions for setting up a Cargo project in VS code including instructions for setting up the cortex-m extension, Xargo and the RLS. It could be any other IDE but VS code is the IDE with official RLS support.

• [ ] Bonus points if you write instructions for getting semihosting, ITM / SWO, register (SVD) view to work.

• [ ] Identify any changes that we could make to cortex-m-quickstart to make integration with VS Code, or any other IDE, easier. Like checking in some configuration file (?).

Copied from original issue: rust-embedded/wg#54

[japaric]

From @niklasad1 on February 26, 2018 16:25

I got debugging in VSCode to work in TockOS you can grab the script for remote debugging here and a very brief tutorial here. Feel free to use as inspiration it but I haven't tried the cortex-m extension cheers.

[japaric]

From @Lakier15 on March 1, 2018 21:44

I've been using IntelliJ IDEA Community with the Rust plugin for almost 9 months. It works really well. Only problem might be the different approach from using the RLS. I believe that they use their own parsing engine.

What really is lacking, out there, is some form of Rust IDE debugging. Rust-DT was a good effort to use the Eclipse capabilities to also debug embedded systems. However, the project has been abandoned, and well, its Eclipse.... 👎

[japaric]

From @nallar on March 2, 2018 9:56

Debugging in CLION with intellij-rust works.

[japaric]

From @Lakier15 on March 2, 2018 10:11

I thought there were some problems with debugging in CLION.

Anyway, I think CLION is not free. It doesn't have a community edition, so it would not be accessible to everybody equally.

[japaric]

From @davidtibbetts on March 5, 2018 22:19

I've had success with VSCode using OpenOCD and STM32 MCUs on Windows. launch.json tasks.json

[japaric]

From @AJAnderson on June 23, 2018 11:33

Hi @japaric, I set up the cortex-debug extension in vs-code and got it working, would love to write instructions but where should I write them up?

[japaric]

From @puzrin on June 23, 2018 16:25

I'd like to point 2 major use cases:

1. I'm a programmer, and i'd like to quickly setup env for project from github to start work.
2. I'm a user, who does not understand anything in programming, but i'd like to flash firmware from some github's project.

Both are important.

Take a look at PlatformIO, it's available as plugin for atom/vscode/eclipse. It's not for Rust now, but solve some important usability issues:

• automate toolchains install for your platform (i mean not compiler only, but programmators and so on)
• simplifies dependancies management (C-specific kludge, not actual for the Rust)
• wrapper to autodetect programmator's port (you should not define it manually, very convenient)
• automates spiffs image build from files in directory

It would be nice, if the same will be simple with rust to.

[japaric]

From @mathk on June 24, 2018 20:47

My experience with ITM was that I would never really know how to setup the TPIU clock from gdb. Once I freeze the MCU to maximum speed (216Mhz) the ITM port didn't work properly.

[rubberduck203]

@jamesmunns brought this to my attention. I’m currently working on a tutorial for setting up VS Code with the Cortex-Debug extension for the Discovery board (alá The Discovery Book). I’m happy to take this on with a bit of guidance.

My biggest concern at the moment is I’m not sure the Discovery board is appropriate for The Book. If I recall correctly, most of the Book is written against QEMU. Is it preferable that an addition here use QEMU rather than the Discovery board?

Other than that, it’d be nice to know where you think this would fit into the narrative. To me, it feels like an appendix to be added to the end. So much of the book is written assuming you’re running from the cli, I’m afraid putting it elsewhere would confuse things.

[therealprof]

@rubberduck203 The book tries to stay vendor neutral or generic as far as possible. However if something cannot be taught in a neutral setup I believe it is more relevant to demonstrate the concept in a suitable environment rather than just ignoring it.

Other than that, it’d be nice to know where you think this would fit into the narrative. To me, it feels like an appendix to be added to the end. So much of the book is written assuming you’re running from the cli, I’m afraid putting it elsewhere would confuse things.

Where would the focus be? Your introductory paragraph covers quite a wide field of topics. Programming via IDE might have a place in the book. However debugging is more a fit for the debugonomicon rather than the book.

[rubberduck203]

The scope of this is really limited to the original post. Walk through setting up an editor to build, load, debug, view registers with SVD, and print to ITM. Not a “This is how you debug a program”, just a “here’s how you can setup an editor to do the same things we were just doing from the command line”.

The book tries to stay vendor neutral or generic as far as possible.

I take that to mean you would prefer the QEMU environment, if possible. I’m happy to give it a shot. I don’t see why it wouldn’t work just as well.

[rubberduck203]

I posted a draft of the blog post. https://dev.to/rubberduck/debugging-rust-arm-cortexm-programs-with-visual-studio-code-336h

For the book, I would obviously skip over things already covered, so it would be more like this section of the post. https://dev.to/rubberduck/debugging-rust-arm-cortexm-programs-with-visual-studio-code-336h#setting-up-visual-studio-code

When time allows, I'll see if I can't adapt this to QEMU so it doesn't rely as heavily on the Discovery book.

Early feedback about whether this is a thing you want, or tips for staying in the existing tone of the book would be appreciated.

[burrbull]

@rubberduck203 Does VS Code support SVD files with clusters?

[rubberduck203]

I’m not sure I understand the question @burrbull. Actually, I’m sure I don’t understand the question. I don’t know much about SVDs beyond what the hour or two I spent trying to figure out how to xslt transform an Atmel format into SVD.

The plug-in is open source, but not well documented. I’m sure the author could answer your question.

https://github.com/Marus/cortex-debug

[rubberduck203]

I got QEMU working and opened a pull request in the quickstart repository. https://github.com/rust-embedded/cortex-m-quickstart/pull/78

If it gets mainlined, there may not be much to add to the book, but probably still worth a mention that it's there for those who want to use it.

[rubberduck203]

Now that https://github.com/rust-embedded/cortex-m-quickstart/pull/78 has been merged, I plan on finding some time to work on a PR for this issue.

[rubberduck203]

Closer. All the raw content is now contained in these two blog posts.

https://christopherjmcclellan.wordpress.com/2019/11/29/debugging-rust-arm-cortexm-programs-with-visual-studio-code/ https://christopherjmcclellan.wordpress.com/2019/12/31/debugging-rust-cortex-m-with-vs-code-take-2/

Now it's just a matter of sitting down, getting my thoughts together and polishing it in a format appropriate for the book.

I'm currently thinking this will live in 5 sections, the first three mirroring sections 2.1, 2.2, and 2.4 of the book. The last 2 are new additions.

x.1. QEMU x.2. Hardware x.3. Semihosting x.4. ITM x.5. Configuring for other hardware