diff --git a/configure/os/CONFIG.Common.RTEMS-mvme2700 b/configure/os/CONFIG.Common.RTEMS-mvme2700 new file mode 100644 index 000000000..9874e6065 --- /dev/null +++ b/configure/os/CONFIG.Common.RTEMS-mvme2700 @@ -0,0 +1,25 @@ +# +# Author: Matt Rippa +# +RTEMS_TARGET_CPU = powerpc +ARCH_DEP_CFLAGS += -DMY_DO_BOOTP=NULL +ARCH_DEP_CFLAGS += -DHAVE_PPCBUG +ARCH_DEP_CFLAGS += -DNVRAM_INDIRECT + +MUNCH_SUFFIX = .boot +MUNCHNAME = $(PRODNAME:%$(EXE)=%$(MUNCH_SUFFIX)) +define MUNCH_CMD + $(RTEMS_BASE)/bin/$(OBJCOPY_FOR_TARGET) -O binary -R .comment -S $< rtems + gzip -f9 rtems + $(RTEMS_BASE)/bin/$(LD_FOR_TARGET) -o $@ \ + $(PROJECT_RELEASE)/lib/bootloader.o \ + --just-symbols=$< \ + -b binary rtems.gz \ + -T $(PROJECT_RELEASE)/lib/ppcboot.lds \ + -Map $<.map + rm -f rtems.gz +endef + +OP_SYS_LDLIBS += -lbspExt + +include $(CONFIG)/os/CONFIG.Common.RTEMS diff --git a/documentation/RELEASE_NOTES.html b/documentation/RELEASE_NOTES.html index 441be8e9e..de85110a5 100644 --- a/documentation/RELEASE_NOTES.html +++ b/documentation/RELEASE_NOTES.html @@ -2,6 +2,7 @@ "http://www.w3.org/TR/html4/loose.dtd"> + EPICS Base R3.14.x Release Notes @@ -9,10 +10,13 @@

EPICS Base Release 3.14.1x

-

Changes between 3.14.10 and 3.14.11

+

Added support for RTEMS-mvme2700

+ +

Supplied by Matt Rippa <mrippa@gemini.edu>. Should work for MVME2400, too.

+

CA Commandline tools: priority support

A new option -p was added to all Channel Access command line @@ -23,18 +27,17 @@ tools to allow specifying the CA priority.

Changed linux builds to link against libncurses instead of libcurses (suggested by Peter Zumbruch).

-

Changes between 3.14.9 and 3.14.10

RTEMS Release

-

RTEMS release 4.9 or newer is required. If you are using the RTEMS NFS time -provider you need to use RTEMS 4.9.1 or newer.

+

RTEMS release 4.9 or newer is required. If you are using the RTEMS NFS +time provider you need to use RTEMS 4.9.1 or newer.

RTEMS epicsEventWaitWithTimeout

-

Correctly return epicsEventWaitTimeout when event is not pending and timeout -value is 0.0 secondsmore agressive.

+

Correctly return epicsEventWaitTimeout when event is not pending and +timeout value is 0.0 secondsmore agressive.

epicsRingPointer, epicsRingBytes

@@ -45,75 +48,77 @@ optimization.

The camonitor program now supports the ability to display both server- and client-side timestamps, simultaneously if requested. The old -command-line options -r -i and -I that controlled the -timestamp display have been replaced with a new -t option that takes -additional argument letters to control which timestamp sources and output format -should be used.

+command-line options -r -i and -I that controlled +the timestamp display have been replaced with a new -t option that +takes additional argument letters to control which timestamp sources and +output format should be used.

-

See the Command Line Tools section of the Channel Access reference manual or -run camonitor -h for a summary of the options.

+

See the Command Line Tools section of the Channel Access reference manual +or run camonitor -h for a summary of the options.

New "stdio" stringout device support

-

A new device support has been added that allows a stringout record to output -one-line messages to stdout, stderr or the errlog subsystem. Use DTYP="stdio" -and set the OUT field to one of "@stdout", "@stderr" or "@errlog" to control the -message destination. A newline is appended to the contents of the record's VAL -field when printing.

+

A new device support has been added that allows a stringout record to +output one-line messages to stdout, stderr or the errlog subsystem. Use +DTYP="stdio" and set the OUT field to one of "@stdout", "@stderr" or +"@errlog" to control the message destination. A newline is appended to the +contents of the record's VAL field when printing.

