Consolidating with VS Code

Posted on by

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.

I’m using VS Code for more than two years now, see my article series about it, or how to build a Triumvirate. Eclipse won’t go away from my desk, as I’m still using different legacy tools for older projects. So Eclipse based IDEs will be around for a very long time. In a similar way as I still have many projects to maintain which are 10+ years old: this means they are using the original tools, compiler and IDE, for example CodeWarrior.

But I feel it is the right time to make the jump for the labs with a migration. With the idea that students have less tools different tools to install. But it is certainly a risk, as Visual Studio Code has the risk of instability, or many of embedded features are not up to the level of Eclipse (yet?). And it is a lot of work, but I feel it is about the right time to give it a try, and Visual Studio Code has shown a positive traction.

The risk is that I won’t have enough time to transition things for the semester start. Only for the next semester there would be around 60 labs to update/change, not including the lecture material itself.

Having use VS Code in some parts of my material, I see many risks too. Microsoft driving the most of VS Code is really good at doing the editor part, but struggles most with anything device or debug specific. The editor features are fantastic, but the build system integration (while flexible) is fragile. Yes, if everything is correctly setup, with the correct tools, it work very well. But think about a class with 30+ students, everyone having different Python versions installed (‘Python hell’), with outdated make and/or cmake, with a mix of Windows versions, Mac and Linux machines. Sure, docker would be an intermediate solution, but it adds complexity and removes some. So I think a good and transparent setup will be key. And for sure I will need to cut some corners.

With this, you will see more articles about using Visual Studio Code on this blog, because as you can imagine, I’m writing things up so it can be used with the labs, avoiding duplicated work.

What I’m planning to do is an new series of articles, similar to the previous one, going from installation and setup up to using and exploring features. So stay tuned for more articles.

Happy Birthday, Switzerland 🙂

Links

PS: and no, there is no reason to change the name of this blog, even if VS Code is eclipsing Eclipse (pun intended) 😉. Eclipse as an IDE will be around for many years to come.

26 thoughts on “Consolidating with VS Code”

  1. we switched a while ago as eclipse has always been a pain to use and the support of platformio for so many platforms makes the vs code/platformio combo a joy to use!

    Like

    Reply ↓

    • I have looked at platformio, and not planning to use it. Because I want that students know how things work, and that they have control over their environment. And that they could add platformio later on to the mix if they want, but not from the beginning.

      Liked by 1 person

      Reply ↓

  2. Nice!
    If you are missing some features, please report it to the developers of the “Embedded Tools” extension from Microsoft.
    You can send feedback to visualcpp@microsoft.com
    They were also at the embedded world exhibition this year, but unfortunately I was ill and missed it.
    I really think the need more feedback from embedded developers.

    I added python to the vcpkg environemt and it works.
    We have now the arm-gnu-toolchain, cmake, ninja, jlink mingw-w64 (unittests) and python with vcpkg.
    Our next step is to build on a linux machine, but now i have no time for it.

    warning: vcpkg-artifacts is experimental and may change at any time.

    You could make a template project with a .vscode/extension.json (with Embedded Tools Extension) and a vcpkg-configuration.json (gcc, cmake, jlink, ….)
    After installing the recommended extensions form the json file, the embedded tools extension would start vcpkg and download all tools for the build environment.
    This should work on windows, linux and mac.

    And vscode profiles are great to switch between different configurations.

    Thanks for your blog!

    Like

    Reply ↓

    • Hi Alex,
      thank you. Did not know that you can send feedback by email, and wondering if this gets considered by such a big company at all?
      I’m aware that some folks from the MS VS Code team are reading and commenting on my blog, so I hope that way things get feed back as well.
      I’m usually not able to make it to Embedded World because of lecture schedules, but I heard good feedback from various vendor VSC presentations, for example I had some former students visiting the NXP demonstration and they were impressed.
      I had looked at the vcpkg, and as well at the xpacks, I definitely need to check this out more, thanks for the hint!

      PS: my new Fronius Symo WR is working like a charm with the Tesla Powerwall 🙂

      Like

      Reply ↓

      • Nice to hear about your new inverter.

        I’m reading the C++ blog from Microsoft and there is often at the end of the posts “Send us your feedback”.
        So i send them a feedback and got a mail from the progam manager. (he was also at the embedded world)
        They asked about more details of my needs.

        The program manager mentioned in an Microsoft YouTube video, that embedded was not in the focus of Microsoft in the past.
        I think this changes now, they have purchased ThreadX RTOS, now Azure RTOS.
        They were also open for a call to discuss my feedback.

        Missing features from my feedback (last november):
        More ITM Stimulus Ports 0-31 and not only port 0 (ITM_SendChar)
        Data Trace
        Data Trace Graph
        Execption Trace

        It is also possible to make a issue on github for feature request.
        example: build analyzer
        https://github.com/microsoft/vscode-embedded-tools/issues/53
        (the nordic build analyzer is nice)

        Like

        Reply ↓

        • Hi Alex,
          that’s really encouraging, that they are listening (and hopefully acting). That build analyzer is present in different Eclipse distributions already, and I agree it is helpful to have that in VS Code too. And your more hardware (ARM Cortex) related features is in line with what I have missing for a long time and asked MS whenever I had a chance: debugging is still the weakest part in VS Code, but it has improved this year. So I hope it will be even more and faster improved in the coming months.

          Like

  3. Delighted to hear this Erich and excited to follow you and your students on your VSC journey on your brilliant blog. I still think Eclipse has a lot to offer particularly in the ability to install and get up and running very quickly in an intuitive manner. But nothing stays still and VSC is now the world’s favourite/most-used IDE and is superior in many key areas as you say and has a broad range of extensions and support for other languages (even including chip/FPGA design). Best of luck!

    https://survey.stackoverflow.co/2023/#section-most-popular-technologies-integrated-development-environment

    Like

    Reply ↓

    • Hi Hugh,
      thanks for your thoughts! Yes, compared with Visual Studio, the Eclipse vendor distributions provide a much more solid and streamlined installation procedure. With the disadvantage that each vendor has its own walled garden, but that way it is guaranteed that things are actually working. On the VS code side the situation is more of a do-it-yourself-IDE side, similar if you are building up a DIY Eclipse toolchain (https://mcuoneclipse.com/2013/07/20/dyi-free-toolchain-for-kinetis-part-1-gnu-arm-build-tools/) with the risk of breaking things. But the good side of this: once you are through this, you know how things are working together, and with that knowledge you have the ability to do the things the way you want and need. The challenge and destiny with VS Code will probably be the same as with Eclipse or Visual Studio: it tries to do everything for everyone, ending up in feature creep, getting too heavy and complicated, until there is the next ‘new kid on the block’. Will be interesting to see that development over the next years.

      Like

      Reply ↓

  4. I use VS Code a lot, for a wide variety of tasks, but its flexibility can also be its biggest drawback. When you have VS Code as your go-to editor for everything, it seems to accumulate plugins like barnacles.

    Language support for python, Java, C, C++, Javascript and so on, ARM, Risc-V and Intel assemblers, support for a range of config and data exchange files, some build tools, some test tools, some deployment tools, some knowledge management, some LaTeX and graphviz for writing up, word-count tools, readers for pdf, epub, html, and other documentation formats, PlatformIO and everything that brings in, a serial monitor/terminal emulator, the list goes on.

    What used to be a simple and quick-to-start editor now takes several seconds to start and bombards me with update messages and the PlatformIO home screen even if I just want to make a small change to a text file. I often find I’ve gone back to Notepad or even (god forbid) vi.

    I would dearly love a way to partition all this stuff into separate “applications”, so that I can choose (say) VSCode for Risc-V assembler, or VSCode for LaTeX, or VSCode for quick text edits as easily as I could with the standalone applications.

    You are probably going to tell me there is a plugin for that 🙄

    Like

    Reply ↓

    • Hi Frank,
      I absolutely agree with you. It is good to see that VS Code is able to do all these things. The same kind of thing imho as been the biggest challenge and problem with the Eclipse architecture and development: it can and does everything you can imagine. I even have running a product which is remote data logger application which is actually an Eclipse instance, but completely looks different than an IDE, but it is eclipse what is running! VS Code might run into the same mistake. The interesting thing I see is that Microsoft tries to adopt to development space (Embedded) for which they have little (or failed) expertise (at least in the past). A company can have the brightest software engineer to write tools, but if these engineers don’t understand the domain the tools are used, it will be very hard, and many mistakes will be made. I think Microsoft again wants to take the initiative, and maybe with the input and help of the silicon vendors they can understand the domain they want to target. And even more, that they will listen to the developers who actually are using it for that embedded domain.

      Like

      Reply ↓

      • “A company can have the brightest software engineer to write tools, but if these engineers don’t understand the domain the tools are used, it will be very hard, and many mistakes will be made.”

        Yah, my experience is that there aren’t all that many programmers who understand embedded these days let alone in a place like MS that has zero experience with it. I don’t care how good your programmers are, if they haven’t inhabited the depths of iron, they don’t even have the framework to understand it, let alone know how to deal with it. It’ll take MS quite awhile to come to terms with things.

        A good example is this update process: right now MS wants to update everything you’re working on as fast as they possibly can which is exactly wrong for embedded code. I’ll tell you when it’s safe to update my compiler chain, thank you and until then I don’t want to be bugged about it. Oh and I want this project on that tool chain version and that project on that tool chain version and will want that for the next several years.

        They have a lot to learn in the embedded space.

        Like

        Reply ↓

    • Hi,
      i think it is already integrated with profiles.
      It is possible to enable different extensions, settings for each profiles.
      The plaformio extension can be disabled for example a LaTeX profile.
      You can start vscode with different profiles:
      code ~/projects/web-sample –profile “Web Development”

      Like

      Reply ↓

      • Exactly. I started using profiles when the ‘extension creep’ started making vscode noticibly slower.

        I took some time to set up a ‘base profile’ for my text editing needs – and nothing else, and from there created different profiles for my different needs. Python, C, LaTeX, nRF Connect, and so on. Now, instead of needing to have all the plugins all the time, I just have the ones I need. Added bonus: if you use different themes for the different profiles, you know what’s what at a glance. I also set up a keyboard shortcut (from my base profile) to quickly access profile switching, so it’s done in almost an instant.

        Like

        Reply ↓

        • Yes, ‘extension creep’ is definitely an issue. Not that much about performance, but about cluttering and confusing the UI. Depending on the extensions installed, the ‘build’ or ‘debug’ might do different things. So I ended up with profiles for different silicon vendors.

          Like

    • Hi Alan,
      yes, I saw that coming :-). Happened already for my first articles on VS Code back some time.
      Doing well, and hoping for better weather, to have a chance to prepare some Texas-style BBQ 🙂

      Like

      Reply ↓

Leave a reply to tklmittoor Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.