1015 lines
40 KiB
HTML
1015 lines
40 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
|
|
<title>EPICS Base R3.15.1 Release Notes</title>
|
|
</head>
|
|
|
|
<body lang="en">
|
|
<h1 align="center">EPICS Base Release 3.15.1</h1>
|
|
|
|
<h2 align="center">Changes between 3.15.0.2 and 3.15.1</h2>
|
|
|
|
<h3>epicsStrnEscapedFromRaw() and epicsStrnRawFromEscaped()</h3>
|
|
|
|
<p>These routines have been rewritten; the previous implementations did not
|
|
always behave exactly as specified.</p>
|
|
|
|
<h3>Shared Library Versions</h3>
|
|
|
|
<p>On architectures that can support it, the shared library version number for
|
|
libraries provided with Base has had the third component of the EPICS version
|
|
number added to it, thus libCom.so.3.15.1 instead of libCom.so.3.15. Windows
|
|
can only support two components to its internal product version number, and the
|
|
Darwin bug that external shared libraries were being built using the EPICS
|
|
version number has been fixed.</p>
|
|
|
|
<h3>Hooking into dbLoadRecords</h3>
|
|
|
|
<p>A function pointer hook has been added to the dbLoadRecords() routine, to
|
|
allow external modules such as autosave to be notified when new records have
|
|
been loaded during IOC initialization. The hook is called dbLoadRecordsHook and
|
|
follows the model of the recGblAlarmHook pointer in that modules that wish to
|
|
use it must save the current value of the pointer before installing their own
|
|
function pointer, and must call the original function from their own
|
|
routine.</p>
|
|
|
|
<p>The hook is activiated from the dbLoadRecords() routine and gets called only
|
|
after a database instance file has been read in without error. Note that the
|
|
dbLoadTemplates() routine directly calls dbLoadRecords() so this hook also
|
|
provides information about instantiated database templates. It is still possible
|
|
to load record instances using dbLoadDatabase() though, and doing this will not
|
|
result in the hook routines being called.</p>
|
|
|
|
<p>Code to use this hook should look something like this:</p>
|
|
|
|
<blockquote><pre>
|
|
#include "dbAccessDefs.h"
|
|
|
|
static DB_LOAD_RECORDS_HOOK_ROUTINE previousHook;
|
|
|
|
static void myRoutine(const char* file, const char* subs) {
|
|
if (previousHook)
|
|
previousHook(file, subs);
|
|
|
|
/* Do whatever ... */
|
|
}
|
|
|
|
void myInit(void) {
|
|
static int done = 0;
|
|
|
|
if (!done) {
|
|
previousHook = dbLoadRecordsHook;
|
|
dbLoadRecordsHook = myRoutine;
|
|
done = 1;
|
|
}
|
|
}
|
|
</pre></blockquote>
|
|
|
|
<p>As with many other parts of the static database access library there is no
|
|
mutex to protect the function pointer. Initialization is expected to take place
|
|
in the context of the IOC's main thread, from either a static C++ constructor or
|
|
an EPICS registrar routine.</p>
|
|
|
|
|
|
<h2 align="center">Changes between 3.15.0.1 and 3.15.0.2</h2>
|
|
|
|
<h3>New iocshLoad command</h3>
|
|
|
|
<p>A new command <tt>iocshLoad</tt> has been added to iocsh which executes a
|
|
named iocsh script and can also set one or more shell macro variables at the
|
|
same time, the values of which will be forgotten immediately after the named
|
|
script finishes executing. The following example shows the syntax:</p>
|
|
|
|
<blockquote><pre>
|
|
iocshLoad "serial.cmd", "DEV=/dev/ttyS0,PORT=com1,TYPE=RS485"
|
|
iocshLoad "radmon.cmd", "PORT=com1,ADDR=0"
|
|
</pre></blockquote>
|
|
|
|
<h3>Support routines for 64-bit integers</h3>
|
|
|
|
<p>The libCom library now provides support for 64-bit integer types on all
|
|
supported architectures. The epicsTypes.h header file defines epicsInt64 and
|
|
epicsUInt64 type definitions for both C and C++ code. The epicsStdlib.h header
|
|
also declares the following for parsing strings into the relevent sized integer
|
|
variables: Functions epicsParseLLong(), epicsParseULLong() with related macros
|
|
epicsScanLLong() and epicsScanULLong(), and the functions epicsParseInt64()
|
|
and epicsParseUInt64(). Use the first two functions and the macros for long long
|
|
and unsigned long long integer types, and the last two functions for the
|
|
epicsInt64 and epicsUInt64 types. Note that the latter can map to the types long
|
|
and unsigned long on some 64-bit architectures such as linux-x86_64, not to the
|
|
two long long types.</p>
|
|
|
|
<p>This version does not provide the ability to define 64-bit record fields, the
|
|
use of the 64-bit types in the IOC database will come in a later release of
|
|
EPICS Base.</p>
|
|
|
|
<h3>Full support for loadable support modules</h3>
|
|
|
|
<p>Apparently later versions of Base 3.14 permitted support modules to be loaded
|
|
from a shared library at runtime without the IOC having been linked against that
|
|
shared library; the registerRecordDeviceDriver.pl program would accept a partial
|
|
DBD file containing just the entries needed for the library and generate the
|
|
appropriate registration code. In 3.15 however the registerRecordDeviceDriver.pl
|
|
program was replaced by one using the new DBD file parser, and in this a device
|
|
support entry would only be accepted after first loading the record type that it
|
|
depended on.</p>
|
|
|
|
<p>The parser has been modified to accept device entries without having seen the
|
|
record type first, although a warning is given when that happens. To remove the
|
|
warning the DBD file can provide a record type declaration instead (no fields
|
|
can be defined, so the braces must be empty), before the device() entry. The
|
|
result will generate the correct registration code for the device entry without
|
|
including anything for any merely declared record types. The generated code can
|
|
be linked into a shared library and loaded by an IOC at runtime using dlload.
|
|
</p>
|
|
|
|
<h3>Parallel callback threads</h3>
|
|
|
|
<p>The general purpose callback facility can run multiple parallel callback
|
|
threads per priority level. This makes better use of SMP architectures (e.g.
|
|
processors with multiple cores), as callback work - which includes second
|
|
stage processing of records with asynchronuous device support and I/O
|
|
scanned processing - can be distributed over the available CPUs.</p>
|
|
|
|
<p>Note that by using parallel callback threads the order of scan callback
|
|
requests in the queue is not retained. If a device support needs to be
|
|
informed when scanIoRequest processing has finished, it should use the new
|
|
scanIoSetComplete() feature to add a user function that will be called after
|
|
the scanIoRequest record processing has finished.</p>
|
|
|
|
<p>Parallel callback threads have to be explicitly configured, by default
|
|
the IOC keeps the old behavior of running one callback thread per priority.</p>
|
|
|
|
<h3>Merge MMIO API from devLib2</h3>
|
|
|
|
<p>Added calls to handle 8, 16, and 32 bit Memory Mapped I/O reads and writes.
|
|
The calls added include <tt><i>X</i>_iowrite<i>Y</i>()</tt> and
|
|
<tt><i>X</i>_ioread<i>Y</i>()</tt>
|
|
where <tt><i>X</i></tt> is <tt>nat</tt> (native), <tt>be</tt> or <tt>le</tt>,
|
|
and <tt><i>Y</i></tt> is <tt>16</tt> or <tt>32</tt>.
|
|
Also added are <tt>ioread8()</tt> and <tt>iowrite8()</tt>.</p>
|
|
|
|
<h3>Added optional dbServer API to database</h3>
|
|
|
|
<p>A server layer that sits on top of the IOC database may now register itself
|
|
as such by calling <tt>dbRegisterServer()</tt> and providing optional routines
|
|
that other components can use. The initial purpose of this API allows the Trace
|
|
Processing implementation in <tt>dbProcess()</tt> to identify a client that
|
|
causes a record to process when TPRO is set.</p>
|
|
|
|
<p>To support the client idenfication, the server provides a routine that
|
|
returns that identity string when called by one of its own processing
|
|
threads.</p>
|
|
|
|
<h3>Concatenated database definition files</h3>
|
|
|
|
<p>A series of database definition (dbd) files can now be concatenated during
|
|
the build process into a newly-created dbd file with result being installed into
|
|
$(INSTALL_LOCATION)/dbd without expanding it.</p>
|
|
|
|
<p>The following lines in an EPICS Makefile will create a file name.dbd in the
|
|
O.Common build directory containing the contents of file1.dbd followed by
|
|
file2.dbd then file3.dbd. The new file will then be installed into
|
|
$(INSTALL_LOCATION)/dbd without expanding any of its include statements.</p>
|
|
|
|
<blockquote><pre>
|
|
DBDCAT += name.dbd
|
|
name_DBD += file1.dbd file2.dbd file3.dbd
|
|
</pre></blockquote>
|
|
|
|
<p>The source files file1.dbd, file2.dbd and file3.dbd may be created by the
|
|
current Makefile, be located in the parent directory or any other directory in
|
|
the SRC_DIRS list, be specified by their full pathname, exist in the install dbd
|
|
directory, or be found in any dbd directory linked from the application's
|
|
RELEASE files.</p>
|
|
|
|
<h3>Posix: Drop SCHED_FIFO before exec() in child process</h3>
|
|
|
|
<p>If Base is compiled with <tt>USE_POSIX_THREAD_PRIORITY_SCHEDULING = YES</tt>
|
|
in configure/CONFIG_SITE or related files, the Posix implementation of the
|
|
libCom <tt>osiSpawnDetachedProcess()</tt> routine will switch the child process
|
|
to use the normal SCHED_OTHER (non real-time) scheduler before executing the
|
|
named executable program. If it needs to use the real-time scheduler the new
|
|
program can request that for itself.</p>
|
|
|
|
<h3>Posix: Lock all memory when running with FIFO scheduler</h3>
|
|
|
|
<p>On Posix systems, an IOC application's ability to meet timing deadlines is
|
|
often dependent on its ability to lock part or all of the process's virtual
|
|
address space into RAM, preventing that memory from being paged to the swap
|
|
area. This change will attempt to lock the process's virtual address space into
|
|
RAM if the process has the ability to run threads with different priorities. If
|
|
unsuccessful, it prints an message to stderr and continues.</p>
|
|
|
|
<p>On Linux, one can grant a process the ability to run threads with different
|
|
priorities by using the command <code>ulimit -r unlimited</code>. To use the
|
|
FIFO scheduler for an IOC, use a command like this:</p>
|
|
|
|
<blockquote><pre>chrt -f 1 softIoc -d test.db</pre></blockquote>
|
|
|
|
<p>On Linux, one can grant a process the ability to lock itself into memory
|
|
using the command <code>ulimit -l unlimited</code>. These limits can also be
|
|
configured on a per user/per group basis by changing /etc/security/limits.conf
|
|
or its equivalent.</p>
|
|
|
|
<p>A child process created via fork() normally inherits its parent's resource
|
|
limits, so a child of a real-time soft-IOC will get its parent's real-time
|
|
priority and memlock limits. The memory locks themselves however are not
|
|
inherited by child processes.</p>
|
|
|
|
<h3>Implement EPICS_CAS_INTF_ADDR_LIST in rsrv</h3>
|
|
|
|
<p>The IOC server can now bind to a single IP address (and optional port number)
|
|
read from the standard environment parameter EPICS_CAS_INTF_ADDR_LIST.
|
|
Additional addresses included in that parameter after the first will be ignored
|
|
and a warning message displayed at iocInit time.</p>
|
|
|
|
<h3>alarmString.h deprecated again</h3>
|
|
|
|
<p>The string arrays that provide string versions of the alarm status and
|
|
severity values have been moved into libCom and the header file that used to
|
|
instanciate them is no longer required, although a copy is still provided for
|
|
backwards compatibility reasons. Only the alarm.h header needs to be included
|
|
now to declare the epicsAlarmSeverityStrings and epicsAlarmConditionStrings
|
|
arrays.</p>
|
|
|
|
<h3>General purpose thread pool</h3>
|
|
|
|
<p>
|
|
A general purpose threaded work queue API epicsThreadPool is added.
|
|
Multiple pools can be created with controlable priority and number
|
|
of worker threads. Lazy worker startup is supported.</p>
|
|
|
|
<h3>Database field setting updates</h3>
|
|
|
|
<p>A database (.db) file loaded by an IOC does not have to repeat the record
|
|
type of a record that has already been loaded. It may replace the first
|
|
parameter of the <tt>record(type, name)</tt> statement with an asterisk
|
|
character inside double-quotes, <tt>"*"</tt> instead. Thus the following is a
|
|
legal database file:</p>
|
|
|
|
<blockquote><pre>record(ao, "ao1") {}
|
|
record("*", "ao1") {
|
|
field(VAL, 10)
|
|
}</pre></blockquote>
|
|
|
|
<p>Note that database configuration tools will not be expected to have to
|
|
understand this syntax, which is provided for scripted and hand-coded database
|
|
and template instantiation only. Setting the IOC's <tt>dbRecordsOnceOnly</tt>
|
|
flag also makes this syntax illegal, since its purpose is to prevent
|
|
multiply-defined records from being collapsed into a single instance.</p>
|
|
|
|
<h3>Added echo command to iocsh</h3>
|
|
|
|
<p>The single argument string may contain escaped characters, which will be
|
|
translated to their raw form before being printed (enclose the string in quotes
|
|
to avoid double-translation). A newline is always appended to the output, and
|
|
output stream redirection is supported.</p>
|
|
|
|
<h3>Added macro EPICS_UNUSED to compilerDependencies.h</h3>
|
|
|
|
<p>To prevent the compiler from warning about a known-unused variable, mark it
|
|
with the macro EPICS_UNUSED. On gcc and clang this will expand to
|
|
<tt>__attribute__((unused))</tt> to prevent the warning.</p>
|
|
|
|
<h3>User specified db substitution file suffix</h3>
|
|
|
|
<p>Per Dirk Zimoch's suggestion, a user specified db substitution file suffix is
|
|
now allowed by setting the variable SUBST_SUFFIX in a configuration directory
|
|
CONFIG_SITE file or in a Makefile before the include $(TOP)/configure/RULES
|
|
line. The default for SUBST_SUFFIX is <tt>.substitutions</tt></p>
|
|
|
|
<h3>NTP Time Provider adjusts to OS tick rate changes</h3>
|
|
|
|
<p>Dirk Zimoch provided code that allows the NTP Time provider (used on VxWorks
|
|
and RTEMS only) to adapt to changes in the OS clock tick rate after the provider
|
|
has been initialized. Note that changing the tick rate after iocInit() is not
|
|
advisable, and that other software might still misbehave if initialized before
|
|
an OS tick rate change.</p>
|
|
|
|
<h3>Added newEpicsMutex macro</h3>
|
|
|
|
<p>Internal C++ uses of <tt>new epicsMutex()</tt> have been replaced with a new
|
|
macro which calls a new constructor, passing it the file name and line number of
|
|
the mutex creation code. C code that creates mutexes has been using a similar
|
|
macro for a long time, but there was no equivalent constructor for the C++
|
|
wrapper class, so identifying a specific mutex was much harder to do.</p>
|
|
|
|
<h3>Post DBE_PROPERTY events automatically</h3>
|
|
|
|
<p>A new record field attribute "prop(YES)" has been added to identify fields
|
|
holding meta-data. External changes to these fields will cause a CA monitor
|
|
event to be sent to all record subscribers who have asked for DBE_PROPERTY
|
|
updates. Meta-data fields have been marked for all Base record types.</p>
|
|
|
|
<h3>errlogRemoveListener() routine changed</h3>
|
|
|
|
<p>Code that calls <tt>errlogRemoveListener(myfunc)</tt> must be modified to use
|
|
the new, safer routine <tt>errlogRemoveListeners(myfunc, &pvt)</tt> instead.
|
|
The replacement routine takes a second argument which must be the same private
|
|
pointer that was passed to <tt>errlogAddListener()</tt> when adding that
|
|
listener. It also deletes all matching listeners (hence the new plural name) and
|
|
returns how many were actually deleted, whereas the previous routine only
|
|
removed the first listener that matched.</p>
|
|
|
|
<h3>Simplified generation of .dbd files</h3>
|
|
|
|
<p>The Perl script <tt>makeIncludeDbd.pl</tt> has been removed and the rules
|
|
that created an intermediate <tt><i>xxx</i>Include.dbd</tt> file from the
|
|
Makefile variable <tt>xxx_DBD</tt> have been modified to generate the target
|
|
<tt><i>xxx</i>.dbd</tt> file directly. This should simplify applications that
|
|
might have had to provide dependency rules for the intermediate files in 3.15.
|
|
Applications which provide their own <tt><i>xxx</i>Include.dbd</tt> source file
|
|
will continue to have it expanded as before.</p>
|
|
|
|
<h3>New Undefined Severity field UDFS</h3>
|
|
|
|
<p>A new field has been added to dbCommon which configures the alarm severity
|
|
associated with the record being undefined (when UDF=TRUE). The default value is
|
|
INVALID so old databases will not be affected, but now individual records can be
|
|
configured to have a lower severity or even no alarm when undefined. Be careful
|
|
when changing this on applications where the IVOA field of output records is
|
|
used, IVOA still requires an INVALID severity to trigger value replacement.</p>
|
|
|
|
<h3>New build target <q>tapfiles</q></h3>
|
|
|
|
<p>This new make target runs the same tests as the <q>runtests</q> target, but
|
|
instead of summarizing or displaying the output for each test script it creates
|
|
a <q>.tap</q> file inside the architecture build directory which contains the
|
|
detailed test output. The output file can be parsed by continuous integration
|
|
packages such as <a href="http://www.jenkins-ci.org/">Jenkins</a> to show the
|
|
test results.</p>
|
|
|
|
<h3>Array field double-buffering</h3>
|
|
|
|
<p>Array data can now be moved, without copying, into and out of the VAL field
|
|
of the waveform, aai, and aao record types by replacing the pointer in BPTR.
|
|
The basic rules which device support must follow are:</p>
|
|
|
|
<ol>
|
|
<li>BPTR, and the memory it is currently pointing to, can only be accessed
|
|
while the record is locked.</li>
|
|
<li>NELM may not be changed; NORD should be updated whenever the number of
|
|
valid data elements changes.</li>
|
|
<li>When BPTR is replaced it must always point to a block of memory large
|
|
enough to hold the maximum number of elements, as given by the NELM and
|
|
FTVL fields.</li>
|
|
</ol>
|
|
|
|
<h3>Spin-locks API added</h3>
|
|
|
|
<p>The new header file epicsSpin.h adds a portable spin-locks API which is
|
|
intended for locking very short sections of code (typically one or two lines of
|
|
C or C++) to provide a critical section that protects against race conditions.
|
|
On Posix platforms this uses the pthread_spinlock_t type if it's available and
|
|
the build is not configured to use Posix thread priorities, but otherwise it
|
|
falls back to a pthread_mutex_t. On the UP VxWorks and RTEMS platforms the
|
|
implementations lock out CPU interrupts and disable task preemption while a
|
|
spin-lock is held. The default implementation (used when no other implementation
|
|
is provided) uses an epicsMutex. Spin-locks may not be taken recursively, and
|
|
the code inside the critical section should be short and deterministic.</p>
|
|
|
|
<h3>Improvements to aToIPAddr()</h3>
|
|
|
|
<p>The libCom routine aToIPAddr() and the vxWorks implementation of the
|
|
associated hostToIPAddr() function have been modified to be able to look up
|
|
hostnames that begin with one or more digits. The epicsSockResolveTest program
|
|
was added to check this functionality.</p>
|
|
|
|
<h3>mbboDirect and mbbiDirect records</h3>
|
|
|
|
<p>These record types have undergone some significant rework, and will behave
|
|
slightly differently than they did in their 3.14 versions. The externally
|
|
visible changes are as follows:</p>
|
|
|
|
<h5>mbbiDirect</h5>
|
|
|
|
<ul>
|
|
<li>If the MASK field is set in a database file, it will not be over-written
|
|
when the record is initialized. This allows non-contiguous masks to be set,
|
|
although only the device support actually uses the MASK field.</li>
|
|
<li>If process() finds the UDF field to be set, the record will raise a
|
|
UDF/INVALID alarm.</li>
|
|
</ul>
|
|
|
|
<h5>mbboDirect</h5>
|
|
|
|
<ul>
|
|
<li>If the MASK field is set in a database file, it will not be over-written
|
|
when the record is initialized. This allows non-contiguous masks to be set,
|
|
although only the device support actually uses the MASK field.</li>
|
|
<li>After the device support's init_record() routine returns during record
|
|
initialization, if OMSL is <q>supervisory</q> and UDF is clear the fields
|
|
B0-BF will be set from the current VAL field.</li>
|
|
<li>When a put to the OMSL field sets it to <q>supervisory</q>, the fields
|
|
B0-BF will be set from the current VAL field. This did not used to happen,
|
|
the individual bit fields were previously never modified by the record.
|
|
Note that this change may require some databases to be modified, if they
|
|
were designed to take advantage of the previous behavior.</li>
|
|
</ul>
|
|
|
|
<h3>Redirection of the errlog console stream</h3>
|
|
|
|
<p>A new routine has been added to the errlog facility which allows the console
|
|
error message stream to be redirected from stderr to some other already open
|
|
file stream:</p>
|
|
|
|
<blockquote><pre>int errlogSetConsole(FILE *stream);
|
|
</pre></blockquote>
|
|
|
|
<p>The stream argument must be a FILE* pointer as returned by fopen() that is
|
|
open for output. If NULL is passed in, the errlog thread's stderr output stream
|
|
will be used instead. Note that messages to the console can be disabled and
|
|
re-enabled using the eltc routine which is also an iocsh command, but there is
|
|
no iocsh command currently provided for calling errlogSetConsole.</p>
|
|
|
|
<h3>Add cleanup subroutine to aSub record</h3>
|
|
|
|
<p>An aSub routine may set the CADR field with a function pointer which will be
|
|
run before a new routine in the event that a change to the SNAM field changes
|
|
the record's process subroutine.</p>
|
|
|
|
<p>This can be used to free any resources the routine needs to allocate. It can
|
|
also be used to determine if this is the first time this routine has been called
|
|
by this record instance. The CADR field is set to NULL immediately after the
|
|
routine it points to is called.</p>
|
|
|
|
<p>Example:</p>
|
|
|
|
<blockquote><pre>void cleanup(aSubRecord* prec) {
|
|
free(prec->dpvt);
|
|
prec->dpvt = NULL;
|
|
}
|
|
|
|
long myAsubRoutine(aSubRecord* prec) {
|
|
if (!prec->cadr) {
|
|
/* check types of inputs and outputs */
|
|
if (prec->ftva != menuFtypeDOUBLE)
|
|
return 1; /* oops */
|
|
|
|
dpvt = malloc(42);
|
|
prec->cadr = &cleanup;
|
|
}
|
|
|
|
/* normal processing */
|
|
}
|
|
epicsRegisterFunction(myAsubRoutine);
|
|
</pre></blockquote>
|
|
|
|
<h3>Sequence record enhancements</h3>
|
|
|
|
<p>The sequence record type now has 16 link groups numbered 0 through 9 and A
|
|
through F, instead of the previous 10 groups numbered 1 through 9 and A. The
|
|
changes to this record are directly equivalent to those described below for the
|
|
fanout record. The fields OFFS and SHFT have been added and operate on the SELN
|
|
value exactly the same way. The result is backwards compatible with the 3.14
|
|
version of the sequence record as long as none of the new fields are modified
|
|
and the application does not rely on the SOFT/INVALID alarm that was generated
|
|
when the selection number exceeded 10. The record also now posts monitors on the
|
|
SELN field at the end of the sequence if its value changed when read through the
|
|
SELL link.
|
|
|
|
<h3>Fanout record enhancements</h3>
|
|
|
|
<p>The fanout record type now has 16 output links LNK0-LNK9 and LNKA-LNKF, plus
|
|
two additional fields which make the result backwards compatible with 3.14
|
|
databases, but also allow the link selection to be shifted without having to
|
|
process the SELN value through a calc or calcout record first.</p>
|
|
|
|
<p>Previously there was no LNK0 field, so when SELM is <q>Mask</q> bit 0 of SELN
|
|
controls whether the LNK1 link field was activated; bit 1 controls LNK2 and so
|
|
on. When SELM is <q>Specified</q> and SELN is zero no output link would be
|
|
activated at all; LNK1 gets activated when SELN is 1 and so on. Only 6 links
|
|
were provided, LNK1 through LNK6. The updated record type maintains the original
|
|
behavior when the new fields are not configured, except that the SOFT/INVALID
|
|
alarm is not generated when SELN is 7 through 15.</p>
|
|
|
|
<p>The update involved adding a LNK0 field, as well as fields LNK7 through LNK9
|
|
and LNKA through LNKF. To add flexibility and maintain backwards compatibility,
|
|
two additional fields have been added:</p>
|
|
|
|
<dl>
|
|
<dt><b>OFFS</b></dt>
|
|
|
|
<dd>This field holds a signed offset which is added to SELN to select which link
|
|
to activate when SELM is <q>Specified</q>. If the resulting value is outside the
|
|
range 0 .. 15 the record will go into a SOFT/INVALID alarm state. The default
|
|
value of OFFS is zero, so if it is not explicitly set and SELN is 1 the LNK1
|
|
link will be activated.</dd>
|
|
|
|
<dt><b>SHFT</b></dt>
|
|
|
|
<dd>When SELM is <q>Mask</q> the signed field SHFT is used to shift the SELN
|
|
value by SHFT bits (positive means right-wards, values outside the range -15 ..
|
|
15 will result in a SOFT/INVALID alarm), before using the resulting bit-pattern
|
|
to control which links to activate. The default value is -1, so if SHFT is not
|
|
explicitly set bit 0 of SELN will be used to control whether LNK1 gets
|
|
activated.</dd>
|
|
|
|
</dl>
|
|
|
|
<p>The record also now posts monitors on the SELN field if it changes as a
|
|
result of record processing (i.e. when read through the SELL link).</p>
|
|
|
|
<h3>Deleted Java build rules</h3>
|
|
|
|
<p>Java has its own build systems now, so we've deleted the rules and associated
|
|
variables from Base, although they might get added to the Extensions build rules
|
|
for a while in case anyone still needs them.</p>
|
|
|
|
<h2 align="center">Changes between 3.14.x and 3.15.0.1</h2>
|
|
|
|
<h3>Application clean rules</h3>
|
|
|
|
<p>The <tt>clean</tt> Makefile target has changed between a single-colon rule
|
|
and a double-colon rule more than once in the life of the EPICS build rules, and
|
|
it just changed back to a single-colon rule, but now we recommend that
|
|
applications that wish to provide a Makefile that is backwards compatible with
|
|
the 3.14 build rules use the construct shown below. The 3.15 rules now support
|
|
a variable called <tt>CLEANS</tt> to which a Makefile can add a list of files to
|
|
be deleted when the user does a <tt>make clean</tt> like this:</p>
|
|
|
|
<blockquote><pre>CLEANS += <list of files to be cleaned>
|
|
|
|
ifndef BASE_3_15
|
|
clean::
|
|
$(RM) $(CLEANS)
|
|
endif</pre></blockquote>
|
|
|
|
<p>The conditional rule provides compatibility for use with the 3.14 build
|
|
system.</p>
|
|
|
|
<h3>MSI included with Base</h3>
|
|
|
|
<p>An enhanced version of the Macro Substitution and Include program <q>msi</q>
|
|
has been included with Base. Both this new version of msi and the IOC's
|
|
<tt>dbLoadTemplates</tt> command now support setting global macros in
|
|
substitution files, and <tt>dbLoadTemplates</tt> can now take a list of global
|
|
macro settings as the second argument on its command line. The substitution file
|
|
syntax is documented in the Application Developers Guide.</p>
|
|
|
|
<h3>Cross-builds targeting win32-x86-mingw</h3>
|
|
|
|
<p>Some Linux distributions now package the MinGW cross-compiler which makes it
|
|
possible to cross-build the win32-x86-mingw target from a linux-x86 host. Build
|
|
configuration files for this combination are now included; adjust the settings
|
|
in configure/os/CONFIG_SITE.linux-x86.win32-x86-mingw and add win32-x86-mingw to
|
|
the CROSS_COMPILER_TARGET_ARCHS variable in configure/CONFIG_SITE or in
|
|
configure/os/CONFIG_SITE.linux-x86.Common.</p>
|
|
|
|
<h3>Architecture win32-x86-cygwin Removed</h3>
|
|
|
|
<p>The ability to compile non-cygwin binaries using the Cygwin build tools is no
|
|
longer supported by current versions of Cygwin, so this architecture has been
|
|
removed. Use the MinWG tools and the win32-x86-mingw architecture instead.</p>
|
|
|
|
<h3>RTEMS and VxWorks Test Harnesses</h3>
|
|
|
|
<p>The original libCom test harness has been renamed <tt>libComTestHarness</tt>,
|
|
and two additional test harnesses have been created <tt>dbTestHarness</tt> and
|
|
<tt>filterTestHarness</tt> which are all built for RTEMS and vxWorks targets.
|
|
The new ones include tests in src/ioc/db/test and src/std/filters/test.</p>
|
|
|
|
<p>Running the new tests requires additional .db and .dbd files to be loaded at
|
|
runtime, which can be found in the relevant source directory or its O.Common
|
|
subdirectory. If the target can access the Base source tree directly it may be
|
|
simplest to cd to the relevant source directory before running the test. If not,
|
|
the files needed are listed in the generated 'testspec' file found in the
|
|
associated build (O.<i>arch</i>) directory.</p>
|
|
|
|
<p>For RTEMS users the current directory is determined in a BSP specific way.
|
|
See rtems_init.c and setBootConfigFromNVRAM.c in src/libCom/RTEMS.</p>
|
|
|
|
<h3>New API to hook into thread creation</h3>
|
|
|
|
<p>A hook API has been added allowing user-supplied functions to be called
|
|
whenever a thread starts. The calls are made from the thread's context,
|
|
and can be used to control additional thread properties not handled inside
|
|
EPICS base, e.g. setting the scheduling policy or CPU affinity (on SMP
|
|
systems).</p>
|
|
|
|
<p>The API also supports a mapping operation, calling a user-supplied function
|
|
for every thread that is currently running.</p>
|
|
|
|
<h3>New scan rate units</h3>
|
|
|
|
<p>Scan rates defined in the menuScan.dbd file may now be specified in seconds,
|
|
minutes, hours or Hertz, and plural time units will also be accepted (seconds
|
|
are used if no unit is mentioned in the choice string). At <tt>iocInit</tt> each
|
|
scan rate is compared with the OS's clock tick and a warning printed if the
|
|
rate is too fast or likely to be more than 10% different to the requested rate.
|
|
For example the rates given below are all valid, although non-standard (the
|
|
default menuScan choices that come with Base have not been changed):</p>
|
|
|
|
<blockquote>
|
|
<pre>menu(menuScan) {
|
|
choice(menuScanPassive, "Passive")
|
|
choice(menuScanEvent, "Event")
|
|
choice(menuScanI_O_Intr, "I/O Intr")
|
|
choice(menuScan1_hour, "1 hour")
|
|
choice(menuScan0_5_hours, "0.5 hours")
|
|
choice(menuScan15_minutes, "15 minutes")
|
|
choice(menuScan5_minutes, "5 minutes")
|
|
choice(menuScan1_minute, "1 minute")
|
|
choice(menuScan10_seconds, "10 seconds")
|
|
choice(menuScan5_seconds, "5 seconds")
|
|
choice(menuScan2_seconds, "2 seconds")
|
|
choice(menuScan1_second, "1 second")
|
|
choice(menuScan2_Hertz, "2 Hertz")
|
|
choice(menuScan5_Hertz, "5 Hertz")
|
|
choice(menuScan10_Hertz, "10 Hz")
|
|
}</pre></blockquote>
|
|
|
|
<h3>Alarm filtering added to input record types</h3>
|
|
|
|
<p>The record types ai, calc, longin and mbbi have a new alarm filter added to
|
|
them. This provides a low-pass filter that can be used to delay the reporting of
|
|
alarms caused by the input level passing the HIGH, HIHI, LOW or LOLO values. The
|
|
filter is controlled with a new AFTC field that sets the filter's time constant.
|
|
The default value for this field is zero, which keeps the record's original
|
|
alarm behaviour.</p>
|
|
|
|
<p>The record must be scanned often enough for the filtering action to work
|
|
effectively and the alarm severity can only change when the record is processed,
|
|
but that processing does not have to be regular; the filter uses the time since
|
|
the record last processed in its calculation. Setting AFTC to a positive number
|
|
of seconds will delay the record going into or out of a minor alarm severity or
|
|
from minor to major severity until the input signal has been in that range for
|
|
that number of seconds.</p>
|
|
|
|
<h3>Post events on Waveform record's NORD field</h3>
|
|
|
|
<p>When the record type or device support modify the NORD field of a waveform
|
|
record, the record support code now posts DBE_VALUE and DBE_LOG events for that
|
|
field, signalling the array length change to any client monitoring the NORD
|
|
field.</p>
|
|
|
|
<h3>Attributes of Non-VAL Fields</h3>
|
|
|
|
<p>Non-VAL fields now report meaningful information for precision, units,
|
|
graphic limits, control limits, and alarm limits instead of simply using
|
|
PREC, EGU, HOPR, LOPR, DRVL, DRVH, HIHI, HIGH, LOW, and LOLO. All delay
|
|
fields have a default precision of 2 digits, units "s" and control limits
|
|
of 0 to 100,000 seconds (these precision and limit values can be changed
|
|
for each record type as a whole at runtime by updating a registered global
|
|
variable). Input fields like A-L of the calc record read their metadata
|
|
from the corresponding INPn link if possible.</p>
|
|
<h4>epicsStdioRedirect.h merged into epicsStdio.h</h4>
|
|
|
|
<p>The definitions from the header file epicsStdioRedirect.h have been moved
|
|
into epicsStdio.h so all calls to printf(), puts() and putchar() in files that
|
|
include that OSI header will now be subject to stdout redirection. In past
|
|
releases (3.14.7 and later) it was necessary to request the redirection support
|
|
by including the epicsStdioRedirect.h header file. The header file is still
|
|
provided, but now it just includes epicsStdio.h.</p>
|
|
|
|
<h4>Named Soft Events</h4>
|
|
|
|
<p>Soft events can now be given meaningful names instead of just using the
|
|
numbers 1-255. The EVNT field is now a DBF_STRING. The <tt>post_event()</tt> API
|
|
is now deprecated but still works. It should be replaced by code that in advance
|
|
looks up the <tt>EVNTPVT</tt> event handle associated with the named event by
|
|
calling <tt>eventNameToHandle(char *)</tt>, and when that event occurs passes
|
|
that handle to the new <tt>postEvent(EVNTPVT)</tt> routine (which may be called
|
|
from interrupt level). A new iocsh command <tt>postEvent <i>name</i></tt> will
|
|
trigger a named event from the command-line or a startup script (on vxWorks the
|
|
expression <tt>postEvent(eventNameToHandle("<i>name</i>"))</tt> must be used
|
|
instead though).</p>
|
|
|
|
<h4>Parallel Builds</h4>
|
|
|
|
<p>
|
|
As EPICS sites get computers with more CPUs they report additional bugs in our
|
|
parallel build rules. Various issues have been fixed by separating out the build
|
|
rules that generate dependency (.d) files, ensuring that they are constructed at
|
|
the appropriate time in the build.</p>
|
|
|
|
<p>
|
|
These rule changes can cause additional warning messages to appear when building
|
|
support modules. Where an application provides its own Makefile rules it may now
|
|
have to add rules to construct an associated dependency file. In many cases
|
|
though the change needed is just to replace a dependency for a
|
|
<tt>target$(OBJ)</tt> with the <tt>target$(DEP)</tt> so this</p>
|
|
|
|
<pre>
|
|
myLib$(OBJ): myLib_lex.c</pre>
|
|
|
|
<p>
|
|
becomes</p>
|
|
|
|
<pre>
|
|
myLib$(DEP): myLib_lex.c</pre>
|
|
|
|
<p>
|
|
To debug build issues assocated with dependency files, use the command <tt>make
|
|
--debug=m</tt> which tells GNUmake to display information about what it is doing
|
|
during the first pass when it updates its makefiles.</p>
|
|
|
|
<h3>
|
|
Removed tsDefs.h</h3>
|
|
|
|
<p>
|
|
The deprecated tsDefs API was provided for 3.13 compatibility only, and has now
|
|
been removed. Convert any remaining code that used it to call the epicsTime API
|
|
instead.</p>
|
|
|
|
<h3>
|
|
Changes to epicsVersion.h</h3>
|
|
|
|
<p>
|
|
The two macros <tt>EPICS_UPDATE_LEVEL</tt> and <tt>EPICS_CVS_SNAPSHOT</tt> have
|
|
been deleted from the epicsVersion.h file; they were deprecated in R3.14 and can
|
|
be replaced with <tt>EPICS_PATCH_LEVEL</tt> and <tt>EPICS_DEV_SNAPSHOT</tt>
|
|
respectively.</p>
|
|
|
|
<p>
|
|
A new pair of macros has been added to make version number comparisons easier.
|
|
Code that will not work with a version of Base before 3.15.0 can now be
|
|
written like this to prevent it from compiling:</p>
|
|
|
|
<pre style="margin: 0 2em;">
|
|
#if defined(VERSION_INT) && EPICS_VERSION_INT < VERSION_INT(3,15,0,0)
|
|
# error EPICS Base R3.15.0 or later is required
|
|
#endif
|
|
</pre>
|
|
|
|
<h3>
|
|
Added support for iocLogPrefix</h3>
|
|
|
|
<p>
|
|
Added a <code>iocLogPrefix</code> command to <code>iocsh</code>. This adds a
|
|
prefix to all messages from this IOC (or other log client) as they get sent to the
|
|
iocLogServer. This lets sites use the "fac=<<i>facility</i>>" syntax for
|
|
displaying the facility, process name etc. in log viewers like the
|
|
<code>cmlogviewer</code>.</p>
|
|
|
|
<h3>
|
|
Reworked the epicsEvent C & C++ APIs</h3>
|
|
|
|
<ul>
|
|
<li>Renamed the enum epicsEventWaitStatus to epicsEventStatus</li>
|
|
<li>Defined epicsEventWaitStatus as a macro for epicsEventStatus</li>
|
|
<li>Renamed epicsEventWaitOk to epicsEventOk</li>
|
|
<li>Renamed epicsEventWaitError to epicsEventError</li>
|
|
<li>Defined epicsEventWaitOK and epicsEventWaitError as macros</li>
|
|
<li>Added epicsEventTrigger(id) which triggers an event and returns OK or an
|
|
error status if the underlying OS primitives report an error</li>
|
|
<li>Added epicsEventMustTrigger(id) which halts on error</li>
|
|
<li>Defined epicsEventSignal(id) as a macro for epicsEventMustTrigger(id)</li>
|
|
<li>Added a new C++ method epicsEvent::trigger() which throws an
|
|
epicsEvent::invalidSemaphore in the event of an error</li>
|
|
<li>epicsEvent::signal() makes an inline call to epicsEvent::trigger()</li>
|
|
<li>epicsEventWait() and epicsEventWaitWithTimeout() now return an error
|
|
status if the underlying OS primitives report an error</li>
|
|
<li>All the epicsEventMust...() routines are now implemented in the common
|
|
libCom/osi/epicsEvent.cpp source file, and call cantProceed() instead of
|
|
mis-using assert()</li>
|
|
<li>Implemented epicsEventShow() on Posix</li>
|
|
<li>Win32: Removed all epicsShareAPI decorations</li>
|
|
</ul>
|
|
|
|
<h3>
|
|
Enabled histogram record type</h3>
|
|
|
|
<p>
|
|
The histogram record was not included in the base.dbd file in any 3.14 release,
|
|
but has now been added along with its associated soft device support. The build
|
|
system now generates the list of all the record.dbd files in base automatically
|
|
in src/std/rec/Makefile.</p>
|
|
|
|
<h3>
|
|
Reorganization of src/</h3>
|
|
|
|
<p>Reorganization of subdirectories of src/ to better represent the relation
|
|
between different parts as described in the following table.</p>
|
|
|
|
<p>This change also allows the number of libraries built to be reduced to:
|
|
libCap5.so, libca.so, libdbCore.so, libdbStaticHost.so,
|
|
libCom.so, libcas.so, libdbRecStd.so, and libgdd.so</p>
|
|
|
|
<table border="1"><tbody>
|
|
<tr>
|
|
<th>Component</th>
|
|
<th>Dependency</th>
|
|
<th>Library name</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
<tr>
|
|
<td>src/tools</td>
|
|
<td></td>
|
|
<td></td>
|
|
<td>Build system scripts</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/libCom</td>
|
|
<td>src/tools</td>
|
|
<td>Com</td>
|
|
<td>Utility routines and OS-independant API</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/template</td>
|
|
<td>src/tools</td>
|
|
<td></td>
|
|
<td>User application templates (e.g. makeBaseApp)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/ca/client</td>
|
|
<td>src/libCom</td>
|
|
<td>ca</td>
|
|
<td>Channel Access client</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/ca/legacy/gdd</td>
|
|
<td>src/ca/client</td>
|
|
<td>gdd</td>
|
|
<td>Generic data layer for PCAS</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/ca/legacy/pcas</td>
|
|
<td>src/ca/legacy/gdd</td>
|
|
<td>cas</td>
|
|
<td>Portable Channel Access Server</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/ioc</td>
|
|
<td>src/ca</td>
|
|
<td>dbCore</td>
|
|
<td>Core database processing functions</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/std</td>
|
|
<td>src/ioc</td>
|
|
<td>dbRecStd</td>
|
|
<td>Standard records, soft device support and the softIoc </td>
|
|
</tr>
|
|
</tbody></table>
|
|
|
|
<p>
|
|
In order to better reflect these relations the following
|
|
directories and files were moved as described:</p>
|
|
|
|
<table border="1"><tbody>
|
|
<tr>
|
|
<th colspan="2">Relocations</th>
|
|
</tr>
|
|
<tr>
|
|
<th>Previous</th><th>New</th>
|
|
</tr>
|
|
<tr>
|
|
<th colspan="2">libCom</th>
|
|
</tr>
|
|
<tr>
|
|
<td>src/RTEMS</td>
|
|
<td>src/libCom/RTEMS</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/toolsComm/flex</td>
|
|
<td>src/libCom/flex</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/toolsComm/antelope</td>
|
|
<td>src/libCom/yacc</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="right">src/dbStatic/alarm.h<br>.../alarmString.h</td>
|
|
<td>src/libCom/misc/</td>
|
|
</tr>
|
|
<tr>
|
|
<th colspan="2">IOC Core Components</th>
|
|
</tr>
|
|
<tr>
|
|
<td>src/bpt</td>
|
|
<td>src/ioc/bpt</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/db</td>
|
|
<td>src/ioc/db</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/dbStatic</td>
|
|
<td>src/ioc/dbStatic</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/dbtools</td>
|
|
<td>src/ioc/dbtemplate</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/misc</td>
|
|
<td>src/ioc/misc</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/registry</td>
|
|
<td>src/ioc/registry</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/rsrv</td>
|
|
<td>src/ioc/rsrv <a href="#rsrv">1</a></td>
|
|
</tr>
|
|
<tr>
|
|
<th colspan="2">Standard Record Definitions</th>
|
|
</tr>
|
|
<tr>
|
|
<td>src/dev/softDev</td>
|
|
<td>src/std/dev</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/rec</td>
|
|
<td>src/std/rec</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/softIoc</td>
|
|
<td>src/std/softIoc</td>
|
|
</tr>
|
|
<tr>
|
|
<th colspan="2">Channel Access</th>
|
|
</tr>
|
|
<tr>
|
|
<td>src/ca</td>
|
|
<td>src/ca/client</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/catools</td>
|
|
<td>src/ca/client/tools</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/cap5</td>
|
|
<td>src/ca/client/perl</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/gdd</td>
|
|
<td>src/ca/legacy/gdd</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/cas</td>
|
|
<td>src/ca/legacy/pcas</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/excas</td>
|
|
<td>src/ca/legacy/pcas/ex</td>
|
|
</tr>
|
|
<tr>
|
|
<th colspan="2">User Templates</th>
|
|
</tr>
|
|
<tr>
|
|
<td>src/makeBaseApp</td>
|
|
<td>src/template/base</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/makeBaseExt</td>
|
|
<td>src/template/ext</td>
|
|
</tr>
|
|
<tr>
|
|
<th colspan="2">Dispersed</th>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="3">src/util <a href="#util">2</a></td>
|
|
<td>src/ca/client</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/ca/client/test</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/libCom/log</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="2">src/as <a href="#as">3</a></td>
|
|
<td>src/libCom/as</td>
|
|
</tr>
|
|
<tr>
|
|
<td>src/ioc/as</td>
|
|
</tr>
|
|
</tbody></table>
|
|
|
|
<p><a name="rsrv">1</a>
|
|
RSRV is built as part of dbCore due to its tight (bidirectional) coupling
|
|
with the other database code.</p>
|
|
|
|
<p><a name="util">2</a>
|
|
The contents for src/util/ moved to three locations. The caRepeater init script
|
|
was moved to src/ca/client/. ca_test is now in src/ca/client/test/.
|
|
The iocLogServer was moved into the same directory (src/libCom/log) as
|
|
the log client code.</p>
|
|
|
|
<p><a name="as">3</a>
|
|
The Access Security code has been divided, with the parts not related to the
|
|
database (lexer/parser and trap registration) becoming part of libCom.
|
|
The remaining components are included in the dbCore library</p>
|
|
|
|
<h3>
|
|
Moved src/RTEMS/base directory</h3>
|
|
|
|
<p>
|
|
These files are now found under src/RTEMS.</p>
|
|
|
|
<h3>
|
|
Removed 3.13 compatibility</h3>
|
|
|
|
<p>
|
|
Removed the 3.13 <top>/config directory and build compatibility rules and
|
|
variables, and various conversion documents.</p>
|
|
|
|
</body>
|
|
</html>
|