General Time subsystem

The way in which EPICS gets the time has been significantly revised since R3.14.9 with the introduction of the General Time subsystem. Two kinds of -pluggable time providers are now supported, which return either the current time -or the latest timestamp of a numbered Time Event from a hardware event system. -All IOCs must have at least one Current Time provider, but Event Time providers -are optional. The General Time subsystem guarantees that the timestamps -returned never step backwards, even when switching between time providers.

+pluggable time providers are now supported, which return either the current +time or the latest timestamp of a numbered Time Event from a hardware event +system. All IOCs must have at least one Current Time provider, but Event Time +providers are optional. The General Time subsystem guarantees that the +timestamps returned never step backwards, even when switching between time +providers.

-

A Current Time Provider reports the current wall-clock time if it is able to -when asked; if it can't it says so, and the time subsystem will then ask the -next provider in its list and so on until someone replies with the time. Event -Time providers are handled similarly, except that they are asked for the -timestamp associated with a particular Time Event number rather than the current -wall-clock time. The registered time providers can be listed using the IOC -command generalTimeReport(int interest) and some time providers also -have their own separate report commands.

+

A Current Time Provider reports the current wall-clock time if it is able +to when asked; if it can't it says so, and the time subsystem will then ask +the next provider in its list and so on until someone replies with the time. +Event Time providers are handled similarly, except that they are asked for +the timestamp associated with a particular Time Event number rather than the +current wall-clock time. The registered time providers can be listed using +the IOC command generalTimeReport(int interest) and some time +providers also have their own separate report commands.

Different target architectures come with different default Current Time -providers in Base. The Unix-like architectures rely on the underlying operating -system clock, which normally involves running something like ntpd as a separate -process. The real-time operating systems vxWorks and RTEMS install two Current -Time providers; the native operating system clock at the lowest priority (this provider -includes a task to periodically reset the operating system clock from a higher priority time -provider), and an NTP time provider which synchronizes the underlying operating sytem tick -timer with an NTP server. Microsoft Windows targets using the Win32 API use a +providers in Base. The Unix-like architectures rely on the underlying +operating system clock, which normally involves running something like ntpd +as a separate process. The real-time operating systems vxWorks and RTEMS +install two Current Time providers; the native operating system clock at the +lowest priority (this provider includes a task to periodically reset the +operating system clock from a higher priority time provider), and an NTP time +provider which synchronizes the underlying operating sytem tick timer with an +NTP server. Microsoft Windows targets using the Win32 API use a Windows-specific time provider which contains a built-in PLL.

-

There are no Event Time providers included with Base except for an optional -"Last Resort" Event provider which can be installed if a site wants to be sure -that every Time Event number will have a recent timestamp associated with it -even if the hardware event system goes down. The Last Resort Event Time provider -returns the current time for every Time Event number. To install this provider, -run the command installLastResortEventProvider from your IOC startup -script.

+

There are no Event Time providers included with Base except for an +optional "Last Resort" Event provider which can be installed if a site wants +to be sure that every Time Event number will have a recent timestamp +associated with it even if the hardware event system goes down. The Last +Resort Event Time provider returns the current time for every Time Event +number. To install this provider, run the command +installLastResortEventProvider from your IOC startup script.

Additional information about General Time and the time providers included with Base can be found in the IOC Application Developers Guide for R3.14.10, -sections 9.7 and 20.6. General Time was originally written by David H. Thompson -and Sheng Peng at ORNL, subsequently worked on by Babak Kalantari and Timo -Korhonen of PSI, and merged into Base by Peter Denison from Diamond. Andrew -Johnson provided input into the design at various points and made various code -revisions after the merge.

+sections 9.7 and 20.6. General Time was originally written by David H. +Thompson and Sheng Peng at ORNL, subsequently worked on by Babak Kalantari +and Timo Korhonen of PSI, and merged into Base by Peter Denison from Diamond. + Andrew Johnson provided input into the design at various points and made +various code revisions after the merge.

New ioc/dllPath.bat file for Win32

-

When creating an IOC with one of the win32-x86 target architectures, a file -dllPath.bat is now generated in the iocBoot/iocxxx directory which can -be run to adjust the PATH variable to include all of the support application -bin directories which might contain DLLs that the IOC uses. The PATH also -includes the IOC application's own bin directory, which simplifies starting up -the IOC as well.

+

When creating an IOC with one of the win32-x86 target architectures, a +file dllPath.bat is now generated in the iocBoot/iocxxx directory +which can be run to adjust the PATH variable to include all of the support +application bin directories which might contain DLLs that the IOC uses. The +PATH also includes the IOC application's own bin directory, which simplifies +starting up the IOC as well.

New epicsEndian.h header

@@ -124,75 +129,74 @@ EPICS_ENDIAN_LITTLE or EPICS_ENDIAN_BIG (these are numeric constants 1234 and needed because some ARM systems use mixed-endian format floats.

Note that just knowing the CPU's endianness doesn't tell you the complete -story about the byte order that your hardware registers will present to the CPU; -byte swapping is often performed automatically by PCI to VME bridge devices and -by other kinds of bus converter, so "portable" drivers aren't always.

+story about the byte order that your hardware registers will present to the +CPU; byte swapping is often performed automatically by PCI to VME bridge +devices and by other kinds of bus converter, so "portable" drivers aren't +always.

Array Subroutine Record added (aSub)

A heavily modified version of Andy Foster's genSub record type has been -added, called the aSub (Array Subroutine) record type. The new name is so that -genSub records can continue to be used in IOCs that need those features that -have changed or been removed in creating the aSub record type. The main +added, called the aSub (Array Subroutine) record type. The new name is so +that genSub records can continue to be used in IOCs that need those features +that have changed or been removed in creating the aSub record type. The main differences between genSub and aSub are:

-

epicsTimeEventDeviceTime support for soft channel input records

-

The Soft Channel device support for all input record types now supports the -fetching of the timestamp along with the data when the record's TSE field is set -to epicsTimeEventDeviceTime (-2). This works for both DB and CA links. However -the timestamp will only be fetched if the record's TSEL link is not set, so you -can't point TSEL to another record to read the -2 value into TSE (that's because -to make this work properly would require that the TSEL link be read twice every -time the record processes; once in the soft channel device support, and again -when the record type calls recGblGetTimeStamp().

+

The Soft Channel device support for all input record types now supports +the fetching of the timestamp along with the data when the record's TSE field +is set to epicsTimeEventDeviceTime (-2). This works for both DB and CA links. +However the timestamp will only be fetched if the record's TSEL link is not +set, so you can't point TSEL to another record to read the -2 value into TSE +(that's because to make this work properly would require that the TSEL link +be read twice every time the record processes; once in the soft channel +device support, and again when the record type calls +recGblGetTimeStamp().

devLib: CR/CSR Support added

-

Thanks to Eric Bjorklund for providing a patch to devLib that gives access to -the CR/CSR address space (for those on a VME64 CPU with appropriate support from -your BSP).

+

Thanks to Eric Bjorklund for providing a patch to devLib that gives access +to the CR/CSR address space (for those on a VME64 CPU with appropriate +support from your BSP).

ascaStats, dbcaStats, seqcaStats

Query routines have been added that count CA client connections made by -Access Security rules and Database Channel Access links. A similar routine will -be added to version 2.0.12 of the sequencer for counting sequence program CA -links:

+Access Security rules and Database Channel Access links. A similar routine +will be added to version 2.0.12 of the sequencer for counting sequence +program CA links:

-
-void ascaStats(int *pchans, int *pdiscon);
+

+  
void ascaStats(int *pchans, int *pdiscon);
 void dbcaStats(int *pchans, int *pdiscon);
 void seqcaStats(int *pchans, int *pdiscon);

 

 
-
The pchans parameter should point to integer storage which will be set to the
-total number of channels open, while the value at the pdiscon pointer will be
-set to the number of channels currently disconnected. Prototypes for these
-routines can be found in the header files asCa.h and dbCaTest.h (seqCom.h for
-the sequencer).

+
The pchans parameter should point to integer storage which will be set to
+the total number of channels open, while the value at the pdiscon pointer
+will be set to the number of channels currently disconnected. Prototypes for
+these routines can be found in the header files asCa.h and dbCaTest.h
+(seqCom.h for the sequencer).

 
 
Messages from errlog

 
@@ -202,60 +206,62 @@ rather than to stdout.

 
 
ipToAsciiProxy

 
-
This thread calls upon vendor libraries which may use significant amounts of stack.  Account for this by providing the ipToAsciiProxy thread with an epicsThreadStackBig stack.

+
This thread calls upon vendor libraries which may use significant amounts
+of stack.  Account for this by providing the ipToAsciiProxy thread with an
+epicsThreadStackBig stack.

 
 
iocBuild, iocRun and iocPause

 
 
These three new commands are mainly intended for use with DESY's redundant
 IOC software but they might have some uses for others too.  iocBuild
 allow an IOC to be initialized and set up ready for a quick start without
-actually making it live; a subsequent iocRun will bring it to the same
-state as an iocInit would have.  Once an IOC has been started (using
-either iocInit or iocBuild + iocRun) the
+actually making it live; a subsequent iocRun will bring it to the
+same state as an iocInit would have.  Once an IOC has been started
+(using either iocInit or iocBuild + iocRun) the
 iocPause command can be used to freeze it, disconnecting its PVs and
-stopping all scan activity.  The iocRun command restarts the IOC from
-this state.

+stopping all scan activity.  The iocRun command restarts the IOC
+from this state.

 
 
While this might seem like a useful thing to be able to do, we have not
-tested it on IOCs using real-world I/O, and it is not unlikely that pausing an
-operational IOC could cause irremdial havok to any device support, sequence
-programs and other software which is not expecting it, so use with care and make
-sure you test it first.  An IOC that is kept paused for more than a minute or
-two could fill up its network buffers and become impossible to restart without
-rebooting.

+tested it on IOCs using real-world I/O, and it is not unlikely that pausing
+an operational IOC could cause irremdial havok to any device support,
+sequence programs and other software which is not expecting it, so use with
+care and make sure you test it first.  An IOC that is kept paused for more
+than a minute or two could fill up its network buffers and become impossible
+to restart without rebooting.

 
 
IOC Support on 64-bit archs

 
-
A fairly significant number of changes have been that were necessary to allow
-the IOC code to run properly on 64-bit CPU architectures where a long
-is 64 bits wide.  This was not as simple as replacing every instance of the
-typename long with epicsInt32 because that would have broken a
-lot of external code unnecessarily.  The generated record.h file now uses the
-typenames from epicsTypes.h to declare record fields, thus field sizes are the
-same on both 32- and 64-bit platforms (on 64-bit, a DBF_LONG does
-not map to long but to int).  This change does not
-affect status return values, which are still implemented using the native
-long type for the platform.

+
A fairly significant number of changes have been that were necessary to
+allow the IOC code to run properly on 64-bit CPU architectures where a
+long is 64 bits wide.  This was not as simple as replacing every
+instance of the typename long with epicsInt32 because that
+would have broken a lot of external code unnecessarily.  The generated
+record.h file now uses the typenames from epicsTypes.h to declare record
+fields, thus field sizes are the same on both 32- and 64-bit platforms (on
+64-bit, a DBF_LONG does not map to long but to
+int).  This change does not affect status return values, which are
+still implemented using the native long type for the platform.

 
 
Conversion of empty strings to character types

 
 
While changing the conversion routines in db/dbConvert.c and
-db/dbFastLinkConv.c to support 64-bit architectures as described above, it was
-noticed that an empty string converts to the value 0 for all types other than
-DBF_CHAR and DBF_UCHAR where it converts to the ASCII
+db/dbFastLinkConv.c to support 64-bit architectures as described above, it
+was noticed that an empty string converts to the value 0 for all types other
+than DBF_CHAR and DBF_UCHAR where it converts to the ASCII
 character '0', value 0x30.  Since these types are usually used for
 storing small integers or boolean values rather than ASCII characters, it was
-decided that this conversion is wrong so it has been changed to match the other
-numeric conversions.

+decided that this conversion is wrong so it has been changed to match the
+other numeric conversions.

 
 
epicsShareAPI deprecated inside IOC

 
 
APIs that are intended for use inside the IOC, the epicsShareAPI
 attribute is slowly being removed.  This keyword is only used on MS Windows
-where it indicates to the compiler that the function should use Pascal calling
-conventions rather than C ones, and was necessary to be able to call such
-functions from MS Visual Basic.  APIs for use by client code (CA and libCom)
-will generally retain the attribute if they already had it.

+where it indicates to the compiler that the function should use Pascal
+calling conventions rather than C ones, and was necessary to be able to call
+such functions from MS Visual Basic.  APIs for use by client code (CA and
+libCom) will generally retain the attribute if they already had it.

 
 
Record types ANSIfied

 
@@ -265,10 +271,10 @@ implementations have been converted from K&R to ANSI C prototypes.

 
Added Perl5 CA library

 
 
Base now provides a CA client library interface for Perl5 scripts in
-src/cap5 and includes as examples some implementations of the catools
-programs written in Perl. Documentation on how to use the Perl library is
-available in base/html/CA.html after the build completes. This library
-cannot currently be built on Windows targets.

+src/cap5 and includes as examples some implementations of the
+catools programs written in Perl. Documentation on how to use the Perl
+library is available in base/html/CA.html after the build completes.
+This library cannot currently be built on Windows targets.

 
 
IOC ignores SIGHUP

 
@@ -284,18 +290,15 @@ should not affect the contents of Makefiles or any applications
 using Base. They do however require that the version of GNU Make used be 3.81
 or later. These changes are briefly:

 
   
-  
  • linux-xscale_be (tested with MOXA UC-7408 Plus)
+  
  • linux-xscale_be (tested with MOXA UC-7408 Plus)
    • 
 
 
 
    Added compile line header search directories
    
@@ -379,7 +377,7 @@ although the core developers lack the ability to test all of them:
    
 
    The compile line list of directories to search for header files now
 includes O.Common and the existing os subdirectories of SRC_DIRS
 <src_dir>/os/<OS_CLASS>, <src_dir>/os/posix, and
-<src_dir>/os/default. 
    
+<src_dir>/os/default.
    
 
 
    Parallel make now supported
    
 
@@ -503,7 +501,7 @@ discussion on the cygwin mailing list it looks like this will be fixed in
 make version 3.82. In the meantime make version 3.80 or a fixed make can be
 downloaded from this
-website. 
    
+website.
    
 
 
    New Architectures
    
 
@@ -540,7 +538,7 @@ this version of Base.
    
 
    dbLoadTemplate
    
 
 
    The parser for the substitutions file accepted by dbLoadTemplate() has
-been revised, and is now stricter than it used to be — unmatched
+been revised, and is now stricter than it used to be — unmatched
 characters that were accepted and discarded without warning before will now
 generate errors. The quote characters at the two ends of a quoted string
 value must now match, although either single or double quotes can be used.
@@ -641,7 +639,7 @@ added to the expression language. The literal values Inf and
 
    The only incompatible change to the expression language was to change the
 NOT 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
+used much, if at all — nobody complained when I discussed this on
 tech-talk...
    
 
 
    The extended API and the expression language are now discussed in detail
@@ -802,20 +800,20 @@ reconnect
    
 
    These changes are required to allow software outside of Base to be built
 on win32 architectures.
    NOTE: If any of your *App/*Db/Makefiles contain "DBDNAME =" lines you should make these same changes in that *Db dirctory. -
  • In all *App/src/Makefile Makefiles change +
  • In all *App/src/Makefile Makefiles change
    RECTYPES=<name>.h
    - to + to
    DBDINC+=<name>
    - change + change
    MENUS=<name>.h
    - to + to
    DBDINC+=<name>
    - change + change
    BPTS
    - to + to
    DBD
    - change + change
    INSTALLDB
    - to + to
    DB
    - change + change
    DBDINSTALL
    - to + to
    DBD
    • -
  • In all example *App/src/Makefile files change +
  • In all example *App/src/Makefile files change
    example_SRCS_DEFAULT += registerRecordDeviceDriver.c
    - to + to
    - example_SRCS_DEFAULT += <name>_registerRecordDeviceDriver.cpp -
    + example_SRCS_DEFAULT += + <name>_registerRecordDeviceDriver.cpp where <name> is the base name of a <name>.dbd file which was created from a <name>Include.dbd file and which will be loaded in a st.cmd or stcmd.host script (e.g. example).
    • -
  • In ./iocBoot/ioc<name>/st.cmd files change +
  • In ./iocBoot/ioc<name>/st.cmd files change
    dbLoadDatabase("dbd/exampleApp.dbd")
    - to + to
    dbLoadDatabase("dbd/example.dbd")
    • -
  • In <top>/iocBoot/ioc<name>/stcmd.host files change +
  • In <top>/iocBoot/ioc<name>/stcmd.host files change
    dbLoadDatabase("../../dbd/exampleApp.dbd",0,0)
    - to + to
    dbLoadDatabase("../../dbd/example.dbd",0,0)
    @@ -2436,31 +2434,31 @@ iocCore on platforms besides vxWorks.

    iocCore is now supported on the following platforms: