Mplab Vscode
Gene Cryder
Building can be started by either using the command MPLABX: Build Project from the command pallet or creating a build task in .vscode/tasks.json. For a build to be successful, several auto-generated files are needed. These files can be generated by opening the project in MPLABX, or by running the MPLABX: Update private make files command.
However, it does have a few oddities, such as not taking arguments directly, opting instead to take them in view a "script file", and not releasing the reset line to the target device after programming when ran on macOS. The macOS issue is something that Microchip will need to address. To address the need for a script instead of command line arguments, the extension will automatically take all args and save them to a temporary file first, then the path of the script is passed to the mdb execution. If you would like to use the mdb command directly, you can override the behavior with the Mdb Command Args Redirect To Script setting.
The MPLABX Integrated Programming Environment (IPE) is an optional program that can be installed while installing the MPLABX Integrated Development Environment (IDE). This method provides a standard command line interface though, and works reliably on all operating systems that support MPLABX. However, it is an optional program, so care needs to be taken when installing MPLABX IDE to make sure MPLABX IPE is also installed.
This method is designed to be the easiest to use. All programer settings are pulled from the project file in nbproject/configuration.xml. This includes what tool to use and any voltage settings. If programer settings need to be changed, it is recommended to change them from withing MPLABX to prevent corrupting the project.
An issue was found with 4 series programers (e.g. PICKit4 and ICD4) that cause the programers to not work with the extension if settings were being sent. If settings are needed they can be selectively turned on using the Programer Tool Allow List setting
The names of programers do not match between the configuration file and the mdb tool. As such, the names of the tools need to matched up manually. If you would like to use a tool that is not listed below, please submit an issue on GitHub with the name of the tool listed in nbproject\configuration e.g. (pk4hybrid), or use the MDB debugging method
If you would like to modify tool options, such as providing power from the tool, they can be added to the toolOptions input. The best place to find the available option names is in a configuration.xml file that uses the given tool.
Use F5 or the run button on the debugger tab. The preLaunchTask item in the configuration will call the build task before connecting to the hwtool, programing, and starting. These tasks can take a while to execute.
The comparison table below is meant to assist MPLAB X Integrated Development Environment (IDE) users new to using Microsoft Visual Studio Code (VS Code) and thus the new MPLAB Extensions for VS Code. Each line describes either a development action or term for MPLAB X IDE and then for MPLAB Extensions.
MPLAB X IDE is based on Apache Netbeans, and a NetBeans workspace contains information about the configuration of the IDE. By default, there is only one workspace in Userdir/AppData/Roaming/mplab_ide/dev/vx.xx.
Debugging the project does not include building the project by default. However, when the launch.json file is created, an option to build prelaunch can be set, e.g.,
preLaunchTask: Example1: default - Full Build.
To select a variable or symbol in the code, right-click to select New Watch, and the New Watch window will have the variable or symbol already selected; just hit return to add it to the Watches window.
If you need to work with Microchip Support staff directly, you can submit a technical support case. Keep in mind that many questions can be answered through our self-help resources, so this may not be your speediest option.
We are happy to announce that we have released the Embedded Tools extension for Visual Studio Code. These capabilities are the same as what we recently announced for Visual Studio 2022. Used in conjunction with the new vcpkg artifact capabilities you can quickly bootstrap an embedded development machine and get started.
In this post we will walk you through how to acquire embedded tool dependencies with vcpkg, then demonstrate edit, build, deploy, and debugging directly in VS Code with new peripheral register and RTOS object views. We will demonstrate all of this with an Azure RTOS ThreadX project.
In the project folder, there is a file vcpkg_configuration.json. This manifest file was created with vcpkg and has recorded the tools you need to build and debug this project. See the vcpkg artifacts post for details on how to create your own manifest. Running the vcpkg activate command will use this file to determine if I have those tools, install them if I do not, then activate them in my environment for use.
In the previous section we used vcpkg to acquire the tools for our embedded project. Today vcpkg is not integrated in Visual Studio Code. So, at present we need to launch VS Code from the environment we activated at the command line so those tools are available for its use as well.
Now that we have the project open in VS Code it is ready to go as any other CMake project. VS Code can run the CMake build using the preconfigured CMakePresets file with the compilers vcpkg acquired. Select the preset arm-gcc-cortex-m4 when prompted on opening the folder.
To see how the launch is controlled in the sidebar open .vscode/launch.json and look at the launch configuration. You can see the miDebuggerPath set to use arm-none-eabi-gdb while the debugServerPath is set to invoke openocd with the configuration script in debugServerArgs. The information for describing peripheral registers is provided by the MCU manufacturer in an SVD file that we point to with svdPath. This project is configured to break on entry with the property stopAtConnect.
Now, with your board plugged into the PC with ST-LINK drivers installed, select the debug icon in the activity bar and make sure Run and Debug is set to Launch. Now F5 will work using openocd acquired by vcpkg to flash and debug the attached board. Execution stops at the entry function, so here we see the assembly code for that. We can also view the disassembly by right clicking the function in the call stack window, Open Disassembly View.
This will open the threads view that shows at a glance much of the information you would commonly need during embedded development, thread ids and names, how many times they have run, where the stack starts, ends, and its size as well as the maximum stack usage.
One last debugging capability to call out is that embedded hardware targets commonly have a limited set of hardware breakpoints available. Setting too many can corrupt the debugger state. As such we have added hardwareBreakpoints to launch.json. For this board that is set to what it supports which is 6. If we set more than that we will see the breakpoint is not set but will show as a gray empty circle.
We hope that these new capabilities will enable you to choose VS Code for your embedded development needs and make you more productive. We are very interested in your feedback to continue to improve this experience. The comments below are open, or you can find us on Twitter (@VisualC), or via email at visu...@microsoft.com.
One of the benefits of Great Cow Basic is that you do not need a complex IDE with a steep learning curve.
But If we are going to support a bloated IDE would it not be better to support MPLABx as a portable platform before spending resources on a proprietary IDE ?
Chris, I support your view.
Great Cow is operating system independent. I see no advantage in supporting a specialized proprietary platform.
Especially since it is known that in the long run you only negotiate disadvantages with it.
Although I have to admit that the sudden openness of Microsoft amazes me a lot
My thinking is that a Universal IDE like VS Code would bring GCB to more people.
After using GCB for a while we become familiar with the IDE, however there is a signifant learning curve for kids & new users.
I think this is why the Aruduino Platform is also now available on VS Code.
From my limited experience of VS Code, it should be quite easy to use it to edit a .gcb file, and have tasks for compile, build, upload etc.
Syntax highlighting and intelligent code completion sounds like it would be a bit more tricky, but I'm not sure by how much.
I've recently switched from the Arduino IDE to VSCode because it seems to compile and upload much faster and I like the syntax highlighting and intelligent code completion, but I still don't find it as intuitive as Arduino (or GCB & Synwrite).
I always thought gcb's best features were-
It's free, it was easy to program a uno.
If you can't do C then the arduino sketch ide is useless.
I never used mplab because I thought you needed to buy software to use basic but I coud be wrong.
It's a difficult choice. Make gcb seem easy to use for a beginner or make it seem useful for advanced programmers.
Maybe a "what do you use gcb for?" in the forum to see the users usage.
You can check how many times gcb has been downloaded but that doesn't mean users.
Bed's gcb home page is great. I'm sure it has attracted new users.
Picaxe is still going and it's commercial yet has many users...see the picaxe forum.
gcb is much better than picaxe but does it have as many users?
Not everyone is a widows expert either...so keep it simple please.
Is there anything stopping me using win notepad or notepad++ to write a program and save as gcb file and compile or the fb ide? Just wondering. When I first used gcb I used xloader to flash the hex file before I understood gcb.
Sorry but it read like using Visual Studio would make using gcb a better experience but I have a feeling that learning something new is not popular with some people...myself included.
I appreciate the effort people make to improve gcb but I'm thinking of non expert users like myself who finally get it working only for it to change..which gcb has done.