NOTE: This page describes creating tasks common to all of your projects/workspaces. If, instead, you wish to have your P2 compile and download tasks unique to each your projects then go to the Project Tasks page.
This document is being developed over time as we prove-out a working environment for macOS.
To date, we have installations, compilation and downloading from Windows, MacOS (this page), and RaspiOS (the Raspberry Pi OS - a Debian derived distribution).
Also, to date, we have building and download for flexprop, PNut-TS, and PNut (PNut is windows or windows emulator only.) with direct USB-attached boards.
In the future, we are also expecting to document building and download with via Wifi with the Wx boards attached to our development board, and with more compilers as they come ready for multi-platform use, etc.
On this Page:
- VSCode development of P2 Projects - basic development life-cycle
- P2 Code Development with FlexProp - setting up
- Being consistent in your machine configuration - why we are doing things this way
- Installation and Setup - preparing your machine for P2 development using tools from within vscode
- Tasks in VScode - this provides more detail about vscode tasks and lists work that is still needing to be done
Additional pages:
- TOP Level README - Back to the top page of this repo
- Migrate to v2.3.0 - checklist to ensure you have migrated to our latest configuration which supports locating installed compilers and compiling and downloading with any of the installed compilers to your USB attached P2
- Setup focused on Windows only - All Windows notes
- Setup focused on RPi only - All Raspberry Pi notes
- VSCode REF: Tasks - Offsite: VSCode Documentation for reference
NOTE: The "P2 Code Development..." sections below provide step-by-step setup instructions
Latest Updates:
31 Aug 2024
- Add PNut-TS notes and installation
- 12 Jun 2024
- Updated to reflect new Spin2 Extension built-in compile/download support
18 Jul 2023
- Misc updates to keep these pages in sync
15 Mar 2023
- Created this file from TASKS-User.md
By choosing to adopt the Custom Tasks described in this document along with the keybindings your work flow is now quite sweet.
- Create a new project
- Add existing files you have already created or are using from P2 Obex.
- Create your new top-level file.
- Add
{project}/.vscode/settings.jsonfile to identify the top-level file for the build tasks.
Iterate until your project works as desired:
- Make changes to file(s)
- Compile the files to see if they compile cleanly (cmd-shift-B) on which ever file you are editing
- Once the files compile cleanly
- Download and test (ctrl-shift-D, F10)
- Alternatively, download your project to FLASH and test (ctrl-shift-F, F11)
To complete your setup so you can use FlexProp on your mac under VScode you'll need to:
One time:
- Install FlexProp for all users to use on your Mac
- Add our tasks to the user tasks.json file (works across all your P2 projects)
(NOTE: there is no longer any tool-path informaton in this file!) - Remove any old compile/download keybindings you may have.
- Optionally add a couple of VSCode extensions if you wish to have the features I demonstrated
- "Error Lens" which adds the compile errors messages to the associated line of code
- "Explorer Exclude" which allows you to hide file types (e.g., .p2asm, .binary) from the explorer panel
For each P2 Project:
- Install a settings.json file identiyfing the project top-level file
- Make sure the name of your top-level file is correctly placed in this settings.json file
Additionally, you can use PNut-TS on your mac under VScode you'll need to:
One time:
- Install PNut-TS for all users to use on your Mac
- Add our tasks to the user tasks.json file (works across all your P2 projects)
- Remove any old compile/download keybindings you may have.
- Optionally add a couple of VSCode extensions if you wish to have the features I demonstrated
- "Error Lens" which adds the compile errors messages to the associated line of code
- "Explorer Exclude" which allows you to hide file types (e.g., .p2asm, .binary) from the explorer panel
For each P2 Project:
- Install a settings.json file identiyfing the project top-level file
- Make sure the name of your top-level file is correctly placed in this settings.json file
I have mostly macs for development but I also have a Windows machine and a number of Raspberry PIs (derived from Debian Linux distro.) and even some larger Ubuntu Machines (also derived from Debian Linux distro.). If you, like me, intend to be able to run VSCode on many of your development machines and you want to make your life easier then there are a couple of things we know already that can help you.
-
Synchronize your VSCode settings and extensions automatically by installing and using the Settings Sync VScode extension. Any changes you make to one machine then will be sync'd to your other VScode machines.
-
Be very consistent in where you install tools for each type of OS. (e.g., for all Windows machines make sure you install FlexProp, PNut-TS, and PNut, in the same location on each Windows machine.) By being consistent your tasks will run no matter which machine your are running on. There is nothing worse than trying to remember where you installed a specific tool on the machine you are currently logged into. Because you install say FlexProp in the same place on all your Raspberry Pi's you will know where to find it no matter which RPi you are logged in to.
- All like operating systems should have a specific tool installed in the same location on each. (e.g., all Windows machines have FlexProp installed in one location, all macOS machines have FlexProp installed in a different location that on Windows but it is the same location across all Macs, etc.)
- During installation of a tool on a machine, finish the process by configuring the PATH to the tool so that terminals/consoles can access the tool by name. This allows VSCode to run the tool from its build tasks.json file without needing to know where the tool is installed! On Windows machines this is done by editing the User Environment from within the Settings Application. On Mac's and Linux machines (RPi's) this is done by editing the shell configuration file (e.g., Bash you edit the ~/.bashrc file)
On MacOS machines we get the latest binaries by downloading a flexprop-{version}.zip file from the FlexProp Releases Page and upacking the zip file to produce a flexprop folder containing the new version.
NOTE: The FlexProp toolset does not have a standard install location. So we will likely have many locations amongst all of us P2 users. You have to take note of where you installed it and then adjust the following examples to point to where your binaries ended up on your file system. Alternatively, it should be safe to just follow what I do in these instructions explictly. This has the benefit that more of us will be able to help each other out with tools problems as more of us will be set up the same.
Next we move this new version into place.
On my Mac's, I install the FlexProp into a folder which I've created at /Applications/flexprop and I set the PATH to point to the /Applications/flexprop/bin directory. I move all of the content of the flexprop folder (created during the unzip) to the /Applications/flexprop folder.
If I'm updating to a new verison I do the following:
- Remove
/Applications/flexprop-prior - Rename the
/Applications/flexpropto/Applications/flexprop-prior - Create a new empty
/Applications/flexpropfolder - Move all of the content of the
flexpropfolder (created during the unzip) to the/Applications/flexpropfolder
NOTE: We use this move-aside technique for updating the FlexProp compiler. When a language compiler is updated more frequently it is not uncommon to one or twice a year experience a breaking change in how the new compiler handles your existing code. Assuming the version you are moving aside works well against all your projects, we move it aside and install the new version. Should you find that the new version doesn't work well against one of your projects you will still have the prior version so you can build the project with the older version that would fail with the new version. You can always skip this move-aside step if you don't care about this issue.
The packaging o PNut-TS for macOS for some reason, doesn't run (I'm working to understand this.) So as a workaround we install a Node.js runtime so we can run our compiler.
To see if you have Node.js installed (or to check what version you have installed) run:
$ node -v
v20.17.0 # output on authors Mac
$If you don't have it installed then visit Download Node.js® and download the installer appropriate to you Mac Processor. I For example, I run Apple Silicon and I've tested with v20.17.0 (LTS) on macOS running Arm64, and it just works. This installs in /usr/local/bin/ so you will want to make sure /usr/local/bin/ is in your PATH. Check this with:
$ whereis node
node: /usr/local/bin/node /usr/local/share/man/man1/node.1 # output on authors Mac
$Once you have node running and it's found in your PATH then you can proceed with installing PNut-TS.
On MacOS machines we get the latest binaries by downloading a {os-arch}.zip file from the PNut-TS Releases page under the [Assets] dropdown and upacking the zip file to produce a .dmg install image.
We double-click on the .dmg file to mount it. It opens a window, then, in the window, we drag the pnut_ts/ folder into the /Applications folder. Then the close the window and eject (unmount) the installer .dmg file.
Architecture specific PNut-TS .zip files available for MacOS:
| Archive Name | Operating System | Architecture | Unpack Leaves |
|---|---|---|---|
| macos-arm64.zip | MacOS | Arm 64 bit | macos-arm64.dmg |
| macos-x64.zip | MacOS | Intel x86-64 bit | macos-x64.dmg |
Get the latest binaries by downloading a {os-arch}.zip file from the PNut-TS Releases page under the [Assets] dropdown.
If you have an intel-based mac then get the x64 .zip file, if you have an Apple-silicon-based make then get the arm64 .zip file.
- Once you have your selected .zip file then double click on it to extract the .dmg file.
- next double-click on the .dmg file to mount this image. Accept the license agreement.
-
- after accespting the agreemnt a window showing to folders appears
- In the new window, drag the pnut_ts folder to the Applications folder.
- Close this window
- Eject the .dmg mounted image
If I'm updating to a new verison I do the following:
- Get the latest binaries by downloading a
{os-arch}.zipfile from the PNut-TS Releases page under the [Assets] dropdown. - Dounble click on the .zip file to extract the .dmg file
- Remove the
/Applications/pnut_ts-priorfolder (move to trash) - Rename the
/Applications/pnut_tsfolder to/Applications/pnut_ts-prior - Double click on the .dmg file to mount it. Accept the license agreement. A window opens showing two folders.
- In the window drag the new pnut_ts folder to the Applications folder
- Close the window
- Eject the .dmg image
NOTE: We use this move-aside technique for updating the PNut-TS compiler. When a language compiler is updated more frequently it is not uncommon to one or twice a year experience a breaking change in how the new compiler handles your existing code. Assuming the version you are moving aside works well against all your projects, we move it aside and install the new version. Should you find that the new version doesn't work well against one of your projects you will still have the prior version so you can build the project with the older version that would fail with the new version. You can always skip this move-aside step if you don't care about this issue.
On MacOS this is really shell dependent. I tend to stick with Bash as I've used it for many 10s of years now. zsh (ZShell) is the new shell on the block (well, new to mac's not a new shell.) I avoided moving to it but the concepts are the same.
On my Macs I install the flexprop folder into my /Applications folder. I then edit my .bash_profile and add the following line. (I have multiple lines such as this for various tools I've installed.)
export PATH=${PATH}:/Applications/flexprop/bin:/Applications/flexpropIf i have install PNut-TS then I also add its path:
export PATH=${PATH}:/Applications/pnut_tsFrom here on when I start new terminal windows we can invoke the flexprop binaries by name without using the path to them.
A Task is how we integrate with External tools in VScode.
See: VSCode "Tasks" Reference Page
There are a number of types of tasks and places Task definitions live. These include Auto-detected Tasks, User level tasks, and Custom Tasks. Tasks when run, can be crafted to depend upon the running of other tasks See: Compound Tasks Some tasks can be run in background such as file watchers which execute when a file has been changed.
When you run VScode on multiple operating systems and want to be able to run a projects tasks on whichever machine you are on then you can specify os-specific alternatives to be used withing the task. See Operating system specific properties
Another VSCode mechanism we are determining if it will be useful is the: Task Provider Extension. If we find this is useful we can add a Task Provder element to our existing extension in order to facilitate our updating task files we use for P1 and P2 development.
...More TBA...
Tasks can be invoked with the search, identify, run technique or they can have keyboard shortcuts assigned to them.
A project can have a single default build task which is, by default, invoked with command-shift-B.
We'll configure our compileP2 task to be the default.
We'll add a downloadP2 task and assign command-shift-D to it. It will depend upon the compile task which makes it run first and then we download the newly compiled result.
We'll add a flashP2 task and assign command-shift-F to it. It will depend upon the compile task which makes it run first and then we download the newly compiled result and write it to FLASH.
TODO-1: We need to ensure download or flash doesn't proceed if compile fails
TODO-2: We'll also test using the file-watch technology to automatically compile and download our project files when they are modified.
To define the tasks we are going to use with our P2 development in most of our projects we place the task definitions in a central "User Tasks" .json file.
To get to this file type in Ctrl+Shift+P (Cmd+Shift+P on mac) to get to the command search dialog. Then type in "tasks". Lower down in the resulting filtered list you should now see "Tasks: Open User Tasks". If prompted for a Task Template, select Others. Select it and you should now have a file open in the editor which should contain at least:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
]
}In between the [] you can place your new task definitions. You should end up with something like:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "compileP2",
"type": "shell",
"command": "${config:spin2.fSpecCompiler}",
"args": [
{
"value": "${command:spinExtension.getCompArguments}",
"quoting": "weak"
},
"${fileBasename}"
],
"problemMatcher": {
"owner": "Spin2",
"fileLocation": ["autoDetect", "${workspaceFolder}"],
"pattern": {
"regexp": "^(.*):(\\d+):\\s*(warning|error):\\s*(.*)$",
"file": 1,
"line": 2,
"severity": 3,
"message": 4
}
},
"presentation": {
"panel": "dedicated",
"focus": false,
"showReuseMessage": false,
"echo": true,
"clear": true,
"close": false,
"reveal": "always",
"revealProblems": "onProblem"
},
"group": {
"kind": "build",
"isDefault": true
}
},
{
"label": "compileTopP2",
"type": "shell",
"command": "${config:spin2.fSpecCompiler}",
"args": [
{
"value": "${command:spinExtension.getCompArguments}",
"quoting": "weak"
},
"${config:spin2.fNameTopLevel}"
],
"problemMatcher": {
"owner": "Spin2",
"fileLocation": ["autoDetect", "${workspaceFolder}"],
"pattern": {
"regexp": "^(.*):(\\d+):\\s*(warning|error):\\s*(.*)$",
"file": 1,
"line": 2,
"severity": 3,
"message": 4
}
},
"presentation": {
"panel": "dedicated",
"focus": false,
"showReuseMessage": false,
"echo": true,
"clear": true,
"close": false,
"reveal": "always",
"revealProblems": "onProblem"
},
"group": {
"kind": "build",
"isDefault": true
}
},
{
"label": "downloadP2",
"type": "shell",
"command": "${config:spin2.fSpecLoader}",
"args": [
{
"value": "${command:spinExtension.getLoaderArguments}",
"quoting": "weak"
},
"${config:spin2.optionsBinaryFname}"
],
"problemMatcher": {
"owner": "Spin2",
"fileLocation": ["autoDetect", "${workspaceFolder}"],
"pattern": {
"regexp": "^(.*):(\\d+):\\s*(warning|error):\\s*(.*)$",
"file": 1,
"line": 2,
"severity": 3,
"message": 4
}
},
"presentation": {
"panel": "dedicated",
"focus": false,
"showReuseMessage": false,
"echo": true,
"clear": true,
"close": false,
"reveal": "always",
"revealProblems": "onProblem"
},
"group": {
"kind": "test",
"isDefault": true
}
}
]
}This provides the following Build and Test tasks:
Under Task: Run Build Task:
- CompileP2 - Compile current file
- CompileTopP2 - Compile the top-file of this project
Under Task: Run Test Task:
- DownloadP2 - Download the binary to RAM in our connected P2
As written, downloadP2 for flexpsin will always be preceeded by a compileTopP2.
This new build system no longer uses custom keybindings. However, when migrating from the older build support we used you should remove any older P2 related keybindings as they can interfere with correct operation of the new build support.
The custom key bindings are found in the keybindings.json file.
To get to this file type in Ctrl+Shift+P (Cmd+Shift+P on mac) to get to the command search dialog. Then type in "keyboard". Lower down in the resulting filtered list you should now see "Preferences: Open Keyboard Shortcuts (JSON)". Select it and you should now have a file open in the editor which should contain something like:
// Place your key bindings in this file to override the defaultsauto[]
[
]NOTE: If you find entries like the following, then they need to be removed.
{
"key": "ctrl+shift+d",
"command": "workbench.action.tasks.runTask",
"args": "downloadP2"
},
{
"key": "ctrl+shift+f",
"command": "workbench.action.tasks.runTask",
"args": "flashP2"
},
{
"key": "F8",
"command": "workbench.action.tasks.build",
"args": "compileP2"
},
{
"key": "F10",
"command": "workbench.action.tasks.runTask",
"args": "downloadP2"
},
{
"key": "F11",
"command": "workbench.action.tasks.runTask",
"args": "flashP2"
}
If you still want to use these keys for build shortcuts, then you should remove the entries, and interactively specify keystrokes in the Keyboard Shortcuts editor. It will make entries that are correct for the new build system.
In order to support our notion of top-level file and to prevent us from occassionally compiling and downloading a file other than the project top-level file we've adopted the notion of adding a CompileTopP2 build task a DownloadP2 download task, and in some cases a FlashP2 task.
When we request a download or flash the automation will first compile the top-level project source which produces a new binary. It is this new binary that will be downloaded/flashed.
We have multiple tasks that need to know the name of our top-level file. So we add a new settings file with a topLevel value to our project:
.vscode/settings.json file contains the following contents:
{
"topLevel": "jm_p2-es_matrix_control_demo",
}
Once we have this file in place, then our tasks.json file can access this value using the form: ${config:topLevel}
Now our CompileTopP2 task can create the toplevel filename using ${config:topLevel}.spin2
You need to find the line containing "jm_p2-es_matrix_control_demo" and replace this name with the name of your top-level file.
And our DownloadP2 task can reference the binary file using ${config:topLevel}.binary
Licensed under the MIT License.
Follow these links for more information: