bobbrow
commented
1 year ago @benmcmorran @robotdad does this sound like something that would make sense for the Embedded extension to tackle? We've tried to stay mostly agnostic to specific embedded devices and this request feels pretty specific to embedded development. It feels like you'd want some kind of "quick start" command that would configure the build/testing/debugging based on the answers to a few questions you might ask along the way (e.g. a wizard)
Blackhex
duaneellissd
Feature Request
So a very simple case version of what I am looking for is this, but understand I am really looking for the third step.
Very Basic First Starter Step On your X64 Cross Compile a Linux C application for RASPBERRY PI (arm linux).
To debug, you must deploy the application to the remote machine and Launch a remote debugger using something like GDBSERVER and attach the GDB Debugger to that remote GDB Server.
A simple HELLO WORLD example would be great.
Here is an example: https://deardevices.com/2019/04/18/how-to-crosscompile-raspi/
NOTE: Additional note: Any form of simulating or MOCKING the hardware is a non-starter. Please do not require QEMU, it must be 100% Optional. REASON: Because while the R-PI is some what supported there are many other targets that are NOT SUPPORTED by QEMU - so the user must be able to skip step 4 and go direct to step 5.
Another example is to use the ARM cpu target as a bare metal target on a PYNQ (or ZYNQ) board.
Second Step
Use the C++/TEST MATE or other example and run unit tests on that remote target (ie: VSCODE presents a BEEKER icon, click on the beaker and and you can select a unit test to run on the remote machine).
Third Step
The target is no longer a RASPBERRY PI - the target is actually a small embedded device. For example one of these: https://learn.microsoft.com/en-us/azure-sphere/hardware/mt3620-reference-board-design
This third step is what I am really looking for - in my case it is a custom microcontroller board, similar to the MT3620 board but something else.
To make VSCODE unit test solution work, there are many many steps to get to this third stage that is is nearly impossible. I want to be proven wrong.
FOURTH STEP
As you will quickly learn, space and resources are limited in the embedded world. You will probably require 20 to 30 different build environments to build all of the different unit test configurations. Often just to make your code + unit test fit in the target you can only fit maybe 3 or 4 of your 20 to 30 total unit tests.
So you will learn that you need to be able to build (N+1) Variants for your various (N) UNIT TEST configurations, the +1 variant is for your final shippable product without any unit test framework present.
ANOTHER VARIANT (simpler then embedded but has similarities)
Run a LINUX machine on a HYPER-V virtual machine (or VMWARE machine) - you need to be able to SSH into he machine and run an application.
On your local Linux machine - compile an application and deploy the application to the remote Linux virtual machine and be able to debug the application.
Even better - be able to use the VSCODE unit test framework work to run unit tests (and debug) that remote application in unit test mode to.
Final Variant - Build on Linux Ubuntu - Deploy to WSL
Or the reverse, build on WSL for UBUNTU and deploy/run/test on a Linux machine - perhaps using SSH and/or a remote GDB Session.