This lastest build system is intended to be easier to set up, maintain, and to use than our original user tasks file mechanism.
This page attenpts to answer questions you may have as you are starting to use this build system.
We have a guided setup page Migrate from v2.2.x to v2.3.0 walking you through your initial setup of the new build system.
While the migration page has instructions for setting up your compilers on each of our supported platforms it is worth noting that if you are using a compiler installation location other than what we prescribe then as long as you have your environment variable PATH pointing to your compiler(s) then they should be found. If you find this to not be the case file an issue at our repository Issues Page and we will help you get this working.
Our compilers work with the following propeller chips:
| Compiler | works with |
|---|---|
| flexspin | P1 and P2 |
| pnut_ts | P2 only |
| PNut (Windows) | P2 only |
You will find that we have a built-in key sequence that allows you to compile the current file you are editing to check for errors. We also have a compile top file key sequence which compiles your entire project checking for errors (if you have specified a top file for your current workspace.)
NOTE: These key sequences are predefined for each platform. You will see that we didn't have the same key sequence available on all our platforms so the modifiers will be different on each.
At our initial release all the compilers can build for and download to P2 Ram or Flash. The selection of RAM or FLASH is done from the VSCode status bar toggle.
We are still certifying the download to P1 with flexspin but you may find it already works. If it doesn't it will be working shortly in an upcoming minor release.
We have a single key sequence for downloading to the P1 or P2. And just like the Compile key sequences this is also not the same on all platofrms, the modifiers are different on each platform.
When working with settings it's even more important, with the latest build feature, that you are aware of when you are adjusting User Settings or Workspace Settings. There is a tab for each at the top of your settings page:
Ensure you are in User or Workspace intentionally!
User settings are for all projects where you are using VSCode. Workspace settings are for the current workspace (project or folder.)
The current build settings, compiler paths, command line switches, etc. are stored only in Workspace settings.
NOTE: This is why when you visit the Spin2 -> Spin2 Workspace Build Environment the fields will all be empty if you have User tab selected. But if you, instead, select Workspace then most of them are filled in.
NOTE2: WARNING By the way, never adjust these Spin2 -> Spin2 Workspace Build Environment settings by hand. This is all managed by the Spin2 Extension at runtime.
If you find the VSCode status bar not affecting these behaviors during download, please check that you haven't set these settings in the User Settings (.json) file. If they get set there, the code seems to have a problem overriding these User Settings. They should only be in Workspace settings (.json), not User Settings. As soon as I can find a means to detect this, I'll add runtime warnings, if not prevention and cleanup of this condition.
There are a number of ways to get to your Keyboard bindings or to your settings. Here's one of the ways I use more often lately:
On the bottom left of your VSCode window:
Click on the Gear Icon
Now from the pop-up menu you can select Settings OR Keyboard Shortcuts:
Select from the Gear Menu
Again there a more ways to do this. This is just one of them.
When running the Spin2 extension built with output logging enabled you should should find two new pull-down values in the OUTPUT tab of the terminal window:
Pop-up menu with two new Extension Logs
From the pop-up menu in the OUTPUT tab, select the item Spin/Spin2 Extension DEBUG log, then you are seeing the log we want to see.
Now do a search in that window (CMD+F on macOS) and type in TOOL: and select case-sensitivity in the search dialog. You should then see somthing like this:
Terminal Window with OUTPUT tab selected and viewing
There should be a TOOL: line indicating each compiler or loader executable found. If some of them are missing then you can look in the TOOL: platofrmPaths=[...] list to see exactly what PATH values are being seen by the extension.
Remember: If you changed your PATH value then remember to shutdown and reload VSCode from within a new terminal that sees the new PATH value.
In the no good deed goes unpunished category, we have the fact that now that I'm tracking build parameters for each workspace in the workspace .vscode/settings.json file, it seems that the newly minted VSCode settings sync mechanisms which I use to keep VSCode in sync across all of my machines is now griping about not being able to merge the workspace files on the different machines. Merging would be really bad as each different OS uses different compilers, loaders, command-line switches, etc.
Well, I'm looking into how to solve this...
If you have questions about something not covered here let me know and I'll add more narrative here.
-Stephen
Licensed under the MIT License.
Follow these links for more information: