Overview
Document Astrobe describes the set-up of the IDE, as well as the complementary definitions via module Config to provide the required configuration data that cannot be set in Astrobe.
Apart from the IDE, the Professional Editions also encompass command line tools for compiling and linking programs. OberonDev makes use of these tools to implement a simple IDE within the Sublime Text working environment.
Version v10 of Astrobe now provides command line tools that can also be run on other platforms on the basis of the .NET framework. The current experience is limited to Astrobe for Cortex-M0, the only product variant available as v10 as of this writing.
This document outlines the basics of running the tools on macOS. For my use, I have integrated them into OberonDev, since Sublime Text is available on macOS, and the corresponding Packages are cross-platform.
Mono
My current basis for running Windows programs on macOS is the Mono framework. As the large text box the the top of the website explains, the “stewardship” of the project has been taken over by WineHQ from Microsoft, and Microsoft has done integration work into their .NET efforts. Honestly, I don’t really understand all this yet in detail as regards future development and availability.
However, we can download a working release of Mono for macOS. It’s the same release we also could install using Homebrew. I have used the download from Mono’s project site, which installs the framework into /Library/Frameworks/Mono, and extends the $PATH for the corresponding binaries.
After executing the installer, running mono as means to run Astrobe’s command line programs just worked. Hence, for now we’re good, but need to keep an eye on the further developments regarding the Mono framework, or other means to run Windows programs on macOS.
Tools Installation
Copy the command line tools to suitable directories on the Mac, where they can be easily referenced from the command line, or scripts (see below). I would not install them in any of the Unix-y bin directories, since they cannot be run directly.
Running Astrobe’s Command Line Tools
There’s not a lot to say here – just run
$ mono AstrobeCompile.exe astrobeFolder configFile moduleFile from a shell to compile an Oberon module, or the other programs to recursively compile a module and all its IMPORTs as needed (AstrobeBuild.exe), or to link the compiled modules into a binary (AstrobeLink.exe). astrobeFolder is an optional parameter to denote the variable such as %AstrobeRP2040% used in the configFile for the library search path definition.
In my view, the command line tools should be used from a build system, which can be a set of simple shell scripts. I always use absolute file and directory paths for the programs and their parameters, which is straightforward from scripts (or OberonDev).
UF2 and Upload
The resulting program binary is a .bin file, which needs to be transmogrified into the .uf2 format, eg. using makeuf2. Use the corresponding options of makeuf2 to upload the program, or simply copy it to /Volumes/RPI-RP2 (RP2040) or /Volumes/RP2350 (RP2350), either in the Finder, or in the shell. Since the RP’s virtual drive unmounts itself immediately after receiving the .uf2 file, the Finder will complain about the drive not being unmounted properly. You can ignore the warning, but it’s annoying to have to dismiss it manually.
Required Changes
The library search path defined in the config .ini file needs to be changed to use forward slashes /. They remain compatible for Windows as well, and the Astrobe IDE and the command line tools on Windows work fine with the forward slashes.
Line Delimiters
Windows uses CRLF as line delimiter in text files, macOS uses the Unix-style LF. The Git repository stores text files using LF, and then checks out the files in the format native to the current platform. That is, on macOS we get text files with LF line delimiter. Since we’re running a Windows program on macOS, this can trip up the source line number identification when compiling a module. This shows as wrong line number inserted into the binary code, eg. for procedure calls, or the source line inserted into the assembly listing at different places compared to Windows.
The solution is to check out source files with the CRLF line ending on macOS. The repository’s .gitattributes file is now set to do that, ie. .mod files get the CRLF line delimiter also on macOS. Already checked out files will not be automatically checked out again, though, so we have to do this manually. There are numerous pieces of differing advice you can find on-line on how to achieve that, but none worked for me, so I ended up deleting the repository and all files, and cloning the repo again. Not elegant, but effective. Just make sure you don’t have any uncommitted local changes. If you’re cloning the repo on macOS now for the first time, all should be good from the beginning.