Commands and Upload

Commands, module upload, and start-up commands are handled by the same process, cmd, defined and implemented in module Cmds. This process is structured similar to EPO’s Oberon.Loop, sans the task invocation.

PROCEDURE cc;
  BEGIN
    set process period
    REPEAT
      yield control to scheduler
      IF a character from Astrobe is available THEN
        stop watchdog
        IF available character is REC THEN
          run uploader to receive file from Astrobe
        ELSE
          read command line
          IF command line is not empty THEN
            execute command
            IF error occurred THEN
              write error message to Astrobe console
            END
          END
        END
      ELSIF start-up command table is armed THEN
        stop watchdog
        get active start-up command table number
        FOR all command table entries DO
          IF command entry is not empty THEN
            execute command
            IF error occurred THEN
              log error
            END
          END
        END
        disarm start-up command table
      END
    UNTIL FALSE
  END cc;

Upload

Since Oberon RTS uses a buffered RS232 device to the IDE, its Upload.Run procedure is rewritten accordingly.

There is a known issue with Astrobe upload functionality when uploading more than one file (timeouts). Oberon RTS attempts to work around these issues, but there are limits what can be done, since the protocol has a flaw. The workaround is not shown in the above pseudo code. To be discussed elsewhere.

Commands

Commands are handled as in Oberon.Loop of EPO, apart from using a buffered RS232 device.¹

The type ParDesc and the module variable Par, which are used to scan the command line to access the command arguments, are defined and declared in module Cmds, as is the procedure Call. Module Oberon sets up an alias for Par and Call, so existing modules such as System don’t need to be adapted.²

Start-up Commands

Oberon RTS provides a set of tables with commands that will be executed sequentially upon system restart. Different tables allow different sets of start-up command sequences, eg. to start different control programs. The number of the currently active start-up command table is held in the FPGA and will survive a system restart. The commands themselves are defined in module Start.

Start-up commands are handled analogously to manually entered commands: they are read from a table in lieu from the console, and errors are logged, not printed to the console.

Installation and Watchdog

• Process cmd is installed during the system start sequence in the body of module Oberon.
• Uploading and command execution run with the watchdog disabled.

Commands can take substantial run-time, in particular if there’s lots of console output, such as with System.Directory, with hundreds of milliseconds. The corresponding serial driver uses an output buffer of 1k bytes, which is sufficient for speedy output of short messages, but not for long outputs. The current implementation will then fall back to busy-waiting upon buffer full, resulting in long run-times. Avoiding the busy-waiting will require some substantial changes to module Texts.