libCom/test, Breakpoints, vxWorks 6, postFix/calcPerform, calc/calcout/asLib,
recGblAlarmHook, raw simulation mode.
This commit is contained in:
Andrew Johnson
@@ -13,6 +13,133 @@
|
||||
|
||||
<!-- Insert new items below here ... -->
|
||||
|
||||
<h4>libCom/test</h4>
|
||||
|
||||
<p>These test programs are no longer installed into the bin/<i>arch</i>
|
||||
directory. Running all these programs on any host architecture should be as
|
||||
simple as:</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>cd /path/to/base/src/libCom/test/O.<i>arch</i>
|
||||
make test</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>The above make target uses Perl's Test::Harness module to execute all of the
|
||||
test programs and summarize the result. It is also possible to run individual
|
||||
tests as desired; the output is designed to be comprehensible to humans.</p>
|
||||
|
||||
<p>For vxWorks and RTEMS, a test harness has been created that will run all of
|
||||
the test programs in a suitable order. At a vxWorks target shell, type:</p>
|
||||
|
||||
<blockquote>
|
||||
<pre>ld </path/to/base/bin/vxWorks-<i>arch</i>/vxTestHarness.munch
|
||||
cd "/path/to/writable/directory"
|
||||
epicsRunLibComTests</pre>
|
||||
</blockquote>
|
||||
|
||||
<p>On RTEMS, boot the bin/<i>arch</i>/rtemsTestHarness binary.</p>
|
||||
|
||||
<p>You may wish to capture the output from running these to a file to more
|
||||
easily check the results, since there is no wrapper program to collect and
|
||||
summarize the results of the individual test programs.</p>
|
||||
|
||||
<h4>Breakpoint tables</h4>
|
||||
|
||||
<p>The handling of breakpoint table data has been reworked. It is now possible
|
||||
to give table data in either ascending or descending order, and the breakpoint
|
||||
data may have a negative slope such that the engineering values increase while
|
||||
the raw values decrease and vice versa. The only restriction on the data is that
|
||||
is must be monatonically increasing or decreasing, so you can't use a breakpoint
|
||||
table for curves that have local minima or maxima. This restriction is checked
|
||||
for when the breakpoint table is loaded.</p>
|
||||
|
||||
<h4>Support for vxWorks 6</h4>
|
||||
|
||||
<p>The build configuration support for vxWorks 6.x has changed significantly,
|
||||
having been recombined with the older vxWorks 5.x support. The two target
|
||||
architectures <tt>vxWorks6-mv2100</tt> and <tt>vxWorks6-mv5100</tt> have been
|
||||
removed; IOCs built under vxWorks 6.x using these architectures must revert to
|
||||
the original <tt>vxWorks-ppc603_long</tt> and <tt>vxWorks-ppc604_long</tt>
|
||||
architectures instead. The configuration file CONFIG_SITE.Common.vxWorksCommon
|
||||
now specifies the vxWorks version number, as well as the filesystem path to
|
||||
the installation of vxWorks using the WIND_BASE variable.</p>
|
||||
|
||||
<h4>postfix and calcPerform</h4>
|
||||
|
||||
<p>The calc expression parser and exective have undergone a signficant overhaul,
|
||||
although the API and expression language supported are backwards compatible with
|
||||
one minor exception, described below. Significant improvements have been made to
|
||||
both the API and the expression language: Multiple values can be calculated and
|
||||
assignments made in a calc expression; Error reporting for humans is now
|
||||
supported by the expression parser, and code can discover what inputs and
|
||||
outputs are needed and generated by an expression.</p>
|
||||
|
||||
<p>Assignment operations are now possible, using the new <tt>:=</tt> operator
|
||||
which must have an expression variable (<tt>A</tt> through <tt>L</tt>) to its
|
||||
immediate left. Multiple expressions can be included in the calculation string,
|
||||
separated by a semicolon <tt>;</tt>, all but one of which must be assignments.
|
||||
The value of the whole string is determined by the single non-assignment
|
||||
expression, which may appear anywhere in the string. For example, the following
|
||||
string causes a single CALC record to output the successive values of a sine
|
||||
curve: <tt>sin(a); a:=a+d2r</tt></p>
|
||||
|
||||
<p>Previously any expression that performed an invalid operation which would
|
||||
generate a NaN or Inf result would be stopped immediately and return an error to
|
||||
the caller. Now it is possible to perform operations that generate NaN or
|
||||
infinite results, and the results are returned as normal. The result of the
|
||||
expression or the value assigned to a variable may thus be a NaN or an
|
||||
infinity. To permit this to be checked within the expression, the new operators
|
||||
<tt>finite()</tt>, <tt>isinf()</tt> and <tt>isnan()</tt> have been added to the
|
||||
expression language. The literal values <tt>Inf</tt> and <tt>NaN</tt> are also
|
||||
now supported in expressions.</p>
|
||||
|
||||
<p>The incompatible change to the expression language was to change the
|
||||
<tt>NOT</tt> operator from performing a unary minus operation to an integer
|
||||
bitwise not; the former meaning is illogical and as a result was probably not
|
||||
used much, if at all — nobody complained when I discussed this on
|
||||
tech-talk...</p>
|
||||
|
||||
<p>The extended API and the expression language are now discussed in detail in
|
||||
chapter 19 (libCom) of the R3.14.9 version of the IOC Application Developer's
|
||||
Guide.</p>
|
||||
|
||||
<h4>calc and calcout record, asLib</h4>
|
||||
|
||||
<p>As a result of the above changes to the calc expression parser and executive,
|
||||
both the calc and calcout records and the Access Security library have been
|
||||
modified to take advantage of the new error diagnostics. The Access Security
|
||||
library has been made to reject any expression that contains an assignment
|
||||
operation, to prevent any possible security holes that might be caused by this
|
||||
significant change to the expression rules.</p>
|
||||
|
||||
<p>The calc and calcout records have had some subtle changes applied: To
|
||||
mitigate the effects of the Inf/NaN behaviour change, the result of an
|
||||
expression is checked for NaN, which will result in the UDF field being set and
|
||||
an Undefined/INVALID_ALARM being raised as a result.</p>
|
||||
|
||||
<p>An empty string is no longer a legal expression, therefor the CALC and OCAL
|
||||
fields have been changed so that their default value is a literal <tt>"0"</tt>
|
||||
string. Also any calcout record device support must now add the line
|
||||
<tt>#include "postfix.h"</tt> before the
|
||||
<tt>#include "calcoutRecord.h"</tt> line in the source code.</p>
|
||||
|
||||
<h4>recGblAlarmHook</h4>
|
||||
|
||||
<p>The <tt>recGblResetAlarms()</tt> routine (which is called by all record types
|
||||
towards the end of record processing) now optionally calls a single hook routine
|
||||
via the function pointer <tt>recGblAlarmHook</tt> after it has updated a
|
||||
record's alarm status and severity. See regGbl.h for the hook routine prototype
|
||||
definition, the routine is also given the previous values of the record's status
|
||||
and severity. The hook routine must not block, since this would hold up record
|
||||
processing.</p>
|
||||
|
||||
<h4>ai, bi, mbbi and mbbiDirect records</h4>
|
||||
|
||||
<p>These record types now support raw simulation mode. If the value of the SIMM
|
||||
field is 2 (enum string "RAW"), the SIOL link value is placed into the RVAL
|
||||
field and passed through the raw to engineering units conversion process just
|
||||
like the real device support's raw value would be.</p>
|
||||
|
||||
<h4>dbpr</h4>
|
||||
|
||||
<p>The TIME field of a record is now displayed in a human readable format. TIME
|
||||
|
||||
Reference in New Issue
Block a user