We’ve all had the experience of checking out an old release branch to debug an issue, only to find out that it depends on toolchains and packages that are no longer installed. This can be a major pain, and people have come up with several ways around it.
Thanks for the awesome article! I decided to check Conda out since Docker for Windows still does not support USB devices (for debugging). Leaving the environment management aside, it was a pleasure to install all development dependencies on one command.
However I found that the integration with other shells on Windows is still problematic. We use VS Code as our IDE, which by default runs its commands on PowerShell, but Miniconda for Windows is designed to be used from its own shell. It is possible to integrate conda into PowerShell by running conda init, however this modifies the profiles (even the registry for cmd.exe!), which causes all PowerShell instances to run with Conda activated, which is not desired. It seems that I won’t be able to integrate Conda into our workflow with VS Code… Has anybody a solution for this?
Apparently this applies to Linux, too. In general, I found it impossible to work with VS Code and Conda, as the tasks, debugger etc. do not recognize the Conda environment. Has anybody used an IDE together with Conda to develop embedded software?
Hey @bora,
You should be able to prepend the conda activate <env> command before the various commands that are needed to use.
If that doesn’t work, you should be able to launch VSCode from the shell when you have the environment activated.
$ conda activate myenv
$ code .
If I launch VSCode native, conda does not get recognized as a command, as it requires the shell profile modification to get recognized.
Launching VSCode from the conda environment would probably work, but it is still impairs the workflow. I use the Windows launcher to open VSCode and open other projects directly from inside VSCode. Changing environments would require going back to the command line for this.
Doable, but not ideal 
Great article, folks! I spent several hours yesterday wrestling with MinGW and only kind of got something working. Today, I remembered this article and spent only 1 hour setting up Conda (about half of which was me being a knucklehead) and it works great! I’m super excited to incorporate this into all of my active and future projects.
I have an issue that I was hoping to get some advice with, though. While following your tutorial, I was able to install the make and gcc-arm-none-eabi packages. I noticed that my conda environment didn’t recognize some Linux commands that I’m used to, like “ls” and “rm” and I was able to get access to these commands by installing “m2-base”. However, after adding this package to my conda environment I now get an error that “arm-none-eabi-gcc” cannot be found when I try to run my makefile build. “arm-none-eabi-gcc -v” works and shows me version info, but calling it from within the makefile doesn’t. Does anyone know either (1) how to fix this error or (2) how to get the Linux commands another way? Thanks for the help!
Error message:
/usr/bin/sh: arm-none-eabi-gcc: command not found
make: *** [Makefile:163: build/main.o] Error 127
I haven’t used Conda before but it sounds like a nice solution. We are already starting to use Ansible more and more at my company to automate environment configuration. Do you have any views on the relative benefits?
I guess Ansible won’t do anything to help with swapping from one configuration to another, only configuring a new environment - and I guess Conda solves that too? For our purposes, this wouldn’t be an issue as we tend to run separate VMs for each project’s environment anyway.
For those interested in solutions for managing developer environments, I invite you to take a look how tests are defined and performed in the micro-os-plus/utils-lists-xpack project, using the xPack Build Framework.
Tests are executed as native processes and as Cortex-M semihosted applications emulated with QEMU. Both CMake and meson tests are available, with GCC and clang.
You can easily do a test run on your machine:
npm install --global xpm@latest
rm -rf ~/Work/utils-lists-xpack.git && \
mkdir -p ~/Work && \
git clone \
https://github.com/micro-os-plus/utils-lists-xpack.git \
~/Work/utils-lists-xpack.git
cd ~/Work/utils-lists-xpack.git
xpm run install-all
xpm run test-all
The only prerequisite is npm; everything else is installed automatically as dependencies. Quite convenient for CI runs.
The xPack tools are available on Windows, GNU/Linux (Intel & Arm), macOS (Intel & Apple Silicon).
And yes, xPacks also allow to lock a project to a specific version of a toolchain (or any other xPack tools).