User`s manual

Writing Custom Applications

// Alerts

Module.Alerts().OnTimeStampRolloverAlert.SetEvent(

this, &ApplicationIo::HandleTimestampRolloverAlert);

Module.Alerts().OnSoftwareAlert.SetEvent(this, &ApplicationIo::HandleSoftwareAlert);

Module.Alerts().OnWarningTemperature.SetEvent(this, &ApplicationIo::HandleWarningTempAlert);

Module.Alerts().OnInputFifoOverrun.SetEvent(this, &ApplicationIo::HandleInputFifoOverrunAlert);

Module.Alerts().OnInputTrigger.SetEvent(this, &ApplicationIo::HandleInputTriggerAlert);

Module.Alerts().OnInputOverrange.SetEvent(this, &ApplicationIo::HandleInputFifoOverrangeAlert);

This code attaches alert processing event handlers to their corresponding events. Alerts are packets that the module generates

and sends to the Host as packets containing out-of-band information concerning the state of the module. For instance, if the

analog inputs were subjected to an input over-range, an alert packet would be sent to the Host, interspersed into the data

stream, indicating the condition. This information can be acted upon immediately, or simply logged along with analog data

for subsequent post-analysis.

// Configure Stream Event Handlers

Stream.OnDataAvailable.SetEvent(this, &ApplicationIo::HandleDataAvailable);

The Stream object manages communication between the application and a piece of hardware. Separating the I/O into a

separate class clarifies the distinction between an I/O protocol and the implementing hardware.

In Malibu, high rate data flow is controlled by one of a number of streaming classes. In this example we use the events of the

PacketStream class to alert us when a packet arrives from the target. When a data packet is delivered by the data streaming

system, OnDataAvailable event will be issued to process the incoming data. This event is set to be handled by

HandleDataAvailable. After processing, the data will be discarded unless saved in the handler. Similarly,

“OnDataRequired” event is handled by HandleDataRequired. In such a handler, packets would be filled with data for output

to the baseboard. The Snap application does not generate output, so the event is left unhandled.

Timer.OnElapsed.SetEvent(this, &ApplicationIo::HandleTimer);

Timer.OnElapsed.Thunk();

In this example, a Malibu SoftwareTimer object has been added to the ApplicationIo class to provide periodic status updates

to the user interface. The handler above serves this purpose.

An event is not necessarily called in the same thread as the UI. If it is not, and if you want to call a UI function in the handler

you have to have the event synchronized with the UI thread. A call to Synchronize() directs the event to call the event

handler in the main UI thread context. This results in a slight performance penalty, but allows us to call UI methods in the

event handler freely. The Timer uses a similar synchronization method, Thunk(). Here the event is called in the main thread

context, but the issuing thread does not wait for the event to be handled before proceeding. This method is useful for

notification events.

Creating a hardware object does not attach it to the hardware. The object has to be explicitly opened. The Open() method of

the baseboard activates the board for use. It opens the device driver for the baseboard and allocates internal resources for

use. The next step is to call Reset() method which performs a board reset to put the board into a known good state. Note that

reset will stop all data streaming through the busmaster interface and it should be called when data taking has been halted.

The size of the busmaster region is changeable by using the BusMasterSize() property before opening the board. Larger

values allow more overlap between the board and application, at the cost of slower allocation at startup time.

// Open Devices

FBusmasterSize = 1 << (Settings.BusmasterSize + 22);

Module.BusMasterSize(FBusmasterSize);

X5-GSPS User's Manual 50