Using Astrobe for Instrumentation Development
Synopsis. Astrobe is an alternative to the classic Oberon System. In this section I will outline how the Astrobe is different from the classic solution, and how to use it to develop Oberon instruments.

Motivation. Our advanced nuclear instruments do not need a comprehensive Oberon System GUI if they are operated remotely. If nobody is watching then why attach a screen and display anything? There is no need to devote a part of RAM to the framebuffer, and no need for the display software drivers. Eliminating these Oberon System components implies that programs can be neither edited nor compiled in situ. The former workstation is then changed to a fully embedded operating system, whose software is developed externally. This is exactly what Astrobe is proposing.

Background information. The original Oberon System was conceived as a standalone general purpose workstation programmed in Oberon language. It then evolved into many variants of essentially the same architecture running on top of other operating systems such as Linux, Windows, or Mac. Since the language, the compiler, and the run time are all very frugal, using Oberon for embedded programming should have been obvious. But it was not, probably because embedded programming has been dominated by C and its subculture. Except for Astrobe, Oberon somehow never became popular in the embedded community. A quick search with Google reveals that Astrobe is about the only link which pops up in response to "embedded Oberon".

What Astrobe is doing. Astrobe originated from the Oberon compiler for ARM by Professor Niklaus Wirth. Support for his RISC5 soft core was added later. In either case, Astrobe Oberon compiler operates on a regular PC host, where it cross compiles the Oberon program into an object code file, which is then downloaded to the target board. Cross-compilation is a typical development flow for most embedded software. What sets Astrobe apart from C is that the target board is running a subset of the original Oberon System. It is still the Oberon System, though without its GUI. The remaining parts are the Oberon module loader and the low level run time modules. These components, which Astrobe is targeting when it is sending the compiled code to the board, comprise an operating system kernel which is running on the target board. The kernel is the recipient of the object code compiled by Astrobe.

This approach is in stark contrast to bare metal programming practiced with most other embedded tools. In the bare metal approach, all the code is compiled and linked on a host, and then the entire executable is sent to the board and started from its initial instruction. In the Astrobe approach, the recipient of the compiled modules is running before the compiled code is sent. The code is delivered by Astrobe piece wise, one compiled module at a time. The embedded kernel receives the compiled module from the host. The module is then loaded into RAM, where it becomes a part of the already running system. This paradigm is similar to what a high level operating system would be doing on a regular workstation computer. The difference is that in the Astrobe case the compilation and the execution are performed on two different machines, the host PC and the target board.


The Astrobe advantage over bare metal. The advantage of Astrobe over the bare metal approach is that the recipient comprises a robust operating system kernel. If something goes wrong when loading the fresh module, the recipient can provide comprehensive diagnostics. Contrast this with the bare metal approach, where the recipient does not even exist. If something goes wrong with the bare metal, the lights just go off and this is about all that the programmer will know. The investigation will then begin, starting with blank LEDs. Not so with Astrobe!

The Astrobe advantage over the full Oberon System. The advantage of Astrobe over running the full Oberon System on a target board is that Astrobe needs less resources on the target. It does not need that much memory, because the compiler is running elsewhere and there is no need for a video framebuffer for the GUI. The frame buffer consumes 1024 x 768 bits (almost 100 kB) just for a B/W display. This is a significant memory for most lower end FPGAs. Saving memory on both counts, Astrobe can work with kilobytes rather than megabytes on the target. Typically, the entire Astrobe run time plus the compiled modules fit into the on-chip BRAM in case of the FPGA target board.

The overall CPU performance of the Astrobe Embedded Project Oberon is better than the original full Oberon System because video-related CPU stalls are not required (there is no video). The CPU clock can run at 40 MHz instead of 25 MHz, because the BRAM is faster than the external ASRAM memory used in the original full System.

Note about ZBT. The ASRAM chips limited the clock speed to 25 MHz in the original 2013 FPGA Oberon System. The ZBT memory would limit the CPU clock to 100 MHz. RISC5 is not yet capable of running at 100 MHz. Improving the RISC5 speed is in our plans sometime down the road.

Summary. Astrobe consists of the Oberon System divided into two pieces. The compiler is running on a host PC, augmented with the syntax-aware program editor. The Astrobe GUI was developed by Chris Burrows from scratch using Gardens Point Component Pascal (effectively Oberon for Windows .NET). The kernel part of the System is running on the target board. It comprises the collection of the run time modules, the file system modules, the SD card, the UART, and the module loader. All these are the original Oberon System modules with only minor modifications. The Astrobe kernel receives the compiled modules and loads them to RAM the same way, as the native Oberon System would do. The gain over running the entire Oberon System in one piece is that the Astrobe kernel can fit into much less RAM.

The gain of Astrobe over the typical bare metal C development is huge. The embedded C community is somehow not aware what they are missing.

Astrobe GUI is running on a host PC. The following figure (taken from the Astrobe website) shows the Astrobe GUI running on a host PC. The upper white-on-black window shows the Oberon System log where the Oberon System run time is sending the messages in response to the commands received from the lower window (black on white). Both windows would be executing on the same CPU if this was the classic Oberon. Here they are executing on two CPUs, the host and the target.


Astrobe kernel and application modules are running on a target board. The following figure (taken from the Astrobe website) shows the target board running the embedded Oberon kernel and the application modules compiled with Astrobe and uploaded to the target board.



Conclusion. Astrobe is similar to the Oberon System, but divided into two parts. The compiler is running on a PC host, while the run time Oberon kernel is running on a target board. The embedded part of the System can fit into a much smaller RAM than is required for the full Oberon System running natively on the board. The advantage of Astrobe over the bare metal programming is that the Oberon kernel offers a rich diagnostic is something goes wrong with the uploaded application code. In short, if you upload some code to the board running the kernel, then you are dealing with a high level embedded environment. In contrast, if you upload something to the bare metal, then there is nobody down there to respond in a sensible way in case of a crash.

Additional technical information about Astrobe provided by the Astrobe creator Chris Burrows. Because Astrobe utilises the Microsoft .NET Framework, a standard part of Windows, the entire distributable which is a single Windows Setup file is only 4 MB (Megabytes not Gigabytes) in size. This contains ALL of the software that is required to run Astrobe. The GUI was built with Gardens Point Component Pascal, while the syntax-sensitive editor was developed with commercial Editor.NET. Unlike open source equivalents which depend on multiple components that have to be acquired (in the correct versions) from multiple sources and then cobbled together to make them work, no other tools, packages, libraries etc. need to be downloaded, compiled etc. etc.

The Astrobe Build tool is additional to the tools provided with Project Oberon and helps to automate the development process. After you have edited several modules that make up an application (or the Project Oberon system itself), you then need to “build” the application. The Builder identifies all the dependencies. (I.e. all the modules that the application imports, which also takes care of hierarchical imports.) It then works out which ones need to be compiled according to the most recent compilation time. Astrobe also verifies whether interfaces of their imported modules have changed. The higher level modules will be recompiled, if this has happened. All these dependencies are topologically sorted so they are compiled in the correct sequence.

In order to upload the compiled files to the board, you only need to sort the directory listing according to the modification time, and highlight the desired items of the list. They will be then uploaded as a batch.

Contact us for more info

Updated June/12/2020.
© 2020 by SkuTek.com.