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;
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 are handled as in
Oberon.Loop of EPO, apart from using a buffered RS232 device.1
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
Oberon sets up an alias for
Call, so existing modules such as
System don’t need to be adapted.2
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-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
cmdis installed during the system start sequence in the body of module
- 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
As an aside, without the buffer, as used in EPO, it’s possible to “miss” a command, if it’s issued too quickly after the preceding one. Try two
System.Directorycommands in quick sequence. The second might be missed. ↩︎
An additional type
ParRef, a pointer to
ParDesc, allows to create
Parin heap memory and aliasing via the corresponding pointer. ↩︎