Controlling the development environment

I write this since these practices have been useful for me, and hope that someone might benefit from these. This may be a bit off-topic since it relates to using PlatformIO.

Reasoning:
We have multiple tools that are developed actively and updated frequently, like Platform IO, ESP-IDF/Arduino framework, Visual Studio Code, OS drivers, etc. These updates sometimes impact your software build for your specific hardware environment in an undesired way, which is practically impossible for anybody to test in a bulletproof manner. Even I want to use the new tools, I do want to be forced to start figuring out tool issues while working on my application.

So I need way to bring in the updates in controlled manner so that I can choose to do updates when there is time to test those and to have an up to date back up to return to if things do not work out just right, so that project which I actually work on doesn’t get delayed.

Proposed solution:
To use a virtual machine (VMware or VirtualBox) for development, and install development tools on that. Then disable automatic updates, on Visual Studio Code, PlatformIO, so one can choose the time when these are done. I use Linux Mint as a host machine and Linux Deepin in a virtual machine for development (Ubuntu would probably be the safest choice for VM). When I plan for tool update, I simply make a copy of the whole virtual machine folder as a backup, and then run the tool updates. This way tool updates never put me offline.

Downsides:

  • Virtual machines are always less responsive than the host machine. This typically is not a big deal, but might be annoying.
  • Running virtual machines requires a relatively powerful host computer. Better to have plenty of RAM and HDD space.
  • Switching USB devices between host and virtual machines and selecting a network for the virtual machines may cause a bit of confusion in beginning.
  • Sometimes one needs to disable (blacklist) USB drivers which communicate with a debugger or with dev board in the host system side to use these from the virtual machines.

Additional benefits:

  • Linux virtual machine images can be published in net and copied from developer to another. If someone prepares a good quality development image for a specific purpose, this would have great value for those getting started. It could be used as-is or as a reference how to make things work.
  • In a commercial setting, products often need to be supported for ten years after initial product development. Virtual machines with disabled updates can be used to “freeze a project for specific HW version” and burn it into long term storage. So that new people, perhaps after years, can do modification to application code, build the microcontroller code and package it.
1 Like

PlatformIO allows to freeze dev-platform in you project. See Redirecting...

You will never be affected when new changes coming to framework, toolchains, or etc.

As for the VSCode, I recommend using the latest version. Our extension for VSCode just wraps PlatformIO Core.

1 Like

Thank you. I had not noticed that and will use it. For projects with a very long lifetime: I am uncertain if VSCode ten years from now will work with Platform IO of today, and how things will work on development hardware and OS version of that day. So I still want to lock the whole development environment when an IoT, etc. project is complete. I have been too many times trying to make small changes to some IO component which was engineered like fifteen or twenty years ago (and part of large automation system), and end up rewriting/reverse-engineering the whole component project or making bubble gum workaround: just because the development tools will not install/work/are not available/are lost for any system of today. Virtual machines have (so far) maintained backward compatibility well, my first virtual machines from 12 years ago run fine today. This is not PlatformIO specific but relates to practically all microcontroller development environments. Of the “modern” system over a short time span of some years, STM32 Cube updates have been the challenging ones.

In a pinch, that won’t be an issue, since if VSCode doesn’t work with PlatformIO, you can throw VSCode away, and run PlatformIO directly, since PlatformIO is really doing all the work, and VSCode is just pretty text editor. But locking it down with a virtual machine is always a good backup to have… especially since you can use snapshots to have backups of different versions and stages of your development environment, and then give any of those specific snapshoted stages to colleagues if needed, as well as being able to roll backwards or forwards as needed at will.

I’ve used the version notation myself for a few projects, as specific updated versions of the espressif8266 core causing otherwise stable code to suddenly break, so I skipped a few versions until things became stable again. This one feature alone make platformio worth sticking with.

1 Like