MCU development from a remote VM. - Page 1
Forum section: electronics / general

author: paulca
author_rank: Super Contributor
timestamp: October 07, 2022, 11:40:01 am
content: I wasn't expecting this to work to be honest. It does though.As per other power saving topics, I banished my gaming PC until it's needed to keep the room warm again. This unfortunately not only evicted me from my gaming setup, but my dev rig too.I was in the process of installing all the tools/ides/drivers on the mini desktop when it occured to me that I have a 16Gb i7-4790 mini-sever. If I use a VM for dev work I can install everything there and use it from any PC in the house!I installed a Windows 10, bought a cheap grey market HOME license for it (should have forked out for pro). Installed VSCode, fiddled with the VM USB settings and managed to get an ESP8266 flashed remotely.Obviously the caveat is... without utilising a USBoEthernet solution the USB programmers and MCUs have to physically live at the VM's host. I have not found this an issue for home use. If I'm coding downstairs in the living room and I crash an MCU so bad it needs power cycled, then I have to get some exercise.However the rewards quickly mounted to make the physical hub of MCUs hanging off the server (extension up onto the desk) easy to live with.Development files in all the IDEs are "local" as the main NAS drives are "local" to the VM, thus I have multiple ways of using what would otherwise have been "network drive" files, which cause lots of hassle with Windows native IDEs and make file build timestamp issues. Most of these go away when the two TCP stacks share the same CPU. There are other ways, for example, I can give the VM physical access to the under lying Linux disks... if I was feeling very stupid. I can also sync folders back and forward and run backups on and of the dev VM. I can create a virtual filesytem shared between host and guest only, a RAM disk, which syncs to an underlying Linux folder using sync-fs or overlay-fs, expand-fs etc... or if I'm feeling adventurous LVM volume caching. That takes care of annoying miss-functionality around mixed unix/windows paths and network mapped drives (looking at VSCode mostly).The Dev machine can run 24/7 as it's not using any more power sitting idle in an already idle host. The net power increase of running a VM is minimal (at idle). This makes it always, instantly available, right where I left off. All my windows from my last dev session are all still open. There is no "cold boot lag" as it's not been shutdown. It's just there, boom! I can run the current lab test project, close the VM windows, shut my PC down and go to bed. Fire up the TV and open the dev VM and check on progress before turning out the lights. In the morning when I fire up a PC and login, it's all still sitting there like I never left. Sure an MCU UART over USB connection might have timed out or crashed, but it's all still running fine.So far, I have successfully used 1xESP8266, 1xESP32, 1xSTLink Nucleo-64 board and a Logic Analyser on a USB hub successfully, at the same time remotely.

author: Berni
author_rank: Super Contributor
timestamp: October 07, 2022, 11:48:19 am
content: One way to go about it is using a Thunderbolt docking station.This gives you a box of native peripherals for a PC that is on the other end of a cable(including even a display). With fancy optical thunderbolt cables the said box can be 100m away from the PC. Using some Linux KVM magic you can pass those trough into a VM with enough performance to even do gaming on it, despite the PC being 100m away.

author: paulca
author_rank: Super Contributor
timestamp: October 07, 2022, 08:57:34 pm
content: There are USB over network plugins for VirtualBox, and in some ways you can have client USB access. I didn't need to go that far, so I didn't.To be honest I'm quite at home with STM32 Cube IDE. I use Eclipse in my day job, so I'm "right at home". Same for JetBrains IDEs.