OASIS3 is a long overdue upgrade for the original OASIS controller, designed in 1991. Still, the original approach, architecture, and design goals are heavily borrowed from the old OASIS. The OASIS3 mechanical design, can, and can wiring are nearly identical to OASIS. For an overview of the original OASIS architecture, click here.
OASIS3 System - CPU Board on left, then 2 I/O Boards and 1Expansion Board
The OASIS3 hardware consists a backplane and three types of boards.
The backplane is a 7 slot backplane using 96-pin Euro-DIN connectors, similar to VME. Unlike VME, it's not a bus. Each slot is for a specific type of board, and the backplane wiring is mainly point-to-point. The 7 slots are used for:
The OASI3 CPU Board is the system controller, and is the only board required in an OASIS3 system. It contains:
14 TPU pins on the CF2 board are programmed to be 7 serial ports (7 Tx, 7 RX). Three of those serial ports are used on the OASIS3 CPU Board as noted above. The remaining 4 are pinned out to backplane slots 1-4, one for each slot; and thus one for each possible I/O board.
The OASIS3 CPU Board makes extensive use of the Serial Peripheral Interface (SPI) on the 68332 processor. There are 16 possible SPI "slots" (note - "slot" in this context means a decoded address, and has nothing to do with backplane slots). The CPU board decodes the addresses for 8 of those slots. It uses 2 SPI slots on the CPU board itself, and pins out the remaining 6 enables to the backplane for use by the other OASIS3 boards, as follows:
|
SPI Slot(s)
|
Used For
|
Board
|
|
0
|
Max146 A/D chip
|
A/D mezzanine on CPU Board (optional) |
|
1
|
Max7301 PIO chips (2)
|
CPU Board |
|
2
|
Max7301 PIO chip
|
I/O Board slot 1 |
|
3
|
Max7301 PIO chip
|
I/O Board slot 2 |
|
4
|
Max7301 PIO chip
|
I/O Board slot 3 |
|
5
|
Max7301 PIO chip
|
I/O Board slot 4 |
|
6-7
|
General purpose, unassigned
|
Pinned out to both backplane slots 5 & 6 |
SPI slot 1 selects two MAX7301 SPI PIO chips wired in series, yielding a total of 56 bits of general purpose parallel I/O. These are used for such things as: serial enables, relay drivers, wakeup bits, analog enable bits, ID lines to detect I/O boards, and general purpose I/O. See file spi.h for bit assignments.
Slots 1-4 are available for OASIS3 I/O Boards. Each OASIS3 I/O Board contains:
The intent is that each I/O board can interface to 7 serial instruments, with a multiplexed serial port and 12V power control for each instrument.
Backplane slots 5 & 6 are used for general purpose expansion boards. These may be used to implement such things as serial and power isolation, analog signal conditioning, or anything else not handled by the general purpose CPU and I/O boards. SPI slots 6-7 are decoded and pinned out to both backplane expansion slots. Thus one expansion backplane slot can use two SPI slots, or each backplane expansion slot can use one SPI slot.
The OASIS3 software was ported directly from OASIS, with changes for:
OASIS3 Software Architecture (with H/W)
The following sections detail the relationships of the various components of the "Software" section above, from the bottom software layer up.
The CF2 BIOS and PicoDOS are burned into the CF2 Flash memory at the factory, and are intended to always be present. The BIOS is the hardware dependent layer, and PicoDOS is a general purpose single-tasking OS and file system. Starting with PicoDOS version 2.28b1, these two components are combined into one, though Persistor's documentation still shows them separately.
OASIS3 uses these components more as a library for interfacing with CF2 hardware than as an OS. Since these components are single-tasking, there is a danger of having them break the OASIS3 multitasking. Much care was taken in insuring this doesn't occur; but this is why the higher-level OS functions were not used. Indeed, PicoDOS has a much richer and more general command-line parser than OASIS3. Unfortunately, it contains global variables and other constructs not appropriate to a multitasking environment, so it could not be used.
The O3 software designer consulted with Persistor representatives in deciding which components could be used.
Files: task.c, list.c, sem.c, malloc.c
This is the OASIS3 multitasking kernel. It implements non-preemptive task switching (aka cooperative multitasking), task delay, semaphores, and memory allocation. These facilities are used by all the upper layers of the software architecture.
Files: io.c, serial.c, spi.c
This is the software layer that talks to the OASIS3-specific hardware. Spi.c interfaces to the SPI (Serial Peripheral Interface) channels. Serial.c interfaces to the serial ports, maps the 32 virtual serial ports to the 8 UARTs (7 TPUs and 1 SCI), and maps to the CF2 BIOS routines that support these. Io.c takes care of the rest of the hardware, including interrupt routines, 100 Hz ticker, and provides a higher-level interface to the hardware supported by spi.c
Files: log.c, file.c
This module implements the OASIS3 data logger functions and interfaces to the file system for PicoDOS. One notable function provided by file.c is that it patches the low-level sector routines for PicoDOS, providing for a call to dispatch() after every sector-level read or write. This is because reading or writing large blocks can take several seconds, and OASIS3 (like OASIS) tries to conform to the convention that a task may only occupy the CPU for 1 tick (10 ms). Unfortunately, even with this trick, we don't quite make it; sector-level reads and writes may take 20 to 30 ms.
Files: All the driver sources listed in Instrument Driver Sources, drvTbl.h
These are the OASIS3 drivers, one for each possible instrument in the system.
Because we now have lots of memory space, the intention is to include drivers for all possible instruments in the system; and then simply change drvTbl.h for each deployment. As of this writing, though, only those instrument drivers that were used for 2003M2 and 2003M1 have been ported.
Files: oasis.c, drvr.c
Oasis.c contains the scheduler, and is the core of the OASIS3 software. It also contains the main() function, which means that it's the software that is first called after power-up.
When first called, main() is operating in a single-tasking environment. It calls the initialization functions for all the major subsystems, including the I/O system, serial I/O, and memory allocation. It then calls task_init(), which is a magic function.
Task_init() initializes the OASIS3 multitasking kernel. When it returns, the OASIS main function is no longer the only possible thread of execution. Instead, it becomes one of many possible threads, the scheduler/supervisor task.
The scheduler then finishes initialization (for those modules that need initialization in the multitasking environment), and then goes into an infinite loop, acting as the OASIS3 task scheduler and supervisor. Note that this function (originally the main function) never exits; it acts as scheduler/supervisor for the life of the system deployment, until the user initiates a reset.
As task scheduler, this task monitors the driver table to determine when it's time to schedule a driver task. When it's time, the scheduler calls task_create() to create a new task to sample the instrument. Each driver task runs to completion; that is, until it has completed sampling an instrument and logging the data. When the driver sample function returns, the task system deletes the task. The scheduler uses functions in drvr.c to help with all the above.
As supervisor, the scheduler/supervisor task watches to see when it's the only remaining task running in the system. When this happens, and no other driver is scheduled for some minimum time (currently 5 seconds, MIN_SLEEP_TIME in oasis.h), then the supervisor
In low-power sleep mode, all hardware except the real-time clock is disabled (put into sleep mode), and the system consumes approximately 1 milliamp at 12 volts.
When the calculated time has expired, the system wakes back up. The supervisor reinitializes the hardware that had been put to sleep, and starts scheduling driver tasks again.
Files: userif.c, usrcmds.c, usrcmd1.c, parm.c usrCmdTbl.h
This box is actually misplaced in the diagram in order to show the User IF separately. In fact, the lowest layer of the user interface is actually two drivers, usr_drv() and radio_drv(). Userif.c implements these two drivers and the command line parser.
The command line parser is a generalized table-driven parser. The command line parser takes user input and parses it to a function name and up to 3 parameters, which it then passes to the function found in the command table. The table that drives it is in usrCmdTbl.h (functbl), and you can add user commands by editing this file.
Usrcmds.c and usrcmd1.c implement the various functions in functbl. Parm.c contains the system parameters, which is used by both the "parm" user command and the configuration parser.
Files: utils.c, clock.c, config.c, parm.c, diag.c
Utils.c implements a number of useful utilities, including xprintf(), xputs(), etc. These are intended to be used in place of the standard I/O library routines printf(), puts(), etc. They supplement the standard I/O functions by being applied to the serial port that's in context for the driver that calls them, instead of always to the console port. They also are re-entrant, making them suitable for the OASIS3 multitasking environment.
Clock.c provides an interface between the real-time clock routines provided by PicoDOS (which conform to standard C usage) and the old-style clock functions of the old OASIS software.
Config.c implements the parser for OASIS.CFG. This provides the facility that allows the system integrator to configure the system via file, rather than recompiling. Parm.c provides the parsing of the system parameters.
Diag.c provides system diagnostics for the OASIS3 hardware. Running these diagnostics is mutually exclusive with normal instrument sampling, so when the user attempts to enter the diagnostics, dire warnings are first given.