User Oriented APIs for Timing System

Report
Timing Workshop – 5th June 2014, Prague
User Oriented APIs for
Timing System
Jim Chen
Hytec Electronics Ltd
Timing Workshop – 5th June 2014, Prague
The Problem
• MRF timing module now has many functionalities rather than purely
trigger generation. These include timestamp, event FIFO, data
transmit and even GPIO etc. This is excellent!
• Timing system also has many ways of generating signals – distributed
bus, events, sequencer, prescaler etc. This is also good.
• Variety of outputs – TTL, LVPECL, CML, Univ I/O. Great!
• Many form factors.
• One of the problems – functions are not always to all platforms
• Not easy to configure – especially for new comers
Jim Chen
Hytec Electronics Ltd
Timing Workshop – 5th June 2014, Prague
What we end up
•
•
•
•
•
•
•
•
Jim Chen
MRF provides low level APIs for VxWorks/RTEMS and Linux
Each lab has its own app implementation.
mrfioc2
Cosylab
Taiwan Light Source – TPS pciGeneral Device Support
Hytec UDP for Orion, APIs for ELI, NUS
……
Re-invent the wheel from time to time and it continues
Hytec Electronics Ltd
Timing Workshop – 5th June 2014, Prague
What end-user needs
Triggers!
Jim Chen
Hytec Electronics Ltd
Timing Workshop – 5th June 2014, Prague
What end-user needs
•
•
•
•
•
•
•
•
Jim Chen
Generate repetitive triggers in different frequencies
Fire single shot
Set delay/relative delay and width for each trigger
Enable/disable triggers/modules
Set up timestamp
Transfer data
Interrupt notification and callback
etc…
Hytec Electronics Ltd
Timing Workshop – 5th June 2014, Prague
What would be nice
• Trigger implementation transparent to the user –
EvrSetPulseProperties, EvrSetPrescalerTrig, EvrUnivDlySetDelay,
EvrSetFineDelay – hide all these!
• User function oriented rather than device function oriented
• A Generic API function set for all platforms – EPICS, TANGO, OPC,
VxWorks, Linux and Windows
• Maintained by community or by Jukka?
Jim Chen
Hytec Electronics Ltd
Timing Workshop – 5th June 2014, Prague
How easy to achieve this
• Not easy given so many options
• Need well defined structures
• Need many branches to distinguish architecture differences, signal
generation differences, trigger type differences, output type
differences, jitter requirement and accuracy differences etc.
• Separate the OS specific from the generic APIs
• Proper interrupt mechanism and callback
• Endian issue
Jim Chen
Hytec Electronics Ltd
Timing Workshop – 5th June 2014, Prague
What we can do
OS Specific
+baseAddr() : long
+ConnectInt() : long
+enableInt() : long
«datatype»
baseStruct
Low Level APIS
+moduleNumber()
+triggerNumber()
+sourceType()
+archType()
+outputType()
+freq()
+RF()
+ EvrEnable() : long
+ EvrMapRamEnable() : long
+EvrSetPulseParams() : long
+......()
Trigger
EVR
+setupTrigger(in baseStruct : baseStruct)
+enable(in baseStruct : baseStruct)
+delay(in baseStruct : baseStruct, in delay : double)
+width(in baseStruct : baseStruct, in width)
+freq(in baseStruct : baseStruct, in freq : int)
+......()
Jim Chen
+setupEVR(in source, in RF)
+enable()
+setupTS()
+connectINT()
+......()
EVG
+setupEVG(in source, in RF, in DBUS, in SEQN, in EVENTs)
+enable()
+singleShot()
+setupTS()
+connectINT()
+......()
Hytec Electronics Ltd
Timing Workshop – 5th June 2014, Prague
The main entities
•
•
•
•
•
•
Jim Chen
OS resource wrapper – base address, interrupt, DMA if required
Jukka’s low level APIs
Trigger structure – need to cover all aspects
Trigger – need to encapsulate all operations
EVG – capable of defining trigger source or the combination
EVR – simple class
Hytec Electronics Ltd
Timing Workshop – 5th June 2014, Prague
The implementation
• Let’s discuss……
Jim Chen
Hytec Electronics Ltd

similar documents