This is another article in my series about Visual Studio Code. After having it installed (see VS Code: IDE Installation), this one is about starting the IDE
I can start the IDE from the shortcut (if created during the installation) or by typing code in console/command prompt shell (e.g. Windows PowerShell). To be able to use the code command requires VS Code to be present in the PATH.
Nothing has to last forever, and VS Code might not be the right thing for everyone. VS Code can go overboard with all the extensions and things it had proposed to install. Up to a point that one needs to get re-started again. Or because you tasted VS Code, but you did not like it.
That’s OK, you can uninstall it, after you have installed it (see VS Code: IDE Installation). The catch is: the uninstall does not a full removal, as settings and extensions do not get removed.
This article shows how to fully uninstall VS Code.
It is August 1st, and Switzerland is celebrating its National Holiday. Rather cold and rainy, so this gets me some time to catch up on things. The preparation for the coming university semester in September is in full swing, and I have the honor to take over building up a new Master of Science in Engineering education module. In the existing courses I teach on the topic of embedded systems, I do use devices and MCUs from vendors like Broadcom, NXP, STM, Nordic, Raspberry Pi and Espressif. This not only means different SDKs, but different IDEs with different debug probes.
Just a subset of different hardware kits used in different labs
Eclipse has been the common factor in the mix with all these, and with all the pros and cons, it worked very well. With NXP having released support for Visual Studio Code, adding an announcement, and other vendors going into the same direction, I took the decision that I want to migrate my lab and lecture infrastructure to VS Code.
The choice of IDE is sometimes given by the available tools at hand. And sometimes it is a preference of the look and feel. Or maybe just what one is used to use. And sometimes small changes can make a big difference too.
For example, when I’m starring at my code for hours, a nice font can make all the difference. A cool and nice feature of fonts are ‘Ligatures‘. Maybe you can you can spot them in the following screenshot?
A Triumvirate is or Triarchy is built by three individuals which lead or rule something. In this article I want to rule a project with Eclipse CDT, Visual Studio Code and with building it from the command line for automated builds.
So what if I have an Eclipse project (say MCUXpresso IDE and SDK), and want to build it on a build server, and and I want to use the same time the project with Eclipse IDE and Visual Studio code?
Key to this is CMake: I’m keeping the Eclipse CDT features, adding CMake with Make and Ninja to the fix, and have it ‘ruled’ by three different ’emperor’: Eclipse, Visual Studio Code and from a shell console:
MCUXpresso SDK CDT project with CMake for Eclipse, Visual Studio Code and Command Line BuildingContinue reading →
The Microsoft Visual Studio Code is a great IDE, but does not (yet?) implement features for true embedded usage. Or things are there to some level, but hard to use. One of these things is how to step in the assembly code. This article shows how to do this.
After the release of the NXP MCU-Link debug probe, there have been hints in the Eclipse based MCUXpresso IDE that there must be another one coming. And indeed: another and more powerful debug probe is now available: the MCU-Link Pro. It is not only a debug probe but a power/energy measurement tool too, including an extra LPC804 mikrocontroller which can be used for all kind of things, like automation or scripting.
For me the Cortex-Debug Visual Studio extension by marus25 is the standard way to use VSC for embedded development. Another ‘standard’ piece I’m using in many of my projects is the SEGGER RTT.