Grinder

May 23, 2019

Grinder - shared memory - inside view

The IRAF based control room software makes use of a shared memory segment. In fact there are 3 instances of this shared memory, each corresponding to one of the on-board computers. We are going to ignore this multiple instance business for now, and look at what is in one of these segments.

On the linux machines, these segments are 263748 bytes in size. They are probably the same on the old suns, but it is not as easy to find out. It would only be different if the C compilers did different structure padding, which is possible, but rather unlikely, and doesn't really matter anyway.

This size is the size of the "database" structure, which is defined in oven.h.

The shared memory segment is initialized like so in the init_database() function in init.c

	database        *db;

        db = (database *)shmalloc (sizeof(database), noven, ncomp, readonly);
        Gdb = db;
        Bdb = &db->biparameter;
        Pdb = &db->parameter;
        Idb = &db->intermediate;
        Ddb = &db->data;

A peek at oven.h shows:

typedef struct  {
        b_database      biparameter;
        p_database      parameter;
        i_database      intermediate;
        d_database      data;
        e_database      error;
} database;

There is also a highly instructive comment at the very end of oven.h which reads as follows:

   The total database is divided into parts according to usage.

   The parameters are modified only by the control room computers.
   The onboard computers only read the parameters and never modify them.
   The control room computer can update the parameters to the onboard,
   and can read them back for verification.
  
   The intermediate values are internal to the onboard computers and
   never need to be exchanged with the control room.
  
   The data values are produced, measured, computed, or derived on the
   onboard computers.  They may be read back to the control room but
   never modified by the control room.
  
   The bidirectional parameters have aspects of both "parameter" and
   "data" sections.  The control room may update these parameters to the
   onboard computers, but the onboard computers may (and usually do)
   modify these numbers.  Thus the control really should read back these
   values before modifying and updating them to the onboard computers.

So the control room software only deals with 4 parts of the database.

P (parameters) are written by control room, read-only by the V computers.
B (bi-params) can be written by either.
D (data) and E (errors) are written by the V computers, read-only by the control room.

Communication with the on-board computers

All of this is done through a pair of routines in ipportrw.c which makes is fairly easy to search. The routines are ipportread() and ipportwrite(). It turns out these are called only from database.c. Calls to these are wrapped in other functions, as follows:

db_pread_oven	PORTRP	p_database
db_bread_oven	PORTRB	b_database
db_dread_oven	PORT*	*_database	* = RB and RD to b_ and d_
db_eread_oven	PORTER	e_database
db_gread_oven	PORTGN	gong

db_pwrite_oven	PORTWP	p_database 	(for all computers)
db_bwrite_oven	PORTWB	b_database 	(for all computers)
db_bpwrite_oven		-- calls both the above

Writes are performed by calls from the menu system dbwog() and zzung() Reads are performed as follows:

hoven.c do_ovend()	--> db_dread_oven
hoven.c do_ovene()	--> db_eread_oven
hoven.c do_oveng()	--> db_gread_oven

menusc/db.c	dbrog	--> db_bread_oven
menusc/db.c	dbrdg	--> db_dread_oven
menusc/db.c	dbreg	--> db_eread_oven

Have any comments? Questions? Drop me a line!

Tom's home page / tom@mmto.org