Visual Studio Code (VS Code)

Microsoft has released a cross language cross platform code editor, vscode, with advanced features packaged into a command-based system (fewer menus, more commands). It has a C/C++ (instructions) module which supports Intellisense for easy code navigation and auto completion.

1. Install VS Code

Install VS Code on your native operating system (where your graphical output is). VS

  1. Install VS Code download
  2. Install extensions:
    • C/C++ for editing and debugging C/C++ code
  3. Use Makefiles for compiling within VSCode blog, extension
    • The Makefile has to be in the base folder to be detected by the plugin automatically. For projects with a Makefile in a subdirectory, configure your workspace with makefile.makeDirectory pointing to the subdirectory (e.g. src) relative to the workspace base.
    • For cross compilation, use the preconfiguration and set makefile.preConfigureSript to the SDK environment setup script.

2. VS Code Remote Development

VS Code Remote Development simplifies remote development by accessing the remote file system, running remote compilations and executions. This is achieved by running a server portion of the editor on the remote machine (giving all access to files, compilers, executables) and a client portion of the editor locally. For more details see the Overview.

2.1 Windows - WSL as remote target

Since the development tools are installed in WSL you will need to use a WSL remote session instructions

2.2 SSH as remote target

For our work, you’ll need to use Remote SSH to connect to the COE machines. Make sure to connect to remote.coe.neu.edu (instead of gateway.coe.neu.edu). VS Code can leave some server processes dangling sometimes which is against the COE usage policy. To still allow for remote editing, we got our own server. There, you can also run the QEMU simulator.

3. Intellisense for Cross Compilation

Intellisense, part of the C/C++ extension, aids in navigating code structures and finding definitions (functions, structures). By default, it searches the host for include files. For cross-compilation, however, it needs to use the header files included in the cross compilation SDK. The SDK location, however, is user and machine specific. Its path should not be hard coded – it is never a good idea to have hard coded paths in code. The 2-step process of first defining the SDK location and second setting the workspace solves this cleanly. Thanks to @benthacher (Spring 24).

3.1 Machine-specific SDK Location Setting

Create a system setting that defines a variable oecore_target_sysroot pointing to the sysroots folder in the installed SDK. For this, open a folder where you typically perform the work (e.g. in WSL if working on windows).

  1. Press F1 to open the command palette
  2. Open the settings:
    • If working remotely (e.g. WSL), enter: Preferences: Open Remote Settings (JSON)
    • If working natively on Linux, enter: Preferences: Open User Preferences (JSON)
  3. Add an entry pointing to your SDK installation, such as (replace with your own path):
{
    "oecore_target_sysroot": "/home/schirner/eece4534sdk/sysroots",
}

3.2 Project-specific Setting (can be commmitted in repo).

In your workspace folder, create a file .vscode/c_cpp_properties.json (create the .vscode if it does not extist). Add the following content:

{
    "configurations": [
        {
            "name": "XARM",
            "includePath": [
                "${config:oecore_target_sysroot}/cortexa9t2hf-neon-esl-linux-gnueabi/lib/modules/5.10.0-esl/build/include/**",
                "${config:oecore_target_sysroot}/cortexa9t2hf-neon-esl-linux-gnueabi/lib/modules/5.10.0-esl/build/arch/arm/include/**"
            ],
            "compilerPath": "${config:oecore_target_sysroot}/x86_64-eslsdk-linux/usr/bin/arm-esl-linux-gnueabi/arm-esl-linux-gnueabi-gcc",
            "cStandard": "gnu89",
            "intelliSenseMode": "linux-gcc-arm"
        }
    ],
    "version": 4
}

The target type in your workspace, indicated bottom right, should now read XARM instead of Linux. This indicates that the SDK header files are used.

4. Working as a group in the lab sessions

For joint code development, we recommend VS Code Live Share.