Setting up IDE with debugging capabilities

[pmehradnia]

Are there any recommended workflows to set up cFS with IDEs to incorporate debugging capabilities (run-time and/or compile-time)?

[mprather]

We've used VSCode with good results.

[pmehradnia]

Thanks for sharing that.

From (1) you seem to suggest that you are able to use C and C++ compilers to build and trace errors within the IDE, as one would with a typical C/C++ application, which would resolve the first part of my question.

For (2), perhaps where the confusion comes from is it seems you are using it to compile on VSCode and running it on a target embedded platform as opposed to running it as a dedicated Linux application. I was curious if anybody has set up a workflow and the tools to run the application under Ubuntu (the default build options in the Readme) as a console application, and if it has been integrated that with the IDE's debug tools. Hope that clears it up.

[jphickey]

I'm also not sure I understand the confusion ... When building CFS using CMake build scripts, when you supply "SIMULATION=native" and "CMAKE_BUILD_TYPE=debug" (usually the default) during the preparation/configuration phase, this instructs the build system to use the system native compiler and also to build with appropriate configuration for debugging. The generated binaries in this configuration are just regular Linux binaries and they can be executed or debugged like any other C program.

This get a little more complex if you want to debug a cross build - it's still possible using gdbserver but it depends on the type of board you have and how you connect to it.

But the simple case of simply debugging this software is nothing special - standard debugging tools (including command line ones like gdb as well as any GUI ones that use the same facilities) should just work.

VSCode is a fine suggestion, I use that myself. I have also use Eclipse for C/C++ in the past, which also worked OK.

[mprather]

perhaps where the confusion comes from is it seems you are using it to compile on VSCode and running it on a target embedded platform as opposed to running it as a dedicated Linux application

Nope, I never said that. You're reading a little too much into my statement. Launch targets is the name of the feature in VSCode. That feature can operate in a variety of ways, and it is up to you to configure it, which I mentioned.

I agree with @jphickey's comment -- it's just another exe and standard tooling you would use on any other project should be fine. I will, however, admit that cFS is a big scary mess when you're just starting out. It is easy to get lost early on but don't let the tooling add to that confusion. Understand what cFS requires first and then fold your tooling/processes into the mix.

To give you an example of the overall workflow on our last project...

All development for the project's main library code would occur on Windows and the elements using those libraries were developed in Ubuntu 18.04 within a cFS deployment. Our engineering and science teams are Windows-based and we obviously had to use a Linux-based distro to get the cFS stuff working, thus 2 distinct toolsets. Our final target was a RPi 3B+. Thus, on check-in, our Azure Devops pipelines would push out the latest bits to a self-hosted RPi agent. The RPi would then install cFS, compile everything, run tests, and, if successful, store the binaries as an artifact. Visual Studio was used on the Windows platform, VSCode everywhere else. All the cFS debugging either occurred on the Ubuntu or the target (it was probably a 95-5 split, we rarely had to debug something that was only seen on the target). Bottom line is that you should use the tools that best fit your team. We chose not to cross-compile and instead build natively. It was just easier across the board to do it that way once we had our target incorporated into the CI/CD pipelines.

[pmehradnia]

Thank you for the suggestions. The workflow you both discussed the allows debugging and building the applications directly from IDE. One key point seems to be that the make SIMULATION=native prep needs to be run once before running the make on the IDE (there is probably a way to invoke that from IDE if one digs far enough, however).

[fschramka]

Hi @mprather, hi @jphickey

I'm trying to use cFS with Visual Studio and WSL2 - you mentioned that you managed the VS part in your project.
I'm using SIMULATION=native and I was able to configure cmake and build the "mission-install" target through VS22.
This gets me an executable in CMAKE_INSTALL_PREFIX/cpu1 - that one also works, I can start it from the wsl console :)

But I have no idea how to start that executable through VS22 with gdb? Cmake does not create an execution target, which makes sense in cases when the target CPU is not compatible with the native one. But in the native case this should be possible?

How did you or @pmehradnia work it out in the end? Were you able to use the Visual Studio Debugger View through gdb